Subject: [hybi] draft-10: ABNF error in section 9.1

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Aug 2011 14:31:20 +0200

------------------------------------------------------------
9.1.  Negotiating Extensions

         extension-list = 1#extension
         extension = extension-token *( ";" extension-param )
         extension-token = registered-token / private-use-token
         registered-token = token
         private-use-token = "x-" token
         extension-param = token [ "=" token ]

   Note that like other HTTP headers, this header MAY be split or
   combined across multiple lines.  Ergo, the following are equivalent:

         Sec-WebSocket-Extensions: foo
         Sec-WebSocket-Extensions: bar; baz=2

   is exactly equivalent to

         Sec-WebSocket-Extensions: foo, bar; baz=2
-----------------------------------------------------------------------------

The examples are wrong since the defined ABNF grammar does NOT allow a
space before the ";" (for the extension-param).

Correct syntax:

        Sec-WebSocket-Extensions: bar;baz=2
        Sec-WebSocket-Extensions: foo, bar;baz=2

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 16 Aug 2011 22:04:23 +0900

My understanding is that they are "implied *LWS" of RFC2616 ABNF.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Aug 2011 15:13:57 +0200

> My understanding is that they are "implied *LWS" of RFC2616 ABNF.

Not al all. The full grammar is described in the WS draft:

And there is no LWS at all. If LWS is allowed then the following line:

should become:

  extension = extension-token *( SEMI" extension-param )

taking into account that:

  SEMI  = SWS ";" SWS;
  SWS  = LWS?;

The ABNF grammar in section 9.1 is just wrong, sure.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Aug 2011 15:15:26 +0200

>  extension = extension-token *( SEMI" extension-param )

Sorry:

 extension = extension-token *( SEMI extension-param )

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 17 Aug 2011 18:27:09 +0900

So, the problem is that seeing this sentence, it's not very clear how much
grammar (all or only some rules from them) is borrowed from RFC2616. (Just
IMO, it's natural to think that we should take into account all of RFC2616
section 2.)

"this section is using ABNF syntax/rules from [RFC2616]"

LWS, CHAR, CTL, separator, etc. are in the dependency tree from the rules
that appear in the WebSocket spec section 9.1 (#rule, *rule, etc.), but
implied *LWS rule is out of the dependency tree. Changing the text to

"this section is using ABNF syntax/rules from [RFC2616] including "implied
*LWS" rule"

would be better? I'm fine with this.

----

I just found existing thread where this is discussed.
http://www.ietf.org/mail-archive/web/hybi/current/msg07728.html
http://www.ietf.org/mail-archive/web/hybi/current/msg07729.html
http://www.ietf.org/mail-archive/web/hybi/current/msg07730.html (your post)
http://www.ietf.org/mail-archive/web/hybi/current/msg07737.html

I agree that we should just inherit all the grammar defined in RFC2616
section 2 to interpret the extension header.

Thanks,
Takeshi

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Aug 2011 10:33:19 +0100

Takeshi Yoshino wrote:

> So, the problem is that seeing this sentence, it's not very clear how 
> much grammar (all or only some rules from them) is borrowed from 
> RFC2616. (Just IMO, it's natural to think that we should take into 
> account all of RFC2616 section 2.)
>
> LWS, CHAR, CTL, separator, etc. are in the dependency tree from the 
> rules that appear in the WebSocket spec section 9.1 (#rule, *rule, 
> etc.), but implied *LWS rule is out of the dependency tree. Changing 
> the text to
>
> "this section is using ABNF syntax/rules from [RFC2616] including 
> "implied *LWS" rule"

Actually, I've already done this in my copy of -11-to-be.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 17 Aug 2011 11:33:52 +0200

> would be better? I'm fine with this.

Honestly I didn't know the "implied *LWS" rule in RFC 2616, but indeed
it exists:

   implied *LWS
      The grammar described by this specification is word-based. Except
      where noted otherwise, linear white space (LWS) can be included
      between any two adjacent words (token or quoted-string), and
      between adjacent words and separators, without changing the
      interpretation of a field. At least one delimiter (LWS and/or
      separators) MUST exist between any two tokens (for the definition
      of "token" below), since they would otherwise be interpreted as a
      single token.

What to say, I don't like it. An ABNF grammar should not require other
text interpretation. For example, SIP protocol inherits from HTTP (SIP
messages are very similar to HTTP messages) but the ABNF grammar in
RFC 3261 (SIP) implies *nothing*. In fact it defines the following
elements:

      STAR    =  SWS "*" SWS ; asterisk
      SLASH   =  SWS "/" SWS ; slash
      EQUAL   =  SWS "=" SWS ; equal
      LPAREN  =  SWS "(" SWS ; left parenthesis
      RPAREN  =  SWS ")" SWS ; right parenthesis
      RAQUOT  =  ">" SWS ; right angle quote
      LAQUOT  =  SWS "<"; left angle quote
      COMMA   =  SWS "," SWS ; comma
      SEMI    =  SWS ";" SWS ; semicolon
      COLON   =  SWS ":" SWS ; colon
      LDQUOT  =  SWS DQUOTE; open double quotation mark
      RDQUOT  =  DQUOTE SWS ; close double quotation mark

and the rest of the grammar use them (in some cases in which LWS is allowed).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 17 Aug 2011 11:37:02 +0200

> Actually, I've already done this in my copy of -11-to-be.

In some aspects, WS draft seems oriented to people with no knowledge
in HTTP (or in RFC 2616 more precisely), so I would not rely in
references to sections in RFC 2616.

I strongly prefer avoiding RFC-2616's "implied *LWS" in websocket
draft. Making the ABNF grammar strict is much better for implementors.

-- 
Iñaki Baz Castillo
<[email-masked]>