Re: [hybi] Websockets sub-protocol registry

Takeshi Yoshino <tyoshino@google.com> Tue, 15 March 2016 08:53 UTC

Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D13212D92A for <hybi@ietfa.amsl.com>; Tue, 15 Mar 2016 01:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPFe39N3ahlx for <hybi@ietfa.amsl.com>; Tue, 15 Mar 2016 01:53:02 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FA012D514 for <hybi@ietf.org>; Tue, 15 Mar 2016 01:53:02 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id g3so12253561ywa.3 for <hybi@ietf.org>; Tue, 15 Mar 2016 01:53:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KOjW+F5wBYhbquLe9ibgOI0jtKNz9E4Yx8R1hUxRC8s=; b=bKgE0ez4lCU0hiIAHTGPi8VixgYjTyBL7hXF8nq30QJmHV0NrtJsPmf5tfFmYJGX31 MAKtagR9PRXTYhMBHs4Z6U6dsWraOq2mTJIeWx9mQoPvS36WWcJBMgRXswLJxTeRE8qV FAkfAIqzmf58DUiIORmmVfOYYxQwIds6wRbyWVPsFjGGzgfSEyET0wMsJdcc5lpVhGZa iqRI2U0de3gBZz+TSAjbSyk798rKt0657aV8vOGprZqs+g7ACWvtfKk+6EsR/QSzT9IJ 9hnxjSBMZSIKb9LXEf99diMaKxPq4WhT6tXYEK/0GlUCQxrWscZwT29aatFO/1Ey5vIw GJuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KOjW+F5wBYhbquLe9ibgOI0jtKNz9E4Yx8R1hUxRC8s=; b=RFQo7v73aV1u4QdiiSdOLYTdOR5yXV9w5Jc6bSa7i4wRkpTMxX2CQTbZv//n0XgyLg T0fd27x30lLEb5rzTG9k45tP2GsdpB26x912hZ9dVwMDti8DFmSEhW98Ni2zyuEi+e5P iF5weOM7AN7rYd3YlkaTNlFbppIy/PYgSCi6gfRO4WLSpUYZnsVvrOornpBsrPZDGxOE 749vFlHuDPtbzu6mp+fae1u5fA7o9u0tRFIoCcuMP2S0pTGA57gqiHwwiQZREWqsVH/p ABE4w3QptIozmyfLoSa8aU7EEbXRaMYjEG1q3JagABbRM/iDK+rMtIw0W/CE7FqPZkWD HRDA==
X-Gm-Message-State: AD7BkJL4SK2/FriLDLO6Mwvhami8VEynJmlSUnh0qJTmItrOmFqPSz8OYLDIpHOrX7nPz/cezgahKOn0rnr+Aw3+
X-Received: by 10.129.120.133 with SMTP id t127mr427674ywc.204.1458031981246; Tue, 15 Mar 2016 01:53:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.203.195 with HTTP; Tue, 15 Mar 2016 01:52:39 -0700 (PDT)
In-Reply-To: <CA+9kkMCPkZcaM6xF0ctkhnz+Uju0WNj24pJ+-+VUqgkRy0BEjw@mail.gmail.com>
References: <CA+9kkMDZQ_dPM76HaAKwvsRaOhdyvbQd+YLOCTR9piBYO2Kt+w@mail.gmail.com> <CADnb78gBkzjhVRQgzF29hNq4LsCZ=vSu4CJSM9nDWuLVcsOzDw@mail.gmail.com> <CA+9kkMCriEjDrs0Fpb-6QGcuZLWX37xVTBo6wk1Zq9cBSRMTxw@mail.gmail.com> <CADnb78iuJ=F=uhOTfyKx7mnH6wtpN6Pjqa2w2sQ7ZCbdULU_rw@mail.gmail.com> <CA+9kkMA5gHqd9QgfOseowEuFsE=sp8yjcUDa+6A06rQg650Jvw@mail.gmail.com> <56E6E454.7090207@gmx.de> <CA+9kkMCPkZcaM6xF0ctkhnz+Uju0WNj24pJ+-+VUqgkRy0BEjw@mail.gmail.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Tue, 15 Mar 2016 17:52:39 +0900
Message-ID: <CAH9hSJZqP1xgYM9HEixif+OiLnrOnRD0dDbTaWHO2rkz8b-w2w@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c0b096850c728052e128621"
Archived-At: <http://mailarchive.ietf.org/arch/msg/hybi/Uk6GiUmxWtEKRwYdHlIPpD_d3RA>
Cc: Julian Reschke <julian.reschke@gmx.de>, Server-Initiated HTTP <hybi@ietf.org>
Subject: Re: [hybi] Websockets sub-protocol registry
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2016 08:53:04 -0000

On Tue, Mar 15, 2016 at 1:43 AM, Ted Hardie <ted.ietf@gmail.com> wrote:

> On Mon, Mar 14, 2016 at 9:18 AM, Julian Reschke <julian.reschke@gmx.de>
> wrote:
>
>> On 2016-03-14 17:04, Ted Hardie wrote:
>>
>>> On Mon, Mar 14, 2016 at 8:56 AM, Anne van Kesteren <annevk@annevk.nl
>>> <mailto:annevk@annevk.nl>> wrote:
>>>
>>>     On Mon, Mar 14, 2016 at 4:01 PM, Ted Hardie <ted.ietf@gmail.com
>>>     <mailto:ted.ietf@gmail.com>> 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).
>>>
>>>
>>> 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.
>>
>>
> 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.

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

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
>
>
>
>
>
>> Best regards, Julian
>>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>