Re: [hybi] -09: IANA considerations

Iñaki Baz Castillo <> Tue, 21 June 2011 12:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E67811E8083 for <>; Tue, 21 Jun 2011 05:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.661
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EjfME9qZR+2N for <>; Tue, 21 Jun 2011 05:53:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6794411E8078 for <>; Tue, 21 Jun 2011 05:53:46 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2123781qwc.31 for <>; Tue, 21 Jun 2011 05:53:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id e20mr4986298qce.192.1308660825773; Tue, 21 Jun 2011 05:53:45 -0700 (PDT)
Received: by with HTTP; Tue, 21 Jun 2011 05:53:45 -0700 (PDT)
In-Reply-To: <4898.1308659426.327742@puncture>
References: <> <> <4898.1308659426.327742@puncture>
Date: Tue, 21 Jun 2011 14:53:45 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
To: Dave Cridland <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Server-Initiated HTTP <>
Subject: Re: [hybi] -09: IANA considerations
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jun 2011 12:53:47 -0000

2011/6/21 Dave Cridland <>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

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

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

Iñaki Baz Castillo