Re: IRIs, IDNAbis, and HTTP

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/