Re: [hybi] Subprotocol and Control Frames

[John Tamplin <[e-mail]>]

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?


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