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

From: Bruce Atherton <[email-masked]>
Date: Wed, 01 Jun 2011 13:14:55 -0700

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?

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 2 Jun 2011 11:18:32 +1000

Bruce,

I think we are saying the same thing.   I am proposing extensions put
their stuff in the extension data - I was just not calling it that and
saying they should put it in the payload.

So what you describe is exactly what I was saying... just said differently.

cheers

On 2 June 2011 06:14, Bruce Atherton <[email-masked]> wrote:
> 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:
>
> retrieved its opcode and flags. What is the benefit of popping the opcode
> and flag requirements up a level?
>
>