Just to make the picture a bit darker, I've realized that RFC 2616 for HTTP 1.1 is relevant. The good news: RFC 2616 section 3.7.1 says that, if text/* types are sent across HTTP, the CRLF requirement is relaxed and bare CRs and LFs are allowed. Good--that's what we wanted to do, anyway. The bad news: The same section says that if a text/* type is sent across HTTP with no charset parameter, it defaults to ISO-8859-1. This is nasty stuff, which is in part probably why application/xhtml+xml was chosen over text/xhtml+xml, the latter of which would *always* require a charset=utf-8 parameter. This is really heartbreaking. The same concerns appear: are we really going to build our future on ISO-8859-1 defaults? Soon no one is going to be shipping ISO-8859-1 text across the wire---and of what use will be the RFC 2616 default? Whatever we choose here, I'm sure that Firefox and IE will implement it differently... Garret Garret Wilson wrote: > Sean B. Palmer wrote: >> Perhaps, as Dan Connolly suggested on IRC, some civil disobedience of >> RFC 2046 is called for here--as long as we're sure that this won't >> cause any security or interoperability problems that would make it not >> worth the effort. >> > > I would wholeheartedly be in favor of that course, as long as we: > > * thoroughly document what we're doing, explaining why we're doing it; > * publicize what we're doing; and > * encourage others to follow suit. > > I don't think waiting for an RFC 2046 replacement would be productive, > but I also don't think it's helpful if we do this in some dark, > obscure corner. Let's do the Right Thing, yet try to get everyone to > follow. > > Garret >Received on Monday, 31 December 2007 02:11:56 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 July 2008 08:10:23 GMT