Subject: [hybi] Websockets sub-protocol registry

From: Ted Hardie <[email-masked]>
Date: Fri, 11 Mar 2016 08:42:18 -0800

Howdy,

RTCWEB re-uses the websockets sub-protocol registry for identifying
sub-protocols using its data channels.  During discussion on the list, we
realized that the method by which these are compared is not specified and
that it is therefore not clear whether IANA could or should register two
values which differed only in case.

Would anyone object to specifying that IANA should not register two values
that differed only in case?  Is there a specification which determines
whether the match is case-sensitive or case-insensitive that we missed?

regards,

Ted

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 14 Mar 2016 09:31:44 +0100

> whether the match is case-sensitive or case-insensitive that we missed?

Why would you assume it to be case-insensitive? Typically any kind of
matching is case-sensitive unless otherwise specified.

-- 
https://annevankesteren.nl/

---

From: Ted Hardie <[email-masked]>
Date: Mon, 14 Mar 2016 08:01:41 -0700

> matching is case-sensitive unless otherwise specified.

We simply don't want to assume it; we'd like it to be specified, at least
in the RTCWEB case.  We're happy to specify that it be case-insensitive
match.  Based on a cursory look at libwebsockets and a few python libs, it
looks like that is the commoning match for the original usage as well.

Back to the IANA side of the question: Any objection to specifying that
IANA should not register two values that differed only in  case?  The
current instructions aren't clear on that.

regards,

Ted Hardie

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 14 Mar 2016 16:56:03 +0100

On Mon, Mar 14, 2016 at 4:01 PM, Ted Hardie <[email-masked]> wrote:
> We simply don't want to assume it; we'd like it to be specified, at least in
> the RTCWEB case.

In the typical use of the word, "a" does not match "A".

> Back to the IANA side of the question: Any objection to specifying that IANA
> should not register two values that differed only in  case?  The current
> instructions aren't clear on that.

Why? That would restrict the value space. We don't do that for HTTP
verbs either (although it might make sense there, and require them to
be uppercase).

---

From: Ted Hardie <[email-masked]>
Date: Mon, 14 Mar 2016 09:04:25 -0700

On Mon, Mar 14, 2016 at 8:56 AM, Anne van Kesteren <[email-masked]> wrote:

> IANA
The IANA registry currently has 23 items in it; restricting the value space
does not seem like a current issue.  Basically, you would do it so that
confusion in which was meant did not occur in the event that someone did
attempt the registration of XMPP (rather than xmpp, which is already
registered).   This is a first-come-first-served registry, so there is no
one to give helpful advice to registrants on this to avoid; the best we can
do is give instructions to IANA.

regards,

Ted

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Mar 2016 17:18:28 +0100

On 2016-03-14 17:04, Ted Hardie wrote:
> On Mon, Mar 14, 2016 at 8:56 AM, Anne van Kesteren <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Mon, Mar 14, 2016 at 4:01 PM, Ted Hardie <[email-masked]
>     <mailto:[email-masked]>> wrote:
> The IANA registry currently has 23 items in it; restricting the value
> space does not seem like a current issue.  Basically, you would do it so
> that confusion in which was meant did not occur in the event that
> someone did attempt the registration of XMPP (rather than xmpp, which is
> already registered).   This is a first-come-first-served registry, so
> there is no one to give helpful advice to registrants on this to avoid;
> the best we can do is give instructions to IANA.
>
> regards,
>
> Ted

The main risk I see is that people could mis-read this as meaning that 
the values are indeed case-insensitive. Of course that could be 
mitigated by being crystal clear in the wording.

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 14 Mar 2016 09:43:29 -0700

On Mon, Mar 14, 2016 at 9:18 AM, Julian Reschke <[email-masked]>
wrote:

> The main risk I see is that people could mis-read this as meaning that the
> values are indeed case-insensitive. Of course that could be mitigated by
> being crystal clear in the wording.
>
>
How would this work:

"The tokens registered in the Websockets sub-protocol registry created by
RFC 6445 Section 11.5 are matched using case-sensitive string match.  IANA
is, however, instructed to decline registrations in the registry which
differ only as to case, in order to minimize potential confusion among
different registered versions.  For other useful advice on avoiding
collision, registrants are encourage to consult the non-normative section
1.9 of RFC 6445."

We can either put that in the RTCWEB draft, a short draft updating just the
registration portion of RFC 6445, or possibly even in an accepted erratum.
If it were an accepted erratum for RFC 6445, we would likely still want to
include something in the RTCWEB docs noting that those were the rules (but
not having that doc update the RFC.)

Any thoughts on that approach?

Ted

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 15 Mar 2016 17:52:39 +0900

On Tue, Mar 15, 2016 at 1:43 AM, Ted Hardie <[email-masked]> wrote:

>> the values are indeed case-insensitive. Of course that could be mitigated
>> by being crystal clear in the wording.
>>
>>
> How would this work:
>
Sounds good to me.

I agree that there's no normative text specifying what comparison method to
use.

FYI, current status of browsers:

The implementation of the WHATWG WebSocket API on Chromium 49.0.2623.87:
- validates that the Sec-WebSocket-Protocol header value in the handshake
response is one of the subprotocols listed in the handshake request.
- Case-sensitive comparison is used for this.
- When the validation fails, the handshake fails.

