- From: =JeffH <Jeff.Hodges@KingsMountain.com>
- Date: Sat, 09 Jan 2010 14:40:09 -0800
- To: IETF HTTP WG <ietf-http-wg@w3.org>, Julian Reschke <julian.reschke@gmx.de>
Thanks for addressing this stuff Julian.
>> In Section 1.2.2 Basic Rules...
>>
>> > Many HTTP/1.1 header field values consist of words separated by
>> ^^^^^
>> tokens
>
> I don't think "token" would be correct here.
Here's my rationale: "word" is used only twice in
draft-ietf-httpbis-p1-messaging with respect to composition and parsing of
(header field) string values (both occurrences being in "1.2.2. Basic Rules"),
yet what constitutes a "word" in this context is not defined anywhere in the
spec, and seems superfluous. Tokens, however, are clearly defined in this
context, and the word "token" is a term of art in the text parsing discipline
(at least it was when I took my compilers class :)
>> > whitespace or special characters. These special characters MUST be
>> > in a quoted string to be used within a parameter value (as defined in
>> > Section 6.2).
>>
>> The "special characters" aren't mentioned anywhere in
>> draft-ietf-httpbis-p* spec set other than the above, nor are they
>> defined in ABNF. Inspection of draft-ietf-httpbis-p1 and RFC2616 reveals
>
> Yes. This happened when we rewrote the ABNF not to use "prose" rules
> anymore.
as I suspected.
> Unfortunately ABNF doesn't have syntax for something like "this
> set of characters, except for that other set".
yep.
> I have looked at this and decided to leave the prose alone for now. I
> changed the ABNF to:
>
> token = 1*tchar
>
> tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
> / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
> / DIGIT / ALPHA
> ; any VCHAR, except special
>
> special = "(" / ")" / "<" / ">" / "@" / ","
> / ";" / ":" / "\" / DQUOTE / "/" / "["
> / "]" / "?" / "=" / "{" / "}"
>
>
> (see <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/744>).
>
> This introduces an unused ABNF production, but I think that's ok for
> clarity.
oh, ok, cool, that works for me.
thanks,
=JeffH
Received on Saturday, 9 January 2010 22:40:38 UTC