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, NathanReceived on Monday, 31 January 2011 20:22:48 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:30 GMT