- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Fri, 28 Mar 2008 10:29:48 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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 UTC