Re: [hybi] Subprotocol and Control Frames

[Hapner mark <[e-mail]>]

John,

Thanks for the further clarifications/corrections ...

So if I understand correctly, extension opcodes are globally defined and extensions are required to be defined such that they can be combined in adhoc combinations.

I would disagree that most users of HTTP put a framing protocol in HTTP bodies. They put MIME types (i.e. content types) in bodies. Content types do not contain protocol control - only the HTTP header contains (should contain) protocol control.

The MessageBroker use case is not an 'application' usecase; it is an extended element of the messaging infrastructure. Much like a firewall or proxy is an extended element of the HTTP infrastructure.

Within the phone home restriction, I believe AJAX clients have free rein to construct HTTP headers as they require. WebSocket needs something equivalent to this. If extensions are not this mechanism perhaps subprotocols can be extended a bit to provide this level of flexibility.

To be specific, providing one extension control frame opcode for overloaded use by a subprotocol, combined with allowing subprotocols to use extension data (or append 'subprotocol extension data' to the end of protocol extension data) would likely resolve this issue (MBWS would definitely use it). Also, the API would need to be extended to provide access to these subprotocol features so AJAX clients could access them.

(As an aside, it isn't clear to me how different extensions that define different extension data can be composed.)

I realize I'm a newbie to this WG so you are free to take my opinion with a grain of salt; however, I hope the WG will carefully consider extending subprotocol to allow MBWS to be defined without requiring it to define yet another message framing protocol.

-- Mark
________________________________
From: John Tamplin [[e-mail]]
Sent: Tuesday, October 04, 2011 6:54 PM
To: Hapner mark
Cc: Greg Wilkins; [e-mail]
Subject: Re: [hybi] Subprotocol and Control Frames

On Tue, Oct 4, 2011 at 9:36 PM, Hapner mark <[e-mail]<mailto:[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