Re: [hybi] Subprotocol and Control Frames

[Hapner mark <[e-mail]>]

Thanks for everyone's comments. Clebert and I are learning as we go ...

Greg,

Thanks for the clarifications ...

I agree that MBWS could define its own framing protocol within the WebSocket message payload, i.e. MBWS could be defined as a WebSocket subprotocol. (Sorry for my original confabulation of subprotocol and extension)

The option also exists to implement MBWS as it is currently defined as a WebSocket extension that adds extension data and extension control frame opcodes. 

WebSocket provides support for both subprotocols and extensions and I believe both are available for use by outside parties as long as the IANA registration mechanisms are followed. Is this correct?

My primary concern is that implementing MBWS as a subprotocol will add complexity and overhead. The only rationale I can see for defining MBWS as a subprotocol would be if, for some reason, browsers/proxies/firewalls blocked WebSocket extensions, i.e. MBWS has to use a 'subprotocol tunnel' through them.

The core point in favor of using an extension is that WebSocket already defines an excellent framing protocol. There is simply no need for MBWS to layer yet another framing protocol over it. It would be equivalent to a REST service defining a request-response framing protocol within the HTTP request-response body when all it needed was to add a few new header fields. Let me see, I think I remember this being done, it was called WS* :>)

The point about control frame opcodes being 'scarce' is an issue; however, the spec already suggests the use of an extension bit to resolve this. 

The spec does not describe how the opcode space will be distributed across extensions. It does not say whether or not an extension opcode value can be 'redefined' by different extensions. Since a session can only be operating under one extension, there does not appear to be a technical reason why extensions could not redefine extension opcodes. If this is possible, then MBWS does not 'use up' any extension opcodes.

Perhaps the fact that WebSocket itself does not reserve any of the opcode extension space for itself is an issue. There seems to be an implication in the comments so far that, in effect, they are all reserved and none are available for 'outside' use. I don't believe this is the case.

I think subprotocols and extensions are both useful. For an application specific case, say the transport of Insurance Policies and Quotes, defining a subprotocol for transport of this Insurance Message Schema would be sensible. I believe that MBWS is case where the use of an extension is sensible.

Again, I think this issue is worthy of some serious debate. I'm not ready to concede, as yet, that defining MBWS as a WebSocket extension is wrong.

-- Mark

 >On 5 October 2011 07:23, 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.
 >
 >Mark,
 >
 >in section 5.8 Extensibility:
 >
 >   This specification provides opcodes 0x3 through 0x7 and
 >   0xB through 0xF, the extension data field, and the frame-rsv1, frame-
 >   rsv2, and frame-rsv3 bits of the frame header for use by extensions.
 >
 >So while there is no explicit restriction on subprotocols using
 >opcodes, the only allowance given is to extensions.
 >
 >> 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.
 >
 >The specification also describes subprotocols in section 1.3 as
 >
 >   ... used to indicate what subprotocols (application-level protocols
 >   layered over the WebSocket protocol) are acceptable to the client.
 >
 >
 >> 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;
 >
 >Firstly subprotocols can no more use extensions data than they can use
 >extension opcodes.
 >They can however use the payload and are free to define arbitrary
 >message semantics within that payload that may include application
 >control messages.
 >
 >The restriction of subprotocols to not use opcodes is not done for
 >security.  It is done for protocol layering reasons.
 >The opcode is there to inform the WS implementation (and it's
 >extensions) how to handle the message.  There is no application
 >semantics associated with any of the opcodes.  For example the text vs
 >binary opcodes instructs the implementation if UTF-8 decoding is
 >required and to which part of the websocket API a message should be
 >delivered.  There is no semantic restriction imposed by a binary
 >message, which may actually be a text message, but one for which the
 >application or subprotocol has taken responsibility for character
 >encoding.
 >
 >> 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.
 >
 >Indeed there is a limitation in the current protocol of providing only
 >a single stream per connection, so there can be no separation of
 >control/data on a single connection.   However the solution is not to
 >allow applications to put their control messages into the protocols
 >control stream, but rather to better support multiple streams - ie
 >MUX.  For the protocol, it is clear that there are two streams of
 >frames: data and control,  but there is no reason why this taxonomy
 >will apply generally to all applications and subprotocols.  There may
 >be use cases where applications/subprotocols need n streams or control
 >frames larger than 125 bytes.
 >
 >The solution is to not see that the protocols control frame mechanism
 >is somewhat like the applications need for control messages and thus
 >to attempt to expose the protocols control channel to the application.
 > The solution is to allow applications to efficiently create their own
 >control channels - MUX!
 >
 >
 >> 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.
 >
 >This distinction between extensions and subprotocols has not been made
 >because of any API limitations.  It has been done for good protocol
 >layering reasons.
 >
 >Consider if we open up the control channel to applications, then this
 >will make the task of creating things like MUX extensions much more
 >difficult. The mux solution would have to allow for extending control
 >frames with extension data so that they may be correctly routed to the
 >right application control channel.  But if a 125 byte application
 >control frame is sent, then there may not be sufficient room to add
 >the channel identifier!    Also if control frames are used to
 >implement MUX flow control, will applications use their application
 >control frames to attempt to get around this flow control?  We may end
 >up needing to put flow control on the control channel to limit the
 >number of application control frames.
 >
 >Mixing application control frames with protocol control frames is a
 >far worse "solution" than mixing application control messages with
 >application data messages.
 >
 >regards