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

On Fri, May 20, 2011 at 10:03 AM, Gabriel Montenegro
<Gabriel.Montenegro@microsoft.com> wrote:
> [as individual]
>
> We have very few reserved bits. These are not meant for use by just any extension, similarly, the bits in the TCP or IP headers are not "up for grabs", but are doled out very carefully.
>
> Dynamic, on-the-fly assignment of reserved bits was proposed by Greg and Brodie here:
> http://www.ietf.org/mail-archive/web/hybi/current/msg07345.html
>
> If we were to allow such a thing, then no particular extension would be guaranteed to run successfully, as it would depend on a resource (a reserved bit) that it is not guaranteed to have until the handshake is over. This would be too unpredictable. Extensions are free to define bits or control frames within their defined payload (as already noted in the draft).

Until the handshake is completed there is no websocket connection and
no guarantee that any extension will be accepted by the server anyhow.
I don't see that this is a problem.

It is more efficient in size considerations to use available bits in
the framing for extensions to use in their signalling. Since size was
important in the beginning and the reason we have the variable size
length field, I assume that saving up to 3 bytes per frame for
extensions that need flags is still desirable.

I still believe that it would be better for the server to explicitly
allocate the bit to the extension rather than have implicit allocation
of a bit via extension order. It allows server to refuse to allocate
specific bits as desired (e.g. new protocol version has allocated it)
without changes to extensions or clients using older protocol
versions. It also facilitates Greg's idea of adding an overflow block
of extra reserved bits if that proves necessary.

However, I don't feel particularly strongly about this issue and can
live with the worst-case scenario of every negotiated extension
extending the payload by a byte in order to get a single bit flag.

Regards,
Brodie

>
> Reserved bits should only be allocated for very compelling reasons, either because there is an extension that has full backing of the WG or because there is a new version of the protocol that needs it. I think we should word our IANA considerations on bit assignment with a very strict assignment policy of "Standards Action":
> http://tools.ietf.org/html/rfc5226#section-4.1
>
> Does this seem reasonable?
>
> Gabriel
>
>> -----Original Message-----
>> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Alan
>> Coopersmith
>> Sent: Thursday, April 28, 2011 21:01
>> To: Brodie Thiesfield
>> Cc: Hybi; jg@freedesktop.org; Greg Wilkins
>> Subject: Re: [hybi] method of allocation of reserved bits to extensions
>>
>> On 04/28/11 07:16 PM, Brodie Thiesfield wrote:
>> > Hi Timothy,
>> >
>> > On Fri, Apr 29, 2011 at 4:31 AM, Timothy Meade <zt.tmzt@gmail.com> wrote:
>> >> On Apr 27, 2011 11:12 PM, "Greg Wilkins" <gregw@intalio.com> 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.
>>
>> I don't know why you'd assume that, since the X extension mechanism is the key
>> that's kept the X protocol alive for 25 years as graphics technology changed
>> rapidly.
>>
>> The primary problem I'm aware of is that while each extension got one of the
>> 128 available requests, and bundled all it's actions into subcodes of that request,
>> they didn't do similar "namespacing" for event & error codes.
>>
>> We've not yet had a situation where we needed more than 128 extensions
>> simulataneously active, but have hit the limits of 64 extension events and errors,
>> as some extensions used quite a few.
>>
>> It does occasionally make user bug reports challenging as the dynamic
>> assignment of extension codes based on which ones are enabled during the build
>> and runtime of the X server means that getting an error report of a failed
>> request 153 doesn't let you know which extension it was.
>> (This is why the standard libX11 error handler always prints the extension names,
>> but some applications and toolkits use custom error handlers that do not.)
>>
>> --
>>       -Alan Coopersmith-        alan.coopersmith@oracle.com
>>        Oracle Solaris Platform Engineering: X Window System
>>
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>
>