W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: IRIs, IDNAbis, and HTTP

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 14 Mar 2008 20:49:17 +1100
Cc: Martin Duerst <duerst@it.aoyama.ac.jp>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org
Message-Id: <AC6F183E-3AF4-4A6B-B88E-C436C17DD203@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

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:


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