The API implemented on Firefox 44.0.2:
- also validates the value against the list sent in the handshake request.
- But case-insensitive comparison is used.
- The WebSocket connection gets established even if the protocol doesn't
match (case-insensitive mismatch) but in that case the protocol attribute
of the WebSocket instance returns an empty string.
- The WebSocket instance's protocol attribute is set to the value in the
header without any case normalization

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Mar 2016 10:03:47 +0100

On 2016-03-15 09:52, Takeshi Yoshino wrote:
> On Tue, Mar 15, 2016 at 1:43 AM, Ted Hardie <[email-masked]
>     On Mon, Mar 14, 2016 at 9:18 AM, Julian Reschke
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>             On Mon, Mar 14, 2016 at 8:56 AM, Anne van Kesteren
>             <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                  On Mon, Mar 14, 2016 at 4:01 PM, Ted Hardie
>             <[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked]
>             <mailto:[email-masked]>>> wrote:
>         The main risk I see is that people could mis-read this as
>         meaning that the values are indeed case-insensitive. Of course
>         that could be mitigated by being crystal clear in the wording.
>
>
>     How would this work:
>
>     "The tokens registered in the Websockets sub-protocol registry
>     created by RFC 6445 Section 11.5 are matched using case-sensitive
>     string match.  IANA is, however, instructed to decline registrations
>     in the registry which differ only as to case, in order to minimize
>     potential confusion among different registered versions.  For other
>     useful advice on avoiding collision, registrants are encourage to
>     consult the non-normative section 1.9 of RFC 6445."
>
>
> Sounds good to me.

+1.

> I agree that there's no normative text specifying what comparison method
> to use.
>
>
> - validates that the Sec-WebSocket-Protocol header value in the
> handshake response is one of the subprotocols listed in the handshake
> request.

...raise a bug report?

 > ...

Best regards, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Mar 2016 14:01:10 +0000

Hi Ted,

On 14/03/2016 16:43, Ted Hardie wrote:
> On Mon, Mar 14, 2016 at 9:18 AM, Julian Reschke <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>             <mailto:[email-masked] <mailto:[email-masked]>>>
>         wrote:
>     The main risk I see is that people could mis-read this as meaning
>     that the values are indeed case-insensitive. Of course that could
>     be mitigated by being crystal clear in the wording.
>
>
> How would this work:
>
> "The tokens registered in the Websockets sub-protocol registry created 
> by RFC 6445 Section 11.5 are matched using case-sensitive string 
> match.  IANA is, however, instructed to decline registrations in the 
> registry which differ only as to case, in order to minimize potential 
> confusion among different registered versions.  For other useful 
> advice on avoiding collision, registrants are encourage to consult the 
> non-normative section 1.9 of RFC 6445."
>
> We can either put that in the RTCWEB draft, a short draft updating 
> just the registration portion of RFC 6445,
I slightly prefer the latter, but the former would be Ok.
> or possibly even in an accepted erratum.
We can do that as well. Although I would rather the erratum not being 
the only source of information on this.
> If it were an accepted erratum for RFC 6445, we would likely still 
> want to include something in the RTCWEB docs noting that those were 
> the rules (but not having that doc update the RFC.)
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Mar 2016 08:54:24 -0700

On Fri, Mar 18, 2016 at 7:01 AM, Alexey Melnikov <[email-masked]>
wrote:

> Hi Ted,
>
>
>
> We can either put that in the RTCWEB draft, a short draft updating just
> the registration portion of RFC 6445,
>

There's a 00 shot at this in
https://datatracker.ietf.org/doc/draft-hardie-rfc6455-iana-clarification/ .

I'm not sure what status to aim it at; BCP is probably wrong, but also easy
to fix.  Suggestions for that or other changes welcome.

Ted

> We can do that as well. Although I would rather the erratum not being the
> only source of information on this.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Mar 2016 18:32:29 +0000

On 21/03/2016 15:54, Ted Hardie wrote:
> On Fri, Mar 18, 2016 at 7:01 AM, Alexey Melnikov 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Ted,
>
>
>
> I'm not sure what status to aim it at; BCP is probably wrong, but also 
> easy to fix.  Suggestions for that or other changes welcome.

2.  Clarified instructions

    The tokens registered in the Websockets sub-protocol registry created
    by RFC 6445 Section 11.5 are matched using case-sensitive string
    match.  IANA is, however, instructed to decline registrations in the
    registry which differ only as to case, in order to minimize potential
    confusion among different registered versions.  For other useful
    advice on avoiding collision, registrants are encouraged to consult
    the non-normative section 1.9 of RFC 6445.

6445 --> 6455. But otherwise this looks good.
>     We can do that as well. Although I would rather the erratum not
>     being the only source of information on this.
>>     If it were an accepted erratum for RFC 6445, we would likely
>>     still want to include something in the RTCWEB docs noting that
>>     those were the rules (but not having that doc update the RFC.)
>>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Mar 2016 11:38:18 -0700

On Mon, Mar 21, 2016 at 11:32 AM, Alexey Melnikov <[email-masked]

> 6445 --> 6455. But otherwise this looks good.

Sigh.  I caught in the title and the references and missed it here.  Will
fix.

Ted

>> If it were an accepted erratum for RFC 6445, we would likely still want
>> to include something in the RTCWEB docs noting that those were the rules
>> (but not having that doc update the RFC.)
>>