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

[Timothy Meade <[e-mail]>]

Oh, great apparently Gmail was sending emails without my name for the
last six years, great to have that fixed.

On Thu, Apr 28, 2011 at 10:16 PM, Brodie Thiesfield <[e-mail]> wrote:
> 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
>>
>>
>

Hi Brodie,

I would have included references in the original email, though I'm
sure either of the two experts I cc'd can be much more helpful in that
regard.

Quoting from http://wiki.x.org/wiki/Development/X12#Compositedbydefault:

Extension space is too small

The first 128 requests are core protocol; the remaining 128 are
single-entry multiplex functions for extensions. It's sort of
ridiculous to have XPolyFillArc on the same footing as GLX.

The minor opcode "convention" should be formalized and made part of
the standard. The core protocol should be assigned major number zero
and use minor numbers.

The first 128 requests are core protocol; the remaining 128 are
single-entry multiplex functions for extensions. It's sort of
ridiculous to have XPolyFillArc on the same footing as GLX.

The minor opcode "convention" should be formalized and made part of
the standard. The core protocol should be assigned major number zero
and use minor numbers.

also see, though this is much more general dealing with more than
protocol issues:

Why X is not our Ideal Window System
http://www.std.org/~msm/common/protocol.pdf

--
Timothy Meade
Real-time web developer
Founder, Jobitr