Re: [rtcweb] Sub-protocol registry update

On 03/16/2016 02:04 AM, Martin Thomson wrote:
> 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?

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.

>
> 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.
>
> On 16 March 2016 at 05:38, Harald Alvestrand <harald@alvestrand.no> wrote:
>> 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.

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
>> 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?
>>
>>
>> I'm very happy with this approach and resolution.
>>
>>
>> regards,
>>
>> Ted
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>