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

Gabriel

I'm concerned that if we really restrict usage of the reserved bits,
then we will force extensions into using whole bytes at the start of
the payload, when they really only want 1 bit.  If we really do get
into the situation where we have many extensions, then we could have
many wasted bits.

How about just having a mechanism that if we can allocated as many
reserved bits as we like, and if more than 3 are allocated then extra
bytes are prepended to the payload (as needed) for the extra bits.
Thus we could have unlimited extensions needing unlimited bits.

If a client doesn't want to play that game, then all it need do is
never handshake with extensions that need more than 3 bits.

cheers

On 20 May 2011 11:03, 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).
>
> 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
>
>