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
