- From: Keith Moore <moore@cs.utk.edu>
- Date: Mon, 20 Aug 2007 09:03:51 -0400
- To: Martin Duerst <duerst@it.aoyama.ac.jp>
- CC: Mark Nottingham <mnot@mnot.net>, Richard Ishida <ishida@w3.org>, Apps Discuss <discuss@apps.ietf.org>, Felix Sasaki <fsasaki@w3.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Paul Hoffman <phoffman@imc.org>
>> also, I'll note that supporting utf-8 in a way that is backward >> compatible with existing implementations is almost certainly more >> complex (and thus more costly, error-prone, etc) than supporting rfc 2047. >> > > Well, if "backwards compatible" means also supporting RFC 2047, > of course it does mean that, as you're not going to get rid of the need to interoperate with the installed base of clients and servers anytime soon. > If the choice is between UTF-8 and RFC 2047, > however, then I'd take UTF-8 any time, because RFC 2047 includes > UTF-8 as well as many other encodings. if we had the luxury of starting from scratch, I'd agree with you. though my (fuzzy) memory seems to say that at the time HTTP was standardized lots of people insisted on using 8859-1 rather than either ASCII or any form of Unicode - again for backward compatibility reasons. but how much of a problem is this really?
Received on Monday, 20 August 2007 13:04:20 UTC