Re: [hybi] first draft of WS mux extension

["Len Holgate" <[e-mail]>]

It means that any existing websocket implementation can support the mux
extension without needing to change the implementation at all, it could all
be implemented above the base protocol layer. This means that if an
implementation has a pluggable extension mechanism anyone, mux can be
implemnted now rather than when the implementation has been changed to
support it. 

I think it would be good practice to try and avoid changing the base
protocol for every extension. Avoiding changes to the base protocol will
likely see more support for various extensions as they'll be easier to
implement.

Your intermediary example doesn't work IMHO. Right now, if the intermediary
doesn't understand the mux extension it MUST fail the connection. If the
base protocol is unchanged then the intermediary can allow the mux extension
and ignore the frame contents, perhaps it's simply applying compression, or
SSL, or stripping masking, or routing via a non websocket transport, or
whatever, it can do all of that without understanding the mux extension.
Only an intermediary that wants to inspect data need worry about the fact
that it doesn't understand the mux extension in this case and if the
intermediary DOES want to inspect payload data and DOES understand the mux
extension then the changes are similar (it needs to understand that the
channel id and per channel FIN bit are in the extension data, rather than
just the channel id).

Len 

> -----Original Message-----
> From: John Tamplin [mailto:[e-mail]] 
> Sent: 24 October 2011 10:00
> To: Len Holgate
> Cc: Hybi
> Subject: Re: [hybi] first draft of WS mux extension
> 
> On Mon, Oct 24, 2011 at 4:30 AM, Len Holgate 
> <[e-mail]> wrote:
> 
> 
> 	No, you'd just use the existing framing in the base 
> protocol and all
> 	fragments would have the FIN bit set. Thus any channel 
> can interleave
> 	without changing any rules from the base protocol. 
> You'd then have a single
> 	FIN bit in the extension data, before the channel id, 
> which acts as the fin
> 	bit for this channel's data.
> 	
> 	Your example in 7 becomes
> 	
> 	81 06 [FIN BIT HERE = 0]01 "Hello" 81 04 [FIN BIT HERE 
> = 1]02 "bye" 81 07
> 	[FIN BIT HERE = 1]01 " world"
> 
> 
> Then those same intermediaries would have to understand the 
> MUX extension in order to do anything with frames anyway -- I 
> don't see what this gains.
> 
> -- 
> John A. Tamplin
> Software Engineer (GWT), Google
> 
>