Overall, I think this draft looks very good, excepting the issues below:1) Abstract - AIUI one of the primary motivations for WS (especially over just exposing a TCP API in browsers) is the use of the "Web security model." This should be mentioned in the Abstract (and background?).
2) The handshake protocol looks like HTTP, but is not (e.g., it's case- sensitive and whitespace-sensitive). However, you define the default ports for WS and WSS to be port 80 and 443, respectively.
These ports are reserved for HTTP, at least initially; while you can use HTTP to upgrade to a different protocol, defining a HTTP-like-but- not-really-HTTP handshake protocol to run over them initially conflicts with the designated use of the port.
Possible remedies; a) define the handshake in terms of HTTP, not byte sequences, orb) define a different (i.e., non-HTTP) protocol identifier to use on the handshake request and response.
3) In section 1.6 (Establishing a Connection), you say
On the face of it, the simplest method would seem to be to use port 80 to get a direct connection to a Web Socket server. Port 80 traffic, however, will often be intercepted by HTTP proxies, which can lead to the connection failing to be established.
Given this, is it a good idea for the default port for the WS scheme to be port 80? Why not use a separate port and fall back to 443 with null encryption, for example?
4) In section 1.2, you define the payload of the headers as ASCII, but then allow a wide range of Unicode characters. Which is it?
5) Are there any constraints placed upon the field-value of the WebSocket-Protocol header? Is there any structure?
If I want to define an intermediary function for WebSockets that allows multiplexing, and I wish to unambiguously identify that it's in use, is this an appropriate use for the WebSocket-Protocol header?
If so, how do I avoid conflicting with the names of other subprotocols, and how do I indicate that multiple subprotocols are in use on one connection?
If not, what's the appropriate mechanism? Cheers, -- Mark Nottingham http://www.mnot.net/
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.