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

[Brodie Thiesfield <[e-mail]>]

If we accept Greg's suggestion, then the following text can be a base:



8.2 Allocating Reserved Bits

An extension may require the use of a reserved bit in the framing for
proper operation. Because both the server and client must know all
extension requirements before negotiating their use, requirements for
use of reserved frame bit are known.

The server and client will allocate reserved frame bits in a
predefined order. The order for the reserved bits is defined as the
number of the reserved bit as defined in section 4.2, i.e. RSV1 ->
RSV2 -> RSV3. The order of the extensions is defined by the order of
the extensions in the the Sec-WebSockets-Extensions response header.

Example;

The client requests the following 3 extensions:
Sec-WebSocket-Extensions: deflate-frame, sign-frame, mux-o-magic

The server supports all extensions and sends the response header:
Sec-WebSocket-Extensions: deflate-frame, sign-frame, mux-o-magic

If the deflate-frame extension requires 1 reserved bit and the
mux-o-magic extension requires 2 reserved bits, then the bits are
allocated as:

deflate-frame: RSV1
mux-o-magic: RSV2, RSV3

If the server response used a different ordering of extensions, the
allocated bits will be different according to the response extension
ordering.

For example, given the following server response header:
Sec-WebSocket-Extensions: mux-o-magic, deflate-frame, sign-frame

The reserved bits would be allocated as:
mux-o-magic: RSV1, RSV2
deflate-frame: RSV3

If there are no available reserved bits to be allocated to an
extension the server MUST NOT agree to use the extension.