Re: [hybi] Subprotocol and Control Frames

[Hapner mark <[e-mail]>]

 >From: John Tamplin [[e-mail]]
 >Sent: Tuesday, October 04, 2011 9:18 PM
 >To: Hapner mark
 >Cc: Greg Wilkins; [e-mail]
 >Subject: Re: [hybi] Subprotocol and Control Frames
 >
 >On Wed, Oct 5, 2011 at 12:00 AM, Hapner mark <[e-mail]> wrote:
 >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.
 >
 >They are globally defined, but it is yet to be determined whether they can be allocated in overlapping fashion or dynamically.  We couldn't reach agreement on those, so we left it the way it is now, which basically means they can't be used without getting some agreement on them.  For example, one proposal was that each extension specify how many opcodes and reserved bits it needs, and those are allocated as needed per connection.  If we go with that approach, we could create a spec that defines the mechanism for dynamically allocating these resources, and then extension specs that want to make use of this could simply refer to that spec.
 >
 >Basically, the intent is to cross that bridge when we get there, and hopefully we will have real use cases to consider to guide that decision.
 > 
 >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.
 >
 >Most JSON or SOAP-based services I have used do in fact have some sort of message type in the payload, but YMMV.
 > 
 >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.
 >
 >I really don't see the difference -- if MBWS were to say "I want 20 bytes of extension data", how is that any different than just using the first 20 bytes of the WS payload as its extension data, and the remainder of the WS payload as the upper-level payload?

My main issue is with putting MBWS control frames into WebSocket message payloads. 

Putting MBWS message metadata into its associated message payload is a lesser issue. It requires the definition of an extension data mechanism within text message payloads and binary message payloads that mirrors what already exists in WebSocket.

You equate WebSocket with TCP. I equate it with HTTP. Possibly neither of us is fully correct. 

HTTP added a framing protocol over TCP so does WebSocket. If all extended use of WebSocket has to treat it like TCP, then Clebert and I should get on with implementing our MBWS message framing protocol and stop annoying the WG. 

On the other hand, there is great potential to reuse/extend the WebSocket protocol in much the same way that the web community has with HTTP. If the community had treated HTTP like it was TCP it would be worse off (as WS* did and is). Possibly the TCP analogy with WebSocket is not the most productive mental model of WebSocket's role in web architecture.

What would be the harm in considering extending the functionality of WebSocket subprotocol in the way I'm suggesting? Wouldn't having one less layer be a useful result. 

 > 
 >(As an aside, it isn't clear to me how different extensions that define different extension data can be composed.)
 >
 >In the order they are declared.
 > 
 >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.
 >
 >Multiple layers of framing is the norm -- Ethernet has its own framing, IP on top of that, TCP or UDP on top of that, HTTP on top of that, etc.  Each layer peels off their part and passes the rest on to the next layer -- that is the way the network stack works.  I am not sure why you are resisting this. 
 >
 >-- 
 >John A. Tamplin
 >Software Engineer (GWT), Google