Subject: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.txt

From: [email-masked]
Date: Tue, 23 Aug 2011 03:27:13 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF.

	Title           : The WebSocket protocol
	Author(s)       : Ian Fette
                          Alexey Melnikov
	Filename        : draft-ietf-hybi-thewebsocketprotocol-11.txt
	Pages           : 68
	Date            : 2011-08-23

   The WebSocket protocol enables two-way communication between a client
   running untrusted code running in a controlled environment to a
   remote host that has opted-in to communications from that code.  The
   security model used for this is the Origin-based security model
   commonly used by Web browsers.  The protocol consists of an opening
   handshake followed by basic message framing, layered over TCP.  The
   goal of this technology is to provide a mechanism for browser-based
   applications that need two-way communication with servers that does
   not rely on opening multiple HTTP connections (e.g. using
   XMLHttpRequest or &lt;iframe&gt;s and long polling).

   Please send feedback to the [email-masked] mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-11.txt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 Aug 2011 11:33:55 +0100

>	Filename        : draft-ietf-hybi-thewebsocketprotocol-11.txt
This version addresses most of the Gen-Art/SecDir/IETF LC issues 
presented in Quebec City, with the exception of:
1). Updated Security Considerations
2). Better explanation of the purpose of masking
3). x-<extension> namespace
4). Frame too big and extensibility clarification issues.
5). addition of text about exponential back-off

Note that the Acknowledgments section was updated, but it is not yet 
complete yet. I still have some emails on the subject to process/reply to.

I might post -12 today or later this week. The only type of change that 
would be present in -12 is moving sections around to improve readability 
of the document.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 24 Aug 2011 04:41:53 +0900

Hi Alexey,

I have some questions about section 5.2.2. and 5.3.

----

implied WSP rule -> implied LWS rule ?

----

Are
Sec-WebSocket-Protocol-Client, Sec-WebSocket-Version-Client,
Sec-WebSocket-Protocol-Server, Sec-WebSocket-Version-Server
just names of ABNF rules?

i.e. Sec-WebSocket-Protocol-Client is the grammar for the right hand side of
the Sec-WebSocket-Protocol header in client handshake?

----

It seems header name and colon are missing from rules. e.g.

Sec-WebSocket-Accept     = base64-value

The left hand side was accept-value in -10 and the line seemed to be
defining the grammar of the right hand side of the Sec-WebSocket-Accept
data. So, just base64-value was fine. But now, maybe you've tried to give
grammar for full header line as RFC 2616 does and follow its style like
       Accept         = "Accept" ":"
                        #( media-range [ accept-params ] )
so, this should be

Sec-WebSocket-Accept     = "Sec-WebSocket-Accept" ":" base64-value

----

This ABNF doesn't cover 1, 2, ... 99
            version = "0" | ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT)
                       ; 0-255

----

Maybe "1#" here is typo.
Sec-WebSocket-Version-Server = 1#version

----

Thanks,

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 Aug 2011 22:56:15 +0100

> Hi Alexey,

Hi Takeshi,

> implied WSP rule -> implied LWS rule ?

Yes. It might have been called different things in different IETF RFCs, 
but I will double check and use the right term.

> ----
>
> Are 
> Sec-WebSocket-Protocol-Client, Sec-WebSocket-Version-Client, Sec-WebSocket-Protocol-Server, Sec-WebSocket-Version-Server 

Yes. The suffix "-Client" means that the syntax is used in HTTP requests 
(C->S), the suffix "-Server" means that the syntax is used in HTTP 
responses.

> i.e. Sec-WebSocket-Protocol-Client is the grammar for the right hand 
> side of the Sec-WebSocket-Protocol header in client handshake?

Yes.

> defining the grammar of the right hand side of the 
> Sec-WebSocket-Accept data. So, just base64-value was fine. But now, 
> maybe you've tried to give grammar for full header line as RFC 2616 
> does and follow its style like
>        Accept         = "Accept" ":"

I suggest we do whatever RFC 2616 is doing. I will double check.

>            version = "0" | ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT)

Sigh, you are right, this needs to be fixed to match the comment.

> Sec-WebSocket-Version-Server = 1#version

No typo here, this matches the text elsewhere in the document: the 
server advertises all versions it supports.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 24 Aug 2011 11:14:24 +0900

On Wed, Aug 24, 2011 at 06:56, Alexey Melnikov <[email-masked]>wrote:

> No typo here, this matches the text elsewhere in the document: the server
> advertises all versions it supports.
>

I overlooked the change. Thanks.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Aug 2011 12:21:33 +0200

On 2011-08-23 23:56, Alexey Melnikov wrote:
> ...
> ...

I strongly suggest to do what HTTPbis is doing; just specify the ABNF 
for the field *value*.

 > ...

Best regards, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 24 Aug 2011 12:23:42 +0100

> I strongly suggest to do what HTTPbis is doing; just specify the ABNF 

I am happy with that, because this means I don't need to change anything 
;-).
'

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 24 Aug 2011 23:21:48 +0900

On Wed, Aug 24, 2011 at 20:23, Alexey Melnikov <[email-masked]>wrote:

>> I strongly suggest to do what HTTPbis is doing; just specify the ABNF for
>> the field *value*.
>
>
Thanks Julian. I just took a look at HTTPbis docs.

So, the WebSocket spec points RFC 2616 but uses ones in HTTPbis? I think
it's not friendly for readers. What's the plan for final publish? Will the
reference be replaced with HTTPbis?

