Re: ACTION-472: New Mime-web-info draft

Eric J. Bowman wrote:
> Nathan wrote:
>> Thus, a media type would always be identified by a URI, and when 
>> referring to a media type one could use the token for registered 
>> types, and full URI for unregistered.
>>
> 
> Just to point out again, there's no such thing as an "unregistered
> media type"; there are strings which *are* media types, as they appear
> in the registry, and there are strings which *are not* media types, as
> only what appears in the registry is, by definition, a media type.  So
> a URI will never be a media type, because media types aren't first-
> class objects (they're registry entries).

Ahh this is a familiar discussion! well reminded.

> Allowing URIs as tokens will immediately result in Content-Type
> referring to data types, instead of processing models, by insinuating
> that media types are first-class objects on the network.  As Web
> architecture stands, media types simply don't work like that, so they
> can't be assigned URIs.  What processing model is described by this?
> 
> Content-Type: http://tools.ietf.org/html/rfc3023
> 
> Even if you give a media type a URI, since media types aren't first-
> class objects, it will always be just as ambiguous as using the URI of
> the data type.  Unless the entire existing system is scrap-heaped and
> rewritten such that media type definitions like RFC 3023 are only
> allowed to reference one media type, or change things such that data
> types have 1:1 identifiers instead of being part of a family -- except I
> thought the purpose here was fixing the registry, not re-architecting
> the Internet.  ;-)

Yes, good point well said :)

> The best way to make the problem of *anything* appearing in Content-
> Type _worse_, is to allow URIs as tokens, since that requires media
> types to be recast as first-class objects -- which they're not.

Aye, and I guess classing some URIs as "media types" based on the 
first x chars of the lexical form of the URI would not be a good idea 
(Opacity and all).

Best,

Nathan

Received on Monday, 31 January 2011 20:22:48 UTC