Re: [hybi] Websockets sub-protocol registry

Ted Hardie <ted.ietf@gmail.com> Mon, 14 March 2016 16:43 UTC

Return-Path: <ted.ietf@gmail.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 0045412DB39 for <hybi@ietfa.amsl.com>; Mon, 14 Mar 2016 09:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 f9nNARz7aiH0 for <hybi@ietfa.amsl.com>; Mon, 14 Mar 2016 09:43:49 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 314E912D647 for <hybi@ietf.org>; Mon, 14 Mar 2016 09:43:49 -0700 (PDT)
Received: by mail-ob0-x22b.google.com with SMTP id ts10so182261069obc.1 for <hybi@ietf.org>; Mon, 14 Mar 2016 09:43:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ul5nHPVho+/T9mrVnsbcyvKiMWFZ2sBxA8e47wm2P1A=; b=TQmooAjv71FyCNgfqBYclUpifzsHjkuG6gHAEeDFMMhWc/6NTWnEFNC3U8KVirwQtm CLB8YUNhqq261ZXXxArMUZdXLC2nV9FvKjI225Ak0v9RnhGDixlZ2PFUSeX+NefqAzn2 vQIx/iF92HM3OghpCxbvFKsPyPvFmPfpe/sSzMtiDsELJky7htjc6qI1hfKXKdByCBjY KaLDSiW8wa5XXc2dsDZ85/3ZlNonmDW5Azs1cYonnyNX0uQnK1lCTmEsfODN1N7rnZnH 23tLBJuutQGlJWfbL/Ej4l6vfV3+yaTSzrUkwTBSxec+JvHApUBNytBfAZIGTFQfxi8u Z6eQ==
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=ul5nHPVho+/T9mrVnsbcyvKiMWFZ2sBxA8e47wm2P1A=; b=KM3IshhNFevtF+LhNob3sxSfjO37d4gd12fcs42S+DuPqOxWU43ygWVRaMDBPyMqI9 o3+lrvVyYBtl4a4sUxULSeQtfHToqiME4vOTDsjLYHvR3LrPo85EkBLmaZ9ljKzYKPKq Yhoh7RJ6ihPlDx5njvuoErltjxPeN8nS+FK1a8ty8RF5J+gB44kNcx9qUA4xQHjKehPk 4bm7inU/DwrXzX1VSmDeDnGUP87DFzOdRGMAcT7nflTa/MXDrw4Ww9T9YqogA7a6yBAU v+Bmm36z6iaCeVbH3aC3IXygeXwUARqp1f9L0uWr4/8vBmIBk8EVrdLM89jCSoA0Xk1R CnkA==
X-Gm-Message-State: AD7BkJK5yumHKdSgJOAINofZdZ6oBjpxybaiAUqT0SadEAbJt/o8BEqcs8du3Keb/duhkBFZ7e+5BnYs5baHPQ==
X-Received: by 10.60.58.65 with SMTP id o1mr3363243oeq.50.1457973828527; Mon, 14 Mar 2016 09:43:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.51.6 with HTTP; Mon, 14 Mar 2016 09:43:29 -0700 (PDT)
In-Reply-To: <56E6E454.7090207@gmx.de>
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>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 14 Mar 2016 09:43:29 -0700
Message-ID: <CA+9kkMCPkZcaM6xF0ctkhnz+Uju0WNj24pJ+-+VUqgkRy0BEjw@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: multipart/alternative; boundary=089e013d095a242bf0052e04fcd2
Archived-At: <http://mailarchive.ietf.org/arch/msg/hybi/yfVy9vyMDkwB2gQDGbHYsJb3qwA>
Cc: 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: Mon, 14 Mar 2016 16:43:53 -0000

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

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
>