e.g. I'm fine with keeping "WSP" instead of "LWS" as HTTPbis defines, but
one cannot find "WSP" in RFC 2616 referred from the sentence.

> ;-).'

OK. But if you do so, I'd suggest that we clarify what *-Client and *-Server
means or remove those suffixes since the context (talking about S->C or
C->S) is clear (separated into two paragraphs). It's clear if they were
embedded in main text like Sec-WebSocket-Accept ABNF in the section
5.2.2.-3.-4. But they're not referred from any sentence but just appears
suddenly in the section 5.3. It's confusing. Sounds like header names are
Foo-Client and Bar-Server.

Thanks,
Takeshi

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Aug 2011 16:43:25 +0200

On 2011-08-24 16:21, Takeshi Yoshino wrote:
> On Wed, Aug 24, 2011 at 20:23, Alexey Melnikov
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Julian Reschke wrote:
>
>         I strongly suggest to do what HTTPbis is doing; just specify the
>         ABNF for the field *value*.
>
>
> it's not friendly for readers. What's the plan for final publish? Will
> the reference be replaced with HTTPbis?

...that would imply waiting for HTTPbis; I doubt the WG wants to do this.

My recommendation is to use RFC2616 grammar constructs, but follow the 
HTTPbis style of only defining the ABNF for the header value.

Best regards, Julian

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 24 Aug 2011 16:12:26 +0000

Agree with Julian. We cannot have a normative reference to HTTPbis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Julian Reschke
> Sent: Wednesday, August 24, 2011 07:43
> To: Takeshi Yoshino
> Cc: [email-masked]
> Subject: Re: [hybi] header field ABNF, was: I-D Action: draft-ietf-hybi-
> thewebsocketprotocol-11.txt
> 
> > So, the WebSocket spec points RFC 2616 but uses ones in HTTPbis? I
> > think it's not friendly for readers. What's the plan for final
> > publish? Will the reference be replaced with HTTPbis?
> 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 24 Aug 2011 11:41:11 -0600

> Agree with Julian. We cannot have a normative reference to HTTPbis.

Well, we could, but we don't want to. :-) If we did, the Websocket spec
wouldn't be published until the HTTPbis specs are published (probably
sometime in 2012 if all goes well). We'll be hard at work on WS 1.1 by
then. ;-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 25 Aug 2011 04:15:39 +0900

Thanks. I also don't want any more delay. I'm fine that HTTPbis is not
referred. Then, things we can refer are ones defined in RFC2616.

- Making style, organization consistent with HTTPbis (e.g. use of
Header-Name = grammar_for_value style) is no problem.
- Using any term, identifier, grammar, etc. not in RFC2616 but in HTTPbis is
bad. WebSocket spec should define them in itself.

That's all.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 25 Aug 2011 04:22:54 +0900

> HTTPbis style of only defining the ABNF for the header value.

Agreed. Thanks.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 30 Aug 2011 11:18:25 +0100

> implied WSP rule -> implied LWS rule ?

Changed "implied WSP" to "implied *LWS" as per RFC 2616.

> side of the Sec-WebSocket-Protocol header in client handshake?

I think I've clarified this by the following new text:

    (for example the Sec-WebSocket-Key ABNF rule describes the 
Sec-WebSocket-Key
    header field).
    <t>Note that the following ABNF conventions are used in this section:
    Some names of the rules correspond to names of the corresponding 
header fields
    Such rules express values of the corresponding header fields, for 
example
    the Sec-WebSocket-Key ABNF rule describes the Sec-WebSocket-Key
    header field.

    ABNF rules with the "-Client" suffix in the name are only used in 
requests sent
    by the client to the server; ABNF rules with the "-Server" suffix in 
the name
    are only used in responses sent by the server to the client. For 
example,
    the ABNF rule Sec-WebSocket-Protocol-Client describes syntax of the
    Sec-WebSocket-Protocol header field sent by the client to the server.
    </t>

>            version = "0" | ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT)

I think I got it right this time:

            NZDIGIT       =  "1" / "2" / "3" / "4" / "5" / "6" /
                             "7" / "8" / "9"
            version = DIGIT | (NZDIGIT DIGIT) |
                      ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT)
                      ; Limited to 0-255 range

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 31 Aug 2011 07:20:30 +0800

>             NZDIGIT       =  "1" / "2" / "3" / "4" / "5" / "6" /

Not quite: '/' instead of '|'.

And you can do ("2" ((("0"/"1"/"2"/"3"/"4") DIGIT)/("5" ("0"/"1"/"2"/"3"/"4"/"5")))) if you want to be properly pedantic.

Either that, or simply:
version = 1*3DIGIT ; 0-255 only

--Martin

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 31 Aug 2011 11:51:39 +0900

> Changed "implied WSP" to "implied *LWS" as per RFC 2616.

Thanks

I think I've clarified this by the following new text:

Looks good.

On Wed, Aug 31, 2011 at 08:20, Thomson, Martin <[email-masked]
> wrote:

> Not quite: '/' instead of '|'.

This will be in the section 4.3. where RFC2616 ABNF is used.

OTOH, in 4.2.2.-3-4, there's no note about which ABNF is used. Please add
the note, or I think we can remove the rules in this subsection as it's also
defined in 4.3.

> And you can do ("2" ((("0"/"1"/"2"/"3"/"4") DIGIT)/("5"
> ("0"/"1"/"2"/"3"/"4"/"5")))) if you want to be properly pedantic.
>
> Either that, or simply:

I'm fine with this simple version, too. Maybe we might want to add "no
leading zeros" note.

Thanks,
Takeshi