Re: [hybi] Subprotocol and Control Frames

[John Tamplin <[e-mail]>]

On Tue, Oct 4, 2011 at 9:36 PM, Hapner mark <[e-mail]> wrote:

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

Yes, but there are very very few available, and they were intended for WS
infrastructure needs.  If the first WS subprotocol allocates two of them, do
we tell people in a couple of months "sorry, we are all out", and not have
any left for the purpose for which they are intended?  This is
notwithstanding the fact that current APIs make no provision for using other
opcodes, and as we have explained, we don't think they should.


> 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* :>)
>

In most cases, such services *do* define a framing layer on top of HTTP --
for example, JSON, which defines how the payload carried by HTTP should be
interpreted.  They even have things like an opcode or message type inside
them.


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

No, arbitrary extensions can be supported at the same time -- there is only
one subprotocol.


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

That was the intent of requiring registration of new opcodes and reserved
bits -- to basically require standards action for them to be assigned, since
they are so scarce.

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.


Let's say you did define it as an extension.  For it to be useful, the API
would have to be modified to suit your need and the browsers would have to
implement your extension.  What are the odds that will happen in a short
time period, vs. just using the facility already available via the
subprotocol?

@Ian - clearly, we need to add some text to the spec explaining the
distinction between subprotocols and extensions so others don't get the same
misconceptions.

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