Re: registering formats in the web [uriMediaType-9] [Fwd: Request for MIME media type Application/Personal Tree - prs.]

IIRC, the problem with using a parameter for dispatch was that many/ 
most/all(?) known MIME dispatchers don't pass the parameters to the  
application. Appendix A of RFC3023 is a good read on these issues.

Personally, I'm not quite as eager to allow arbitrary formats be  
registered as I used to be. The registry acts as a brake on  
proliferation (as intended), and the issues around "what deserves its  
own media type" are tricky enough that some sort of review process is  

I should attribute at least some of the cause of this hesitation to  
the Microformats folks, who encourage reuse of existing formats and  
data models, rather than reinvention. I'm not completely convinced  
that this is the right approach for everything (in particular, at the  
element/statement level, depending on your data model of choice), but  
at the granularity of identifying/dispatching formats, it might be.

If we do go to the trouble of coming up with something that isn't  
compatible with the current MIME infrastructure (and that may be the  
best way out), it would probably be best to use a new header (e.g.,  
Content-Type-URI, although I'm sure somebody can come up with  
something better than that).


On 2006/02/02, at 8:23 PM, Mark Baker wrote:

> On 2/2/06, Dan Connolly <> wrote:
>> The idea is to migrate from a central registry of media types
>> to just using the web as a registry.
> You know I'm with you there. 8-)
>>> Are you perhaps thinking that the URI in the parameter could be used
>>> to dispatch applications?
>> Yes.
>>>   If so, I don't think that's workable as
>>> virtually all (AFAICT) software that dispatches off media types,  
>>> does
>>> it off the media type name independent of the value of any  
>>> parameters.
>> In such a dispatch slot, we insert a handler for t9 that dispatches
>> further.
> That seems a monumental undertaking to me, since as I see it, you'd
> have to upgrade all components (Web servers, browsers, intermediaries)
> simultaneously, otherwise you'd fragment the Web into two; those
> components that dispatch data processors off the media type name, and
> those that dispatch off the new parameter value.
> That's why I prefer mnot's proposal, as it accomodates that transition
> more gracefully IMO, by also modifying the media type name.
> Mark.

Mark Nottingham

Received on Friday, 3 February 2006 22:29:01 UTC