- From: <noah_mendelsohn@us.ibm.com>
- Date: Mon, 2 Mar 2009 04:33:19 -0500
- To: Dan Connolly <connolly@w3.org>
- Cc: public-w3c-ietf@w3.org, www-tag@w3.org
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