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

media types could be defined in such a way to support both registries 
and extensible URIs.

For example, a registry could be setup whereby registered and 
standardized types could be passed as tokens of the current format 
'text/foo', which would relate to an identifier by concatenating that 
value to a base uri, such that:

   'text/foo' is concatenated to 
'http://www.iana.org/assignments/media-types/' to create the URI 
'http://www.iana.org/assignments/media-types/text/foo', where an HTTP 
GET on this URI would redirect to the relevant standard, if a 404 is 
received then the type is not registered.

This would allow for a registry to be kept, and located at 
http://www.iana.org/assignments/media-types/ with lists for specific 
trees at the existing URIs, like 
http://www.iana.org/assignments/media-types/text/.

Further, it would allow URIs to be used for unregistered types, thus 
making for an extensible, unconstrained web.

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.

Best,

Nathan

Eric J. Bowman wrote:
> Exactly.  The Content-Type header can contain *anything*, so there
> needs to be some list of tokens which are officially recognized as
> media types, which correspond to processing models which have been
> vetted by peer review (particularly for security considerations, which
> requires a trust model).
> 
> If we used URIs, we'd still need some sort of list of those URIs which
> actually point to conforming media type definitions, which correspond
> to processing models which have been vetted by peer review (also to
> prevent naming collisions, like with application/rss+xml).  But, URIs
> are too opaque, preventing us from knowing at a glance whether the
> payload is an image, or an XML derivative, etc.
> 
> So, if we do away with the registry in favor of URIs, how do I know
> that the URI I'm looking at actually resolves to a document that
> defines a media type?  Whose word can I take as to the security
> considerations, aside from the author?  If the URI points to multiple
> processing models, how do I know which one to choose?  How can I search
> for all XML-derived media types?
> 
> What it comes down to is this:  If you're going to have headers in a
> protocol, you're going to need registries, because you'll never prevent
> folks from sending *anything*, or prevent other folks from needing to
> know whether *anything* is valid.
> 
>> Surely we could just use the URI of the spec (dated/versioned)?
>>
> 
> No, because data-type identifiers aren't processing models.  What's the
> processing model for this spec, and how would I express an intent that
> it be processed as plaintext?
> 
> http://www.w3.org/TR/xhtml1/
> 
> Some sort of token representing a processing model that applies to one
> or more *families* of data types, is required by the architecture.  I'm
> not in favor of any proposed alternative to the registry, which removes
> the feature of being able to send HTML as plaintext -- do you see how
> bypassing media types in favor of links to data formats, winds up being
> a different architecture altogether?
> 
> I could go on for, well, months apparently...
> 
> -Eric
> 
> ashok malhotra wrote:
>> I believe a registry implies some oversight.
>> All the best, Ashok
>>
>> Jonathan Rees wrote:
>>> Nathan wrote:
>>>> This is possibly a stupid question, but why even have a registry,
>>>> surely we could just use the URI of the spec (dated/versioned)?
>>> Not a stupid question at all.  The TAG even has a name for the
>>> question: ISSUE-50. (Oddly, the issue's home page has a URI, but the
>>> issue itself doesn't have a URI.)
>>>
>>> Jonathan
>>>
> 
>

Received on Monday, 31 January 2011 11:28:53 UTC