- From: Anne van Kesteren <annevk@opera.com>
- Date: Sun, 01 Apr 2007 13:34:14 +0200
- To: "Web API WG (public)" <public-webapi@w3.org>
On Sun, 01 Apr 2007 03:53:16 +0200, Asbjørn Ulsberg <asbjorn@ulsberg.no> wrote: > On Wed, 21 Mar 2007 12:29:09 +0100, Anne van Kesteren <annevk@opera.com> > wrote: > >> Personally I would like to have things for XMLHttpRequest work >> similarly to other content (not fetched through XMLHttpRequest), but it >> seems this might be tricky to get right. > > It is indeed tricky, especially considering RFC-3023 and the 'text/*' > media types. A lot of 'text/*' content on the web breaks RFC-3023 and > RFC-2046, and discussions on the Atom mailing list concluded (at least > for me) that those specifications needs to be disregarded, at least for > all XML media types. This issue is not about the imo bogus part of RFC3023 that says that text/xml without a charset parameter must be treated as if US-ASCII was specified. I'll just assume that in due course we'll have a more sensible specification that says to treat text/xml identically to application/xml. Especially given how widely deployed text/xml is versus application/xml. > [...] > > Defaulting to anything but iso-8859-1 or UTF-8 on the web today doesn't > make much sense, especially not US-ASCII. It made sense in the 80's, but > doesn't any more and I strongly believe disregarding RFC-2046 in this > regard is the right thing to do, since the compatibility of existing > MIME parsers isn't a concern the XHR specification needs to take. This is not the problem though. I'm not sure which part of my original e-mail led you to think it is. > It's an interesting discussion, though, and I would love to see a global > and final conclusion on the matter, not just applying to XHR or Atom. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Sunday, 1 April 2007 11:34:24 UTC