[hybi] Subprotocol and Control Frames

[Hapner mark <[e-mail]>]

In my reading of draft 17, I do not find a definition of subprotocol that puts any restrictions on the WebSocket extensibility features a subprotocol may use. If the sense of the WG is that subprotocols are restricted to use only extension data and message format/schema restrictions, this is not apparent in the content of this draft.

It is my observation that there will be a number of WebSocket usecases that could benefit from the ability to define usecase-specific control frames to mediate message flow. Telling developers to stuff this mediation protocol into extension data rather than in control frames does not appear to increase security; rather, it likely decreases security because it intermixes control with data which is a fundamentally bad thing for a protocol design to do.

The two control frames defined by MBWS are fairly simple and are likely representative of what other subprotocols would need. It would be far better to allow MBWS to properly factor its control and data than force it to put control in its data.

It is true that TCP does not support application control extension; however, HTTP clearly does support this with a very open-ended extension of the HTTP header. The WG needs to think carefully about this. I hope there is room to resolve this issue in this version of WebSocket.

It is up to the W3C WebSocket API to insure it provides the functionality that both native users of WebSocket and implementors of WebSocket subprotocols require. In looking over what is currently defined, this API does not yet provide an API sufficient for the later. Possibly later it will. I don't believe that the design of WebSocket needs to be restricted by the current limitations of this API.