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

[Greg Wilkins <[e-mail]>]

On 25 May 2011 15:14, John Tamplin <[e-mail]> wrote:
> On Wed, May 25, 2011 at 1:08 AM, Greg Wilkins <[e-mail]> wrote:
>>
>> > Again, that isn't what Greg was suggesting.
>> > Also, if reserved opcodes can't be used (which Greg was also
>> > suggesting),
>> > then there is no room for any experimentation, which seems a recipe for
>> > poor
>> > progress getting useful extensions.
>>
>> Extensions can always have their own opcodes by putting them as a byte
>> in the payload (which is what you have previously advocated for
>> extension opcodes anyway).
>
> Not if you don't define some extension opcode.  Ie, if I can't use a
> reserved opcode, saying my frame is a binary frame and the first byte is
> really a new opcode doesn't work with fragmentation and multiplexing being
> done by intermediaries which think it is just a regular binary frame.


Why can't the extension just send frames with the normal binary frame
opcode which then contain the extension specific opcode in the
payload.

Intermediaries will see these as binary frames - which they are.
Intermediaries that don't know the extension are not allowed to mess
with the framing/fragmentation, so thats not a problem.
The receiving extension takes the real opcode out of the payload and
handles it as a control, text, binary, whatever frame as appropriate.

ie, I don't see what is wrong with using the normal binary opcode for
an extension that sends binary payload, or the normal text opcode for
an extension that sends a text payload (eg adding mime headers as
text).

cheers