Subject: [hybi] RSV bits in extensions

From: Peter Thorson <[email-masked]>
Date: Fri, 11 May 2012 12:24:01 -0500

Is the intention of the RSV registration to prevent the reuse of RSV bits or simply to catalog their use and help determine potential conflicts?

In the case that an endpoint gets a handshake request for two extensions with incompatible RSV bit registrations what is the expected behavior? Just pick one? Return an incompatible extension code? Return protocol error? Something else?

Peter Thorson

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 21 May 2012 16:46:00 +0900

On Sat, May 12, 2012 at 2:24 AM, Peter Thorson <[email-masked]>wrote:

> Is the intention of the RSV registration to prevent the reuse of RSV bits
> or simply to catalog their use and help determine potential conflicts?
>

My understanding is
- it's to get the allocation widely known to prevent unexpected
confliction, complication.
- it doesn't disallow use of the same bit by multiple extensions completely.

> In the case that an endpoint gets a handshake request for two extensions
> with incompatible RSV bit registrations what is the expected behavior? Just
> pick one? Return an incompatible extension code? Return protocol error?
> Something else?
>

I think
- it's ok to request two or more mutually incompatible extensions
- it's ok that the server accept the client by picking one of them.
- if the client requested two or more mutually incompatible extensions and
the server acked two or more of them, the client must fail.

Takeshi

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 21 May 2012 12:35:47 +0200

In practise, I believe this means that the RSV bits are of very very
limited use to 3rd party extensions and really have  been reserved for
extensions developed by this WG.    For example RSV1 will effectively
become the compression bit once the per-frame-compession draft is accepted
and RSV1 will only be able to be used by other extensions that are
obviously mutually exclusive to per-frame-compression (such as stream
compression)

I'm not saying this is a bad thing... it's probably good to have these bits
available for standard extensions without the need for the complexity of
dynamic bit allocations.     It just means that 3rd party extension should
really avoid using these bits and put their own flags in the payload....
unless somebody wants to define the unlimited-reserved-bit extension to be
used with other extension :)

cheers

On 21 May 2012 09:46, Takeshi Yoshino <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Jonathan Castello <[email-masked]>
Date: Mon, 21 May 2012 04:14:50 -0700

On the other hand, an extension could allocate an RSV bit only for
specific opcodes. If per-frame compression was only defined on text
and binary frames, RSV1 could be used by another extension on other
opcodes. This kind of scoping less solves the problem than it does
push it to the number of available opcodes, but it is an option.

Incidentally, this is my first message to the list. Hello!

~Jonathan Castello

On Mon, May 21, 2012 at 3:35 AM, Greg Wilkins <[email-masked]> wrote:
> In practise, I believe this means that the RSV bits are of very very limited
> use to 3rd party extensions and really have  been reserved for extensions
> developed by this WG.    For example RSV1 will effectively become the
> compression bit once the per-frame-compession draft is accepted and RSV1
> will only be able to be used by other extensions that are obviously mutually
> exclusive to per-frame-compression (such as stream compression)
>

---

From: Bruce Atherton <[email-masked]>
Date: Wed, 23 May 2012 11:47:35 -0700

On 5/21/2012 3:35 AM, Greg Wilkins wrote:
> become the compression bit once the per-frame-compession draft is 
> accepted and RSV1 will only be able to be used by other extensions 
> that are obviously mutually exclusive to per-frame-compression (such 
> as stream compression)
>
> I'm not saying this is a bad thing... it's probably good to have these 
> bits available for standard extensions without the need for the 
> complexity of dynamic bit allocations.     It just means that 3rd 
> party extension should really avoid using these bits and put their own 
> flags in the payload.... unless somebody wants to define the 
> unlimited-reserved-bit extension to be used with other extension :)
>

I think this is a little pessimistic. People writing extensions only 
have to accept that if they use a particular RSV bit, they are 
automatically incompatible with any other extension that uses it. So 
long as everyone is really clear in their documentation about what RSV 
bits they use, users can decide how to deploy them so that no conflicts 
occur.

Admittedly, though, if this WG defines any other RSV bits, that will 
effectively make them off-limits to others. I wouldn't recommend to any 
extension writer that they use the RSV1 bit for their extension, for 
example, unless it was an extension for compression.

So although users manually managing extensions for RSV bit conflicts is 
complicated, and although extension writers run a risk of being booted 
off their chosen RSV bit by the WG, I still think using them is doable 
for a couple of reasons. First, I don't see that there will be a flood 
of extensions that require an RSV bit, and second I don't see the WG 
rushing to create standard uses for them either.

Of course, I could be wrong. If there is a sudden rush for RSV bits then 
that might be a reason for the WG to define one of the RSV bits as an 
RSV bit extender, or to have an extension for reserve bits as you 
suggest. Let's see what happens.

---

From: John Tamplin <[email-masked]>
Date: Wed, 23 May 2012 21:19:54 -0400

On Wed, May 23, 2012 at 2:47 PM, Bruce Atherton <[email-masked]> wrote:

> I think this is a little pessimistic. People writing extensions only have
> to accept that if they use a particular RSV bit, they are automatically
> incompatible with any other extension that uses it. So long as everyone is
> really clear in their documentation about what RSV bits they use, users can
> decide how to deploy them so that no conflicts occur.
>
> complicated, and although extension writers run a risk of being booted off
> their chosen RSV bit by the WG, I still think using them is doable for a
> couple of reasons. First, I don't see that there will be a flood of
> extensions that require an RSV bit, and second I don't see the WG rushing
> to create standard uses for them either.
>
> that might be a reason for the WG to define one of the RSV bits as an RSV
> bit extender, or to have an extension for reserve bits as you suggest.
> Let's see what happens.

I suspect that if we came up with a bunch of extensions that needed
reserved bits, we would come up with a way of dynamically allocating them.
 So, I don't think it is really a problem.

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