- From: Sean B. Palmer <sean@miscoranda.com>
- Date: Mon, 17 Dec 2007 17:38:13 +0000
- To: "Garret Wilson" <garret@globalmentor.com>
- Cc: "Eric Prud'hommeaux" <eric@w3.org>, ietf-types@iana.org, "Tim Berners-Lee" <timbl@w3.org>, "Daniel W. Connolly" <connolly@w3.org>, "Dave Beckett" <dave@dajobe.org>, "Lee Feigenbaum" <lee@thefigtrees.net>, "Graham Klyne" <GK@ninebynine.org>, "Dan Brickley" <danbri@danbri.org>, www-archive@w3.org
On Dec 17, 2007 4:15 PM, Garret Wilson <garret@globalmentor.com> wrote: > My literal reading of RFC 2046 (which may not be correct) led > me to believe that this only applied to text/plain. Aha, I understand your reading now. I took it as having used text/plain merely as an example, and to be talking about the whole text branch: these quotes are from 4.1. Text Media Type -> 4.1.2. Charset Parameter, whereas text/plain is defined later on in 4.1.3. Plain Subtype. The "pay close attention to the implications of multioctet character sets" part goes the other way, however, and for me speaks most strongly in defence of your reading; but either way: "Semanticists should be obstetricians, not coroners of programming languages." - John Reynolds, via James Clark [1] > In fact, I could easily be persuaded just to ignore the US-ASCII > and CRLF parts if everyone else were to do the same. I'd be happy with that too. The only issue for me is whether interpreting utf-8 as US-ASCII would cause any security issues or serious damage anywhere, because as you say, people have taken RFC 2046 as mandating US-ASCII for non-charset-parametered text/*. > The problem with the computer standards process is that it has > gotten so bureaucratic and slow [...] I applaud anyone that would > push for a new RFC to update RFC 2046 Yes, and yes. > I'd prefer that either application/* were used, or the RFC 2046 > default character set were ignored. I'd prefer that text/* were used as intended, not that we continue to be coroners of RFC 2046. RFC 2046 was looking forward to a time where there would be a universal character encoding, and utf-8 is what it wished for. It seems wrong that RFC 2046 should then prevent utf-8 from being deployed! And as for CRLF, it doesn't seem like anybody cares about that at all. 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. [1] http://lists.xml.org/archives/xml-dev/200201/msg00155.html -- Sean B. Palmer, http://inamidst.com/sbp/
Received on Monday, 17 December 2007 17:38:22 UTC