Re: [hybi] Subprotocol and Control Frames

["Martin J. Dürst" <[e-mail]>]

Hello Mark, others,

I think you are working on some great stuff, but I very much agree with 
John and Greg and the many others who have clearly explained that 
options are for extensions and not for subprotocols (and Greg even found 
the text in the spec that says so).

It would be really great if you gave WebSockets a chance to be deployed 
and used as designed in the WG. This means that when you design a 
subprotocol, you just pretend that there are no more free option bits 
available (just the same as in TCP).

If you really, really can't get things to work that way (which I highly 
doubt), please ask this WG for further advice. We can always change 
things in a future version of WebSockets if we see a really strong need 
to do so. But for the moment, we would really strongly prefer to get 
experience with WebSockets as designed and as described in the spec.

Many thanks in advance!

Regards,    Martin.

On 2011/10/05 7:19, Greg Wilkins wrote:
> 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
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>