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

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 20 May 2011 01:03:22 +0000

[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: [email-masked] [mailto:[email-masked]] On Behalf Of Alan
> Coopersmith
> Sent: Thursday, April 28, 2011 21:01
> To: Brodie Thiesfield
> Cc: Hybi; [email-masked]; 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 <[email-masked]> wrote:
> >> On Apr 27, 2011 11:12 PM, "Greg Wilkins" <[email-masked]> 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-        [email-masked]
> 	 Oracle Solaris Platform Engineering: X Window System
> 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 20 May 2011 16:42:31 +1000

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

---

From: "Andy Green (林安廸)" <[email-masked]>
Date: Fri, 20 May 2011 08:50:13 +0100

> never handshake with extensions that need more than 3 bits.

Sounds good to me.

This idea of reserved bits being misered is not only unnecessary but it 
is really inefficient - it'll lead to only special, big, connected 
players being able to use them and because they are permanently 
allocated to particular extensions in that model, there will always be a 
desire to withhold them "for later".

Dynamic allocation way anyone can randomly decide their extension will 
use them, no central allocation is needed and multiple extensions using 
reserved bits will always play well (plus or minus other doubts about 
extension ordering not related to reserved bits).

-Andy

---

From: Brian <[email-masked]>
Date: Fri, 20 May 2011 11:05:46 -0700

This seems fine to me too, but a bit more complicated than just
letting extensions prepend a byte for themselves to the payload data.
Honestly.. quibbling over wasting 7 bits by allocating a whole byte in
this day and age seems silly, even for things like cell phones.  My
cell phone (iPhone on AT&T in Los Angeles) is routinely able to
transfer data at over a megabit per second (and even faster when I get
out of the city).  So if there are a small handfull of "wasted" bytes
in the payload to accommodate extension data/flags, nobody's really
going to notice.

I would support the dynamically allocated flags mechanism that can
dynamically add more bytes to accomodate more extensions, but I just
think it seems a little unnecessary.

Brian

On Fri, May 20, 2011 at 12:50 AM, "Andy Green (林安廸)" <[email-masked]> wrote:
> This idea of reserved bits being misered is not only unnecessary but it is
> really inefficient - it'll lead to only special, big, connected players
> being able to use them and because they are permanently allocated to
> particular extensions in that model, there will always be a desire to
> withhold them "for later".
>
> Dynamic allocation way anyone can randomly decide their extension will use
> them, no central allocation is needed and multiple extensions using reserved
> bits will always play well (plus or minus other doubts about extension
> ordering not related to reserved bits).
>
> -Andy

---

From: Brodie Thiesfield <[email-masked]>
Date: Mon, 23 May 2011 08:23:59 +0900

> 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…

Until the handshake is completed there is no websocket connection and
no guarantee that any extension will be accepted by the server anyhow.
I don't see that this is a problem.

It is more efficient in size considerations to use available bits in
the framing for extensions to use in their signalling. Since size was
important in the beginning and the reason we have the variable size
length field, I assume that saving up to 3 bytes per frame for
extensions that need flags is still desirable.

I still believe that it would be better for the server to explicitly
allocate the bit to the extension rather than have implicit allocation
of a bit via extension order. It allows server to refuse to allocate
specific bits as desired (e.g. new protocol version has allocated it)
without changes to extensions or clients using older protocol
versions. It also facilitates Greg's idea of adding an overflow block
of extra reserved bits if that proves necessary.

However, I don't feel particularly strongly about this issue and can
live with the worst-case scenario of every negotiated extension
extending the payload by a byte in order to get a single bit flag.

Regards,
Brodie

---

From: Patrick McManus <[email-masked]>
Date: Tue, 24 May 2011 19:53:43 -0400

I apologize for quoting from so deep in the archive, but the thread is
still, somewhat to my horror, active:

On Wed, 2011-04-27 at 21:16 -0400, John Tamplin wrote:
> We had this discussion during the framing discussion, and we couldn't
> reach consensus then.  So, instead we simply said that each extension
> defines how bits are to be interpreted.   That could mean the bits are
> statically allocated, or it could mean some negotiation scheme like
> what you propose.
> 
> I would be opposed to delaying the spec to try and get consensus on
> negotiating the usage of reserved bits into the base spec, since it
> can be just as easily postponed until the first extension that wants
> to make use of some reserved bit.
> 

I agree with everything John says above. Our AD has given strong
guidance to create a IANA registry to record this, and I think that
makes sense as well.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 25 May 2011 12:40:02 +1000

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.

cheers

---

From: John Tamplin <[email-masked]>
Date: Tue, 24 May 2011 23:04:44 -0400

> is better not to have them than to have them with no fair share

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

---

From: Brodie Thiesfield <[email-masked]>
Date: Wed, 25 May 2011 12:08:50 +0900

> bounds to all extensions.

As stated earlier, I'm happy to live with no arbitrary extension use
of the reserved bits. This will require the explicit permission to use
reserved bits to be removed from the spec (see section 4.8).

Removing extension use of opcodes doesn't seem reasonable, but without
some sort of allocation scheme there will be no guaranteed interop
between extensions as multiple extensions may attempt to use the same
opcode. This will be the actual cause of the unpredictibility that
Gabriel was worried about.

Since there are already extensions being created that make use of
extended opcodes (e.g. the elusive google-mux), now is really the time
now to figure out how opcodes are allocated. At the very least, two
opcodes (e.g. 0x7 and 0xF) should be explicity reserved for future
expansion of the opcode space, which gives us somewhere to move if we
continue the free for all now.

Regards,
Brodie

---

From: Brodie Thiesfield <[email-masked]>
Date: Wed, 25 May 2011 12:18:55 +0900

On Wed, May 25, 2011 at 12:04 PM, John Tamplin <[email-masked]> wrote:
>> ....snip...

Then making them reserved and off-limits to arbitrary use by
extensions, and requiring the use of the IANA registry is your
preference as well?

> them to the opcode than leaving them unused.

If they are registered it doesn't mean they can't be used. Just that
the extension that uses them must be blessed with the registration.
All other extensions just add a byte to their payload and use it for
their flags.

Regards,
Brodie

---

From: John Tamplin <[email-masked]>
Date: Tue, 24 May 2011 23:31:24 -0400

> extensions, and requiring the use of the IANA registry is your

That isn't what Greg was suggesting -- he was saying they were not available
for extensions at all, but yes having a registry would be fine with me.

> All other extensions just add a byte to their payload and use it for

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.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 25 May 2011 15:08:01 +1000

> for extensions at all, but yes having a registry would be fine with me.

I don't want them available for extensions if it is just a
free-for-all, because then non-technical market forces will come into
play for their allocation and interoperability will be poor unless you
only use defacto standard extensions.

IANA registry is also a way to avoid the free for all, but it feels a
bit heavy bureaucracy for just 3 bits, which will soon be consumed and
then we are back to having no available bits and extensions have to
use the payload anyway.

But IANA is better than the status quo of no allocation.

> 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).         Sure we can go to IANA and create a
registry for the 8 or so available opcodes, but I'm sure they will
soon be allocated to some worthy extensions and then future
experimentation will have to use payload opcodes anyway.

