Re: "Content-Type Processing Model" draft 9 Jan (ISSUE-24 contentTypeOverride-24)

I'm probably missing something obvious:  is there any reason that if 
sniffing is to be formally "blessed" at the protocol level, rather than 
tolerated (and perhaps carefully specified) as a browser kludge, that it 
wouldn't be better to update the specifications for the affected media 
types rather than changing HTTP.  So, the text/html media type 
registration would say something unappealing like:

"text/html is properly used for documents conforming to [whichever HTML 
specification(s) we want to point to].  Widely deployed user agents, 
especially browsers, often accept additional content that is not 
conforming text/html, "sniffing" the content to infer some other media 
type to be used.  To promote interoperability in situations where such 
sniffing is necessary, the following rules should be used.  User agents 
operating in such a sniffing mode are not conformant with the text/html 
media type, but should be described as operating in "text/html sniffing 
mode".  The detailed rules for sniffing content labeled as text/html would 
then be provided.

It's still ugly, but it seems to me that it's putting the logic in the 
right place.  After all, as drafted, neither the HTML 5 working draft nor 
the Barth & Hickson draft provides generalized support;  when new types 
are to be sniffed explicit rules must be added.  If that's the case, why 
not leave HTTP itself "pure", and put the kludges in with the affected 
media type specifications?  I think that's actually a pretty true 
reflection of what's going on:  HTTP in general is working just fine; 
certain media types are being used sloppily.  Am I missing something?

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Monday, 2 March 2009 09:34:11 UTC