The WebSocket Protocol
Note: This ballot was opened for revision 13 and is now closed.
( Peter Saint-Andre ) Yes
Jari Arkko No Objection
( Ron Bonica ) No Objection
Comment (2011-09-05 for -)
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)
( Stewart Bryant ) No Objection
( Gonzalo Camarillo ) No Objection
( Wesley Eddy ) (was Discuss) No Objection
( Adrian Farrel ) No Objection
Stephen Farrell (was Discuss) No Objection
Comment (2011-09-05 for -17)
- p20: code "running on www.example.com" is an odd phrase, I think you mean code "running that was downloaded from www.example.com" - 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) typos: - 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/
( Russ Housley ) (was Discuss) No Objection
( Pete Resnick ) No Objection
Comment (2011-09-07 for -)
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?
( Dan Romascanu ) No Objection
( Robert Sparks ) No Objection
Comment (2011-09-06 for -)
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).