I just think that we have too few bits and opcodes available to make a
fixed allocation work (either by defacto standards or by IANA
registry), as all will soon be consumed and we then have to think of
other solutions anyway.      I think a simple dynamic allocation
mechanism would work for a large pool of possible extensions, but we
would be limited by how many active extensions could be applied on the
same connection.

So eitherway, I see that eventually we will have to handle extensions
with flags and codes in the payload, so why not just go there directly
and not have to deal with either designing a system now or working
with IANA to allocated very limited resources.

cheers

---

From: John Tamplin <[email-masked]>
Date: Wed, 25 May 2011 01:14:04 -0400

On Wed, May 25, 2011 at 1:08 AM, Greg Wilkins <[email-masked]> wrote:

> 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.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 25 May 2011 16:00:56 +1000

> 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

---

From: SM <[email-masked]>
Date: Tue, 24 May 2011 23:52:41 -0700

At 18:03 19-05-2011, Gabriel Montenegro wrote:
>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":

Reserved bits can be allocated in future.  When a bit is marked as 
"reserved" it does not mean that it will never be used.

Having a strict assignment requirement has advantages and 
disadvantages.  If people find it difficult to get an assignment, 
they will squat on the bits.  It would be good if the working group 
give some thought to this question.

Regards,
-sm

---

From: Jim Gettys <[email-masked]>
Date: Thu, 26 May 2011 08:38:46 -0400

> with IANA to allocated very limited resources.
There is a technique we used in X11 design we should have pushed on much 
more broadly: enabling the client to do assignment/allocation of 
protocol elements as much as possible: we did this with resource ID's, 
and should have done this elsewhere in the protocol.  Our really big 
mistake was the Atom system, but I'll leave that for a different 
discussion if appropriate.  But the extension system has a similar 
mistake we made.

In the X protocol, extensions are a two phase process.

