Subject: [rtcweb] Sub-protocol registry update

From: Ted Hardie <[email-masked]>
Date: Tue, 15 Mar 2016 09:05:49 -0700

So, I'll wait a day or two more for objections, but folks on the websockets
side seem to be generally okay with this text:

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

(See the thread starting here:
https://mailarchive.ietf.org/arch/msg/hybi/Ax-UqERaQ1P8KDzroBTQYhocjt0.
Note especially Takeshi Yoshino's note, which points out that even
websockets needs this clarification, as the behavior of Chrome and Firefox
differs. )

I think the cleanest approach here is a very short update to RFC 6445.
Anyone on this list have heartburn with that approach to resolving this?

regards,

Ted

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 Mar 2016 19:38:51 +0100

On 03/15/2016 05:05 PM, Ted Hardie wrote:
> So, I'll wait a day or two more for objections, but folks on the
> websockets side seem to be generally okay with this text:
>
> "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."
>
> websockets needs this clarification, as the behavior of Chrome and
> Firefox differs. )
>
> I think the cleanest approach here is a very short update to RFC
> 6445.  Anyone on this list have heartburn with that approach to
> resolving this?

I'm very happy with this approach and resolution.

>
> regards,
>
> Ted
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Mar 2016 12:04:09 +1100

This looks fine.  I checked.

I shouldn't have checked.

"(╯°□°）╯︵ ┻━┻)" is a valid subprotocol name according to both the
WebRTC spec and draft-ietf-rtcweb-data-protocol-09.  However, this is
not permitted in thewebsocketprotocol.  RFC 6455 says that I can't
register it, but what happens if I try to use it?

FWIW, I have no problem whatsoever with the protocol accepting more
values than might be permitted elsewhere.  But we should confirm that
this is fine; acknowledging the highly advanced state of the protocol
document (RFC editor queue, MISSREF).

Maybe our friends in the WebRTC WG in the W3C (whoever they are)
should address this.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 16 Mar 2016 08:49:41 +0100

> register it, but what happens if I try to use it?

I don't think RFC 6455 restricts you to using registered values in the
protocol field - in fact section 1.9 contains the typical language of
someone who thinks that using a domain name as part of an identifier is
enough for uniqueness (which is true for such a large fraction of cases
that in most cases, the failures caused by this are far down the list of
issues one has to deal with).

So if you send  "(╯°□°）╯︵ ┻━┻)" to me, dealing with it is my problem.
As long as I can find any commas in it, I'm OK.

>> RFC 6445 Section 11.5 are matched using case-sensitive string match.

Of course "case-sensitive string match" is not well defined either :-)
(cue the dragons of NFC vs NFKC vs no-normalization).
But it's well defined for the ASCII subset that can be registered, which
I regard as "good enough".

>>   IANA

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Mar 2016 07:57:17 -0700

On Wed, Mar 16, 2016 at 12:49 AM, Harald Alvestrand <[email-masked]>
wrote:

> I could replace that with one of the PRECIS definitions, but my personal
take
is that it will be confusing, given that only ASCII can be registered.  But
If you'd
like a citable reference, we could also call it simple string comparison,
and cite
RFC 3986 section 6.2.1.  I personally like that term because it "simple
string comparison"
seemed likely to invite confusion, but it would work for anyone who
followed the
reference.

So, I think the simplest description that works for the registry is
"case-sensitive string match",
but I will shift as needed.

Ted

> Firefox

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Mar 2016 15:47:56 -0400

> I regard as "good enough".

How about "are matched byte-by-byte"? (Or bit-by-bit)

	Thanks,
	Paul

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Mar 2016 13:48:45 -0700

On Wed, Mar 16, 2016 at 12:47 PM, Paul Kyzivat <[email-masked]>
wrote:

> So, RFC 3986 actually goes into why that terminology is potentially
confusing.  Its reasoning likely does not apply here, because the issues
when there is not a common character encoding; I think in this case
octet-by-octet matching will be equivalent to case-sensitive string match.

regards,

Ted

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 17 Mar 2016 18:51:01 +0100

On 03/16/2016 09:48 PM, Ted Hardie wrote:
> On Wed, Mar 16, 2016 at 12:47 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> confusing.  Its reasoning likely does not apply here, because the
> issues when there is not a common character encoding; I think in this
> case octet-by-octet matching will be equivalent to case-sensitive
> string match.

Octet-by-octet will be equivalent to case-sensitive string match with no
normalization before comparision - we already know the strings will be
UTF-8 (happily).

>     [email-masked] <mailto:[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Mar 2016 09:02:48 -0700

Just FYI, I did post a short draft to update the registry, which will need
to get a little discussion on the hybi list before going forward:

https://datatracker.ietf.org/doc/draft-hardie-rfc6455-iana-clarification/

(Likely not really for BCP, by the way, just not sure if I can get away
with informational).

Ted