W3C home > Mailing lists > Public > public-ietf-w3c@w3.org > September 2003

Re: suggestion re: media type registration

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 12 Sep 2003 14:06:51 -0700
Cc: public-ietf-w3c@w3.org
To: "Roy T. Fielding" <fielding@apache.org>
Message-Id: <07B4DC0E-E565-11D7-BD3E-00039396E15A@mnot.net>

On Friday, September 12, 2003, at 01:56  PM, Roy T. Fielding wrote:
>> Has the W3C considered a policy of registering media types in the 
>> vnd. tree? E.g.,
>>   application/vnd.w3c.soap+xml
>> It seems to me that this may help avoid some of the delays and 
>> overhead with registration in the IETF tree*, and would encourage use 
>> of the vnd. and prs. trees by example, so that people wouldn't be 
>> prejudiced against them.
> I personally hate the vnd and prs trees -- it promulgates the same 
> failed
> design as the x- prefixes.  A reversed dns prefix would at least have
> made some sense.

Aha; interesting you mention that. I have an I-D written and ready to 
go for it, but have been holding off because of mixed private feedback. 
Do you *like* this approach, or just dislike it less than vnd/prs?

> As for the +xml types, a more effective mechanism would have been to
> define a major type of xml under the namespace control of W3C, or
> barring that an xml tree (application/xml.soap) which could either
> be assigned to the W3C or at least incorporate the W3C process.
> That would, of course, require an RFC to set up.  The +xml suffix
> seems to beg for the most delays.

One suggestion I've heard is to have an xml media type registration 
that allows an attribute to describes either an opaque intent URI or 
the namespace URI of the top-level element; e.g.,
(the alternative is to change application/xml itself, but that would be 
more difficult process-wise)

The problem that I see with this approach is that some (most?) MIME 
dispatchers can't do anything with parameters, as explained in the 
appendix of 3023. Still would be interesting to have the alternative, 
Received on Friday, 12 September 2003 17:08:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:09:27 UTC