You perform a "QueryExtension", in which you provide the name of the 
extension (which is a string).  If it exists, the server tells you what 
opcode it will be available at (and a base number in the error numbering 
field for reporting errors, and a base number in the event fields that 
events may return from the extension).

In the X protocol, opcodes are two fields, a major opcode (1 byte) and a 
minor opcode (1 byte).

So long as there is no collision in the names of extensions, there is no 
reason for a registry.

There is also a protocol request to list the extensions available at the 
server.

By convention extensions have version numbering in them.

The downside of what we did (in the X protocol in general), is that 
while maximally extensible, it's more "chatty" than it might be 
requiring round trips to synchronise client and server state, which 
we've had to kludge around by pipelining requests.  We hadn't yet 
internalised that going over the net was so expensive to always optimise 
for that case.

It would have been better to just list the extension names available up 
front at connection open, and (when an extension is first used), have 
the client have to send a request to assign it a free opcode, avoiding 
the RTT delays.  You could also imagine (given your limited opcode 
space) you might be able to support more extensions simultaneously, 
switching assignments dynamically.  You could even have your servers 
list the most frequently used extensions first, and pre-assign them, so 
that the client doesn't have to send this message in many cases.

We haven't needed to in X, because we have 256 available opcodes, and 
haven't exhausted the op-code space.

Dunno if you can go this route: but it's what I'd do if I could and it 
were my headache.
                 - Jim

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 26 May 2011 19:55:08 +0300

After discussion with Gabriel,
taking in consideration the long mail discussion and different positions 
on this topic,
we have decided thata IANA strict assignment policy is the right way to 
handle the allocation of reserved bits

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Andy Green (林安廸)" <[email-masked]>
Date: Thu, 26 May 2011 18:40:19 +0100

> handle the allocation of reserved bits

... and reserved opcodes?

-Andy

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 26 May 2011 21:09:35 +0000

Also reserved opcodes, yes.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> "Andy Green (???)"
> Sent: Thursday, May 26, 2011 10:40
> To: Salvatore Loreto
> Cc: [email-masked]
> > taking in consideration the long mail discussion and different
> > positions on this topic, we have decided thata IANA strict assignment
> > policy is the right way to handle the allocation of reserved bits
>

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 27 May 2011 08:28:38 +1000

On 27 May 2011 02:55, Salvatore Loreto <[email-masked]> wrote:
> taking in consideration the long mail discussion and different positions on
> this topic,
> we have decided that a IANA strict assignment policy is the right way to

OK,  but can we add some text to the specification saying  that
experimental/proprietary extensions must not squat on opcodes/bits
pending IANA allocation, but instead put them in the payload until
such as they are allocated opcodes/bits.

cheers

---

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 27 May 2011 01:03:26 +0000

No need for such language. "Standards action" IANA policy is enough in addition to the wording already in 07.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg
> Wilkins
> Sent: Thursday, May 26, 2011 15:29
> To: Salvatore Loreto
> Cc: [email-masked]
> > positions on this topic, we have decided that a IANA strict assignment
> experimental/proprietary extensions must not squat on opcodes/bits pending
> IANA allocation, but instead put them in the payload until such as they are
> allocated opcodes/bits.
> 
> cheers

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 27 May 2011 03:27:32 +0200

>addition to the wording already in 07.

I am not sure what you are saying. If the idea is that people need to go
through some standards process in order to make use of shared resources,
like reserved bits or opcodes, then it seems the working group needs to
condemn not doing so in the strongest possible terms. We have experience
with any number of other protocol elements where people just do their
thing without bothering to do anything to document or register anything,
be they privileged port numbers, internet media types, character set i-
dentifiers, properties on the global object in ECMAScript environments,
HTML elements and so on and so forth.

If the working group does not want this to be the case for Websockets,
and considering that the group does not have much influence beyond very
clearly stating the ideas in its deliverables, I find the request to be
very explicit about this quite reasonable, and do not see what "need" is
absent here. At the very least I would expect some argument why whatever
language you find sufficient is indeed sufficient, such as a comparison
to comparable protocols where this kind of language did indeed prevent
bad actors from abusing shared resources, including why all the counter-
examples aren't very comparable to Websockets.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 31 May 2011 12:55:14 +0100

>such as they are allocated opcodes/bits.
I don't object to such text being added, but I suspect it will be ignored.

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 31 May 2011 16:27:48 +0000

We have as many counterexamples of the opposite with the bits in the IP header, TCP headers, IP TOS bits, as well as protocol numbers (e.g., for IP, TCP, ESP, IPv6, UDP, etc), etc. There is nothing new about IANA sections and process to control shared resources. Sure, there's no police and people can use bits as they see fit and sometimes they do so, but rules are already clear, and no extra wording will change that. 

> From: Bjoern Hoehrmann [mailto:[email-masked]]
> Sent: Thursday, May 26, 2011 18:28
> To: Gabriel Montenegro
> Cc: Greg Wilkins; Salvatore Loreto; [email-masked]
> I am not sure what you are saying. If the idea is that people need to go through
> some standards process in order to make use of shared resources, like reserved
> bits or opcodes, then it seems the working group needs to condemn not doing
> so in the strongest possible terms. We have experience with any number of
> other protocol elements where people just do their thing without bothering to
> do anything to document or register anything, be they privileged port numbers,
> internet media types, character set i- dentifiers, properties on the global object
> in ECMAScript environments, HTML elements and so on and so forth.
> 
> If the working group does not want this to be the case for Websockets, and
> considering that the group does not have much influence beyond very clearly
> stating the ideas in its deliverables, I find the request to be very explicit about
> this quite reasonable, and do not see what "need" is absent here. At the very
> least I would expect some argument why whatever language you find sufficient
> is indeed sufficient, such as a comparison to comparable protocols where this
> kind of language did indeed prevent bad actors from abusing shared resources,
> including why all the counter- examples aren't very comparable to Websockets.
> --

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Jun 2011 07:52:27 +1000

> We have as many counterexamples of the opposite with the bits in the IP header, TCP headers, IP TOS bits, as well as protocol numbers (e.g., for IP, TCP, ESP, IPv6, UDP, etc), etc. There is nothing…

I was thinking that the extra text was not so much trying to enforce
IANA rules/exclusions.  More to remind the developers that extra data
can be added to the payload for extra op-codes and flags.  Ie reduce
the temptation to squat on the reserved bits by steering them to an
acceptable alternative.

regards

---

From: John Tamplin <[email-masked]>
Date: Tue, 31 May 2011 17:58:07 -0400

> the temptation to squat on the reserved bits by steering them to an

I disagree with using existing opcodes for something different -- if a frame
is labelled as binary, then it should represent binary payload data that
will be delivered to the app.  If you want to have the payload that means
something else, then it needs a different opcode.  Even if you allowed
hijacking the existing frame definitions, it seems like you still have the
same problem in assigning values for the "secondary opcode" stored in the
first byte.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Jun 2011 08:44:21 +1000

> same problem in assigning values for the "secondary opcode" stored in the

I can see that argument and while not entirely convinced by it, don't
object to it either.

Which suggests that if we want to go the IANA path and not have
cyber-squatting, then we need to
define an opcode that says the frame is an extension frame and that
the interpretation of it is entirely up to the extension(s)

cheers

---

From: John Tamplin <[email-masked]>
Date: Tue, 31 May 2011 18:50:03 -0400

> the interpretation of it is entirely up to the extension(s)

So what happens when multiple extensions are defined?  How do you make sure
their use of such extension frames don't conflict?  That sounds at least as
complicated as the proposal to dynamically assign opcodes/bits.

I don't know if it is necessary -- I don't know about IANA allocation
procedures, but I would hope that bits can be allocated temporarily for
experimentation.  For example, something like "opcode 0x7 is reserved for
experimentation with MUX-related extensions until 31 Dec 2011".  If that is
feasible, then I think having a central registry is a good idea, rather than
saying only opcodes/bits are registered but secondary extension opcodes are
free-for-all.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Jun 2011 10:53:15 +1000

On 1 June 2011 08:50, John Tamplin <[email-masked]> wrote:
> their use of such extension frames don't conflict?

I am not proposing to give extensions any powers that they don't
already have now.

Extensions will be entirely responsible for separating their own meta
data from payload data and it will be the order of extensions that
keeps them separated.

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>

because extension A might be doing crypto, compression, muxing or
something else that smunges up the payload, so the meta data for B
would only be visible once the receiver had unwrapped the A extension,
and the meta data for C would only be visible once the B extension had
unwrapped it's payload mutations etc.

> That sounds at least as

I'm not proposing anything other than reminding developers that wish
to have meta data for an extension that they can put it in the payload
rather than squat on the reserved bits and opcodes.

> saying only opcodes/bits are registered but secondary extension opcodes are

What I'm advocating is that all experimental extensions use flags and
opcodes in the payload and do not use the reserved bits temporarily or
otherwise.    If the Working Group eventually looks at one of these
extensions and decides that it should be part of a future version of
the spec,  we can then allocate reserved bits and thus improve the
efficiency of the extension.

cheers