- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 07 Nov 2010 09:33:14 +0100
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: Mark Nottingham <mnot@mnot.net>, httpbis Group <ietf-http-wg@w3.org>
On 07.11.2010 02:53, Bjoern Hoehrmann wrote: > * Mark Nottingham wrote: >> According to<http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#section-3.2>: >> >>> Historically, HTTP has allowed field content with text in the ISO- >>> 8859-1 [ISO-8859-1] character encoding and supported other character >>> sets only through use of [RFC2047] encoding. In practice, most HTTP >>> header field values use only a subset of the US-ASCII character >>> encoding [USASCII]. Newly defined header fields SHOULD limit their >>> field values to US-ASCII characters. Recipients SHOULD treat other >>> (obs-text) octets in field content as opaque data. >> >> I don't see what not specifying the character set that doesn't require encoding buys us here. > > I think this issue can be closed; I think the document has been changed > to my satisfaction. (I do note that there is some slight inaccuracy in > the text you cite and the Content-Disposition draft: if the filename > value is a `token` instead of a quoted string, RFC 2616 does not define > the encoding of the token to be ISO-8859-1; the ISO-8859-1 language is > for words of TEXT, which are in comments in quoted strings only.) True, but token doesn't allow anything outside USASCII anyway, right? Best regards, Julian
Received on Sunday, 7 November 2010 08:33:52 UTC