- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 14 Mar 2008 20:49:17 +1100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Martin Duerst <duerst@it.aoyama.ac.jp>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org
Personally, I am *very* -1 on doing this. Changing the allowable characters in a protocol element is a *big* change, and there is not an interoperability gain to doing so. There is also not a functionality gain; it is possible (if not pretty) to serialise other characters into HTTP headers. Furthermore, HTTP headers for the most part don't carry user-visible data, and when they do, it's often an IRI, for which there is a well- understood serialisation into header-safe characters. Before we go too far down this path again, folks should refresh themselves with the last round of discussion, starting at: http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/0323.html Cheers, On 14/03/2008, at 8:36 PM, Julian Reschke wrote: > > Martin Duerst wrote: >> ... >> It may be difficult to fix the truely horrible RFC 2047 on top of >> iso-8859-1 mess for existing headers. But in order to move in the >> right direction, it would be a very good idea to allow newly defined >> headers to specify that they just use UTF-8. >> ... > > That's related to <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/74 > >. > > This really sounds like the simplest way to do it -- if this applies > only to new headers, is there even a remote chance of breaking > something? > > BR, Julian > -- Mark Nottingham http://www.mnot.net/
Received on Friday, 14 March 2008 09:49:57 UTC