- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Wed, 26 Dec 2007 10:10:41 -0500
- To: Martin Dürst <duerst@it.aoyama.ac.jp>
- Cc: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, ietf-types@alvestrand.no, ietf-http-wg@w3.org
- Message-ID: <20071226151041.GC5331@w3.org>
* Martin Dürst <duerst@it.aoyama.ac.jp> [2007-12-26 10:29+0900] > At 00:45 07/12/19, Frank Ellermann wrote: > >Julian Reschke wrote: > > > >> there's also RFC2616 > > > >Yes, that's an ugly legacy exception... > > > >> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i20> > > > >...maybe 2616bis can drop this oddity in favour of a simple > >"unknown text is ASCII" rule. > > The new version of the HTTP spec, 2616bis, should definitely > drop the iso-8859-1 default, but NOT in favor of "unknown text is ASCII". > It should just say that there is no default. > There is a big difference between these two, especially > for document formats that contain internal 'charset' information. > A default of US-ASCII makes document-internal 'charset' information > useless (because the external information wins). No default means > that the recipient will look at the internal information. I'm fuzzy on the logic here. It seems one of the big values of text/ tree is that you know the browser will render it on the screen if it doesn't know anything about the subtype. How then will it know where to look for internal charset info? (By the same token, how then will it know what the default charset is for the mystery media type?) Don't get me wrong, I'm ok with the browser making a guess and the user overriding it. In fact, I'd like to see the first guess be utf-8 if the stream appears to be valid utf-8. And if it's really shift-JIS or utf-16, you'll get some funny looking chars (hopefully the browser won't be sensitive to misinterpreting something as "^drm -r /"). Are we on the cusp of a new HTTP1.1 draft? May I register media types that pre-empt that this a little in favor of doing the right thing? > >HTTP oddities shouldn't affect > >MIME registrations, there's no string "2616" in BCP13. > > One reason for the problems with text/xml was that the > original MIME default of US-ASCII was enforced. This made > it impossible to serve XML documents with internal 'charset' > information only as text/xml. > > Regards, Martin. > > > #-#-# Martin J. Dürst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp -- -eric office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA mobile: +1.617.599.3509 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.
Received on Wednesday, 26 December 2007 15:11:22 UTC