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

Re: PROPOSAL: i74: Encoding for non-ASCII headers

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 28 Mar 2008 10:29:48 +0100
Message-Id: <90D6C16D-B29F-46BA-9227-DB8E4F78E6E1@greenbytes.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Mark Nottingham <mnot@mnot.net>


Am 28.03.2008 um 00:45 schrieb Mark Nottingham:
> Concretely, our options at this point are:
>
> 1) Change the character encoding on the wire to UTF-8

-1

Some people proposed to handle headers by just looking at the octets  
alone. While that is good advice to detect line ends and such, most  
HTTP client implementations *have to* convert the header names and  
values to "characters" since those are used in their own APIs and  
host languages.

> 2) Leave the character encoding on the wire at ISO-8859-1, document  
> existing TEXT instances' encoding requirements on top of that, and
>    a) Require new headers that need i18n content to specify  
> RFC2047, or
-1
ugly, no improvement

>    b) Require new headers that need i18n content to specify *some*  
> encoding into ISO-8859-1 using character escapes (which explicitly  
> MAY be RFC2047).

+1

My personal preference is to follow the AtomPub decision on the slug  
header encoding. If memory servers me right, there was a lot of  
fruitful discussion about it and opinions asked from asians  
implementors that finally resulted in the encoding adopted.
(See RFC 5023 ch. 9.7.1)

//Stefan

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782
Received on Friday, 28 March 2008 09:30:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT