Skip to main content

The WebSocket Protocol
RFC 6455


(Peter Saint-Andre)

No Objection

(Adrian Farrel)
(Dan Romascanu)
(Gonzalo Camarillo)
(Jari Arkko)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)

Note: This ballot was opened for revision 17 and is now closed.

Peter Saint-Andre Former IESG member
Yes ()

Adrian Farrel Former IESG member
No Objection
No Objection ()

Dan Romascanu Former IESG member
No Objection
No Objection ()

Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

Jari Arkko Former IESG member
No Objection
No Objection ()

Pete Resnick Former IESG member
No Objection
No Objection (2011-09-07)
Section 1 has lots of "_This section is non-normative._" That convention isn't defined until section 2, so it's pretty silly to see them in section 1. But even so, I don't think it clears up anything. I would prefer to remove them.

4.1 - "Additionally, if the client is a web browser, an /origin/ MUST be supplied." Also see sub-bullet 8 of the handshake: "The request MUST include a header field with the name "Origin" [I-D.ietf-websec-origin] if the request is coming from a browser client." What happens if a web browser doesn't supply an origin? And how would you know if a web browser didn't do this? (That is, how can you distinguish it from a non-web browser?) I don't see how this can be a MUST.

4.1 - "In a Web browser context, the client SHOULD consider the number of tabs the user has open in setting a limit to the number of simultaneous pending connections." That's going to end up being anachronistic. Let's not put SHOULDs on this kind of user interface stuff. How about instead, "For example, in a web browser context, the number of open windows or tabs are a good indication of the number of simultaneous connections."

4.2 - "_This section only applies to servers._" Seems unnecessary.

4.3 - Do you really intend base64-value (and therefore Sec-WebSocket-Key and Sec-WebSocket-Accept) to be able to be empty in the ABNF?

5.5 - "A response to an unsolicited pong is not expected." SHOULD/MUST NOT be sent?

5.7 - I don't think "_This section is non-normative._" is necessary. Further, this section seems oddly out of place. Perhaps in an appendix?
Robert Sparks Former IESG member
No Objection
No Objection (2011-09-06)
1) At the next to last bullet in the list of fragmentation rules in section 5.4, can you make it clearer that an 
intermediary that might fragment a frame will always be able to tell that whether or not extensions have 
been negotiated? In particular, consider calling out that an intermediary that isn't able to see the server's 
handshake message (due to it being inside a TLS tunnel for example) also would not "see" individual frames, 
so it wouldn't be possible for it to try to fragment them. If the assumption in my first question isn't true, then a 
more aggressive adjustment to the text is probably needed.

2) The text in section 5.5.2 (Ping) could be misinterpreted to require sending a Pong even after receiving a Close (otherwise it violates that MUST). 

3) There are currently three ways to say this frame has 5 octets of data. Please consider adding a requirement to use the shortest of those three possible ways. (This is related to one of Stephen's discuss points).

Ron Bonica Former IESG member
No Objection
No Objection (2011-09-05)
A couple of reference issues:

  ** Downref: Normative reference to an Informational RFC: RFC 2818

  ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891)
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection ()

Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2011-09-14)

Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2011-09-05)
- p20: code "running on" is an odd phrase, I think
you mean code "running that was downloaded from"

- p27: referring to "Paragraph 4 of Section 4.2.2" from within 4.2.2
is odd and probably wrong depending on how you count paragraphs.
Suggest rewording.

- p29: If the ABNF and the introductory text in 5.2 were to be in
conflict, which takes prededence? I'm not saying there is a
conflict, but that kind of thing happens, so picking one as
normative might be useful just in case. 

- p30: the "%x" notation is odd - why not just specify the values in
decimal? If you prefer hex, I'd find 0x8 clearer than %x8.

- p30: you don't say until 5.5 that opcodes 8-10 are control frames,
but you depend on that in 5.4 where you say "control frames MAY be
injected...". Better to move the text at the start of 5.5 earlier.

- p33: why does "to be defined later" appear here? (twice) That
chunk of ABNF seems a bit flakey since all four frame-*-*-data are
just the same binary stuff.

- p33: I guess masking is pretty useless if TLS is in use
end-to-end, but is still done even with TLS in case the TLS
endpoints aren't the websocket endpoints. Is that right? If so, it
might be worth pointing out.

- p36: why no ABNF for control frames?

- p38: "A response to an unsolicited pong is not expected." seems
vague. Can't you not say what MUST or MUST NOT happen?
- p44: Providing some reference for the "Certain algorithms and
specifications..." mentioned in 7.1.7 would be good. (Same comment
for 7.2.1 & 7.2.2)


- p21: s/doesn't contains/doesn't contain/ 
- p23: s/a "Origin"/an "Origin"/ 
- p27: s/other section of/other sections of/
- p36: s/if streaming API/if a streaming API/
- p39: s/base protocols/base protocol/
- p50: s/other section of/other sections of/
- p52: s/in a case of/in the case of/
- p54: s/,TLS authentication./ or TLS authentication./ in 10.5
- p69: s/didn't necessarily endorsed/don't necessarily endorse/
Stewart Bryant Former IESG member
No Objection
No Objection ()

Wesley Eddy Former IESG member
(was Discuss) No Objection
No Objection (2011-09-08)