Note: This ballot was opened for revision 13 and is now closed.
Summary: Needs a YES. Needs 6 more YES or NO OBJECTION positions to pass.
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
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
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?
- 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.
- 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/
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).
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)