Re: [hybi] Subprotocol and Control Frames

[John Tamplin <[e-mail]>]

On Tue, Oct 4, 2011 at 4:23 PM, Hapner mark <[e-mail]> wrote:
>
>  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.
>

So where do you see that a subprotocol may define new opcodes or change the
framing?  There are an infinite number of things the spec doesn't say can't
be done.


>  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.
>

WS control frames are there for WS implementations, not for higher-level
protocols.  Similarly, you can't directly control ICMP frames from your UDP
connection.  If you want your own control frames, you layer them on top of
the lower level protocols.


>  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.
>

There are very few available opcodes.  If every subprotocol allocates a
couple that it needs, there won't be many subprotocols.


>  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.
>

HTTP doesn't send a separate control frame, it is sent as a prefix to the
higher-level payload, exactly as we are suggesting you do.


>  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.
>

There are many examples where the protocol is not restricted by the API --
for example, the JS API did not even support binary frames when they were
present in the wire protocol.

-- 
John A. Tamplin
Software Engineer (GWT), Google