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

[John Tamplin <[e-mail]>]

On Tue, May 24, 2011 at 10:40 PM, Greg Wilkins <[e-mail]> wrote:

> The simplest solution is to say that the 3 bits (and spare opcodes) in
> the framing are reserved for future versions of the protocol - ie off
> bounds to all extensions.
>
> Extensions that want to send bits and extra opcodes will always have
> to allocated bytes in the payload to carry them.
>
> Then we have two choices - come up with an allocation scheme in the
> spec (eg based on ordering like I've suggested), that may save a few
> bits per frame;  or we could leave this to the extensions to do their
> own allocation (minimum 1 octect for extensions wanting flags and/or
> opcodes).   I tend to agree that the bit savings might not be worth
> the effort to specify such a system, specially if we have a
> frame-deflate extension that would compress all those wasted bits
> anyway.
>
> The only outcome I'm strongly against is the status quo - where we
> have a few scarce resources with no fair share mechanism defined.
> This will just result in unfair market forces being used to make
> defacto allocations of those bits (and opcodes for that matter).   It
> is better not to have them than to have them with no fair share
> policy.
>

So why do you object to leaving it up to the definition of the first
extension that wants to allocate a reserved bit?  At that point, it could
define the dynamic allocation method you want.  It isn't like any one party
can railroad through a standards definition allocating one or more of the
bits.  I don't object to the idea, but I do not want to hold up the base
spec, which isn't going to define a use for these bits anyway, trying to get
consensus on how they should be allocated (though personally my preference
is a registry rather than the complexity of dynamically allocating them).

It sounds to me like you are saying "if I can't have it my way, nobody can
have them".  If they can't ever be used for extensions, it isn't entirely
clear what they could be used for, so we would be better off just allocating
them to the opcode than leaving them unused.

-- 
John A. Tamplin
Software Engineer (GWT), Google