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

[Brodie Thiesfield <[e-mail]>]

Hi Timothy,

On Fri, Apr 29, 2011 at 4:31 AM, Timothy Meade <[e-mail]> wrote:
> On Apr 27, 2011 11:12 PM, "Greg Wilkins" <[e-mail]> wrote:
>>
>> this is good. But I think we also need to say the same for op-codes.
>>
>> I think each extension needs to say how many bits, data op-codes and
>> control op-codes it needs and then these should all be allocated in
>> order.
>>
>
> It might be instructive to look at X Protocol opcodes for core and
> extensions and how that played out over time.

I found the following description of the opcodes:
http://www.x.org/wiki/Development/Documentation/Protocol/OpCodes

>From the summary of the scheme above:
* each extension is assigned a single major identifying opcode
* the extension then defines sub-codes for itself if necessary

So this is pretty much the same as we are looking at in websockets but
we have a lot less opcode space to allocate.

Can you supply a pointer to a summary of the problems that occurred
with the X scheme? I'm assuming that it didn't turn out all rosy.

Regards,
Brodie




>> On 28 April 2011 12:57, Brodie Thiesfield <[e-mail]> wrote:
>> > 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.
>> >
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>
> --
> Timothy Meade
> Real-time web developer
> Founder, Jobitr
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>