- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 28 Mar 2008 20:17:52 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote:
>
> * p1, 2.2:
> Old:
>> The TEXT rule is only used for descriptive field contents and values
>> that are not intended to be interpreted by the message parser. Words
>> of *TEXT MAY contain characters from character sets other than ISO-
>> 8859-1 [ISO-8859-1] only when encoded according to the rules of
>> [RFC2047].
>> TEXT = %x20-7E | %x80-FF | LWS
>> ; any OCTET except CTLs, but including LWS
>> A CRLF is allowed in the definition of TEXT only as part of a header
>> field continuation. It is expected that the folding LWS will be
>> replaced with a single SP before interpretation of the TEXT value.
>
>
> New:
> """
> Words of *TEXT MUST NOT contain characters from character sets other
> than ISO-8859-1 [ISO-8859-1].
>
> TEXT = %x20-7E | %x80-FF | LWS
> ; any OCTET except CTLs, but including LWS
>
> A CRLF is allowed in the definition of TEXT only as part of a header
> field continuation. It is expected that the folding LWS will be
> replaced with a single SP before interpretation of the TEXT value.
>
> Characters outside of ISO8859-1 MAY be included where the encoded-word
> rule (as defined in RFC2047, Section 2) is specified. The encoded-word
> rule is only used for descriptive field contents and values that are not
> intended to be interpreted by the message parser. When used in HTTP,
> encoded-word has no specified length limit.
> """
>
> One question to consider here -- should %x80-%x9F be included in TEXT?
> They don't fall into the syntactic definition of CTLs in 2616, but the
> are semantically control characters, AFAIK.
I think it would be the right thing to forbid them.
> * p1, 2.2:
> Old:
>> comment = "(" *( ctext | quoted-pair | comment ) ")"
>
>
> New:
> """
> comment = "(" *( ctext | quoted-pair | comment | encoded-word ) ")"
> """
OK, but then we'll have to state somewhere where encoded-word comes
from; <http://tools.ietf.org/html/rfc2047#section-2>?
Also, do we really Really REALLY want to require to support all what's
in there?
> * p1, 4.2:
> Old:
>> field-content = <field content>
>> ; the OCTETs making up the field-value
>> ; and consisting of either *TEXT or combinations
>> ; of token, separators, and quoted-string
>
> New:
> """
> field-content = <field content>
> ; the OCTETs making up the field-value,
> ; consisting of either *TEXT or combinations
> ; of token, separators, quoted-string and encoded-word,
> ; according to the syntax specified by the field.
> """
I prefer the simplified version you posted later:
field-content = <field content>
; the OCTETs making up the field-value,
; according to the syntax specified by the field.
> * p3, B.1:
> Old:
>> filename-parm = "filename" "=" quoted-string
>
> New:
> """
> filename-parm = "filename" "=" quoted-string | encoded-word
> """
I'd prefer to make C-D a special case where we specify *exactly* what's
needed, nothing more (which means: RFC2231 encoding of utf-8, no line
folding/contiuation lines).
> * p6, 16.6:
> Old:
>> warn-text = quoted-string
> New:
> """
> warn-text = quoted-string | encoded-word
> """
>
>
> Note that I have NOT suggested the use of encoded-word in the following
> places:
>
> p1, 3.4 (Transfer Codings -- parameter values), p1, 6.1.1
> (Reason-Phrase), p2, 10.2 (expect-extensions), p3, 3.3 (Media Types --
> parameter values), p3, 6.1 (accept-extension), p4, 3 (ETag opaque-tag),
> p6, 16.2 (cache-extension), p6, 16.4 (extension-pragma).
OK, except probably for Reason-Phrase.
> I think the *-extension and parameter value ones are straightforward; if
> a particular extension wants to specify use of encoded-word, it should;
> we shouldn't specify use of encoded-word in the generic extension
> construct, but leave it to the specific instances.
Yes.
> I don't see a use case for ETags being internationalised -- does anyone
> else? Reason-Phrase may be necessary, though.
No. Yes.
> Also, I haven't addressed From (p2, 10.3). Anybody want to take a stab
> at that?
BR, Julian
Received on Friday, 28 March 2008 19:18:40 UTC