Re: [hybi] -09: IANA considerations

Iñaki Baz Castillo <ibc@aliax.net> Tue, 21 June 2011 12:53 UTC

Return-Path: <ibc@aliax.net>
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 1E67811E8083 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 05:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.661
X-Spam-Level:
X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjfME9qZR+2N for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 05:53:46 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6794411E8078 for <hybi@ietf.org>; Tue, 21 Jun 2011 05:53:46 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2123781qwc.31 for <hybi@ietf.org>; Tue, 21 Jun 2011 05:53:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr4986298qce.192.1308660825773; Tue, 21 Jun 2011 05:53:45 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 05:53:45 -0700 (PDT)
In-Reply-To: <4898.1308659426.327742@puncture>
References: <4DFB8E07.60908@stpeter.im> <BANLkTi=6_1H_cTTXRh00v1LM=E_1LUCq9g@mail.gmail.com> <4898.1308659426.327742@puncture>
Date: Tue, 21 Jun 2011 14:53:45 +0200
Message-ID: <BANLkTinEc5o3D=GeUvQ_wQEn+PmgOm+0wQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Dave Cridland <dave@cridland.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Server-Initiated HTTP <hybi@ietf.org>
Subject: Re: [hybi] -09: IANA considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 21 Jun 2011 12:53:47 -0000

2011/6/21 Dave Cridland <dave@cridland.net>et>:
> That all said, it's not clear to me this really needs a registry, or why one
> might want to allow independant stream RFCs to define a new version number -
> that effectively means that the next version of WebSockets might not be an
> IETF protocol at all. In contrast with the other registries - which seem
> reasonable - allowing random people to invent new and conflicting versions
> seems like a recipe for chaos.

I agree. WebSocket draft/RFC should registry an unique protocol
version (i.e. "1.0"). If a future extension is created, it should not
involve a new protocol version, but instead a like "Require" mechanism
within the core protocol so a client or a server can require an
extension and, if the other party supports it use it, if not, fail the
connection with the appropiated mechanism (i.e: "extension not
supported"). The protocol version cannot change for each new
extension.

For example, in SIP protocol (whose version is "2.0" and that's all)
there are "Require" and "Supported" headers. If a client sends a
request with "Require: xxxxxx" and the server does not support it, the
server replies 420 "Bad Extension":

   http://tools.ietf.org/html/rfc3261#section-21.4.15

Such mechanism is already defined in SIP 2.0, so increasing the
protocol version number is never required.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>