Re: [hybi] method of allocation of reserved bits to extensions

[Greg Wilkins <[e-mail]>]

On 28 April 2011 11:16, John Tamplin <[e-mail]> wrote:
> I would be opposed to delaying the spec to try and get consensus on
> negotiating the usage of reserved bits into the base spec, since it can be
> just as easily postponed until the first extension that wants to make use of
> some reserved bit.

I also am not keen to see any unreasonable delay.   But I think that
many of the issues surrounding framing and extensions are now better
understood and I think that it is worth while to at least revisit
unresolved issues such as these to see if we can resolve them.

Currently we have the assumption that if we look at a negotiated WS
connection and if we know all the extensions that have been
negotiated, then we will be able to decode the bytes on the wire.
Unfortunately, as Brodie has pointed out, that does not hold if there
is more than one extension that uses reserved bits.     I think this
is an oversight that must be fixed, but I'm not sure that we need
additional headers etc. for it.

I think it would be sufficient to say that reserved bits are allocated
to extensions in the order in which the extensions are negotiated (and
I don't think we need optional bits):

For example: if we have 3 extensions:

   deflate-frame:   uses 1 reserved bit
   sign-frame: uses 0 reserved bits
   mux-o-magic: users 2 reserved bits

the following extension ordering

   mux-o-magic, sign-frame, deflate-frame

then mux-o-magic would get bits RSV1 and RSV2  and defkate-frame would get  RSV3

This is really just a simple convention and requires no extra bytes
sent during handshake.


cheers