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
This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC