- From: Mark Nottingham <mnot@yahoo-inc.com>
- Date: Fri, 3 Feb 2006 09:49:33 -0800
- To: Mark Baker <distobj@acm.org>, Dan Connolly <connolly@w3.org>
- Cc: www-tag@w3.org
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 necessary. 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). Cheers, On 2006/02/02, at 8:23 PM, Mark Baker wrote: > > On 2/2/06, Dan Connolly <connolly@w3.org> 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 mnot@yahoo-inc.com
Received on Friday, 3 February 2006 22:29:01 UTC