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

[Bruce Atherton <[e-mail]>]

On 31/05/2011 5:53 PM, Greg Wilkins wrote:
>
> So if you have extensions A, B and C, each wanting to have opcodes and
> flags then you might see a payload like:
>
>   <A opcode><A flags>  <B opcode>  <B flags>  <C opcode>  <C flags>  <payload>
>
> Except that in reality the semantics of that is actually
>
>   <A opcode><A flags>  <A payload  of<B opcode>  <B flags>   <  B
> payload of<C opcode>  <C flags>  <  payload>>>
>
> Which essentially means that on the wire all you would see is
>
>   <A opcode><A flags>  <A payload>
>

I understand your concerns about squatting on bits, but I don't follow 
your reasons for wanting this scheme. If A wants its own opcode and 
bits, why not let it put that into its extension data? Why not have 
something like:

<Standard Opcode><Standard Flags><A Payload>

where <A Payload> is composed of:

<A Opcode><A Flags><B Payload>

and <B Payload> is:

<B Opcode><B Flags><C Payload>

and so on. A's crypto/compression/muxing could apply only after it had 
retrieved its opcode and flags. What is the benefit of popping the 
opcode and flag requirements up a level?