[uriMediaType-9]: Draft Finding from 12th February F2F Meeting

Folks,

I took an action to draft a finding based on our discussion at the TAG F2F
on 12th February.

Find attached my initial draft.

In drafting the finding I believe I have stayed within the bounds of what we
discussed on Tuesday. However, having now read Eastlakes draft I have a
couple of comments that might result in further discussion that would affect
our 'finding':

1) We recommend that the mapping should be to an HTTP scheme URI (with some
well-known common base URI) rather than to a URI in a new URI scheme. This
is fine from the point-of-view of decentralised authority over the creation
of mapped URIs (subject to there being an appropriate delegation of
authority under common base URI). However, since part of the motivation for
this suggested change is that the mapped URI be capable of being
dereferenced to provide documentation on the media-type, our  proposed
change places the actual deployment of such documentation back under
centralised control. This seems counter-productive with respect to the goal
of enabling those defining a media-type provide documentation without
centralised control. OTOH, it would potentially preserve some element of
review process in the definition and deployment of new media-types. In the
IANA considerations section of his draft Eastlake draws attention to the
'free-for-all' that his proposal has potential to create :-)

2) Eastlake's draft I think goes further than we might want it to. It maps
between instances of usage of Content-Type: headers and URI references (with
query string and frag IDs). Granted, it provides a mapping for just the bare
media type as a degenerate case of a Content-Type header that carries no
parameters. However, I think it important to sort out distinctions between
class and instance (which I don't think is clear in the Eastlake draft).

3) It is evident from Graham Klyne's response[1] on the uriMediaType-9
thread, that the IETF are embarked the definition of a framework for URN
based naming of IETF defined protocol parameters. This potentially includes
parameters of mime media-types used in content-type headers and potential
mime media-types themselves.

Regards

Stuart

[1] http://lists.w3.org/Archives/Public/www-tag/2002Feb/0055.html
[2] http://www.ietf.org/internet-drafts/draft-mealling-iana-urn-02.txt