Re: [hybi] -09: IANA considerations

Ian Fette (イアンフェッティ) <> Tue, 21 June 2011 23:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3758421F8503 for <>; Tue, 21 Jun 2011 16:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.775
X-Spam-Status: No, score=-104.775 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IHRImv8KmZw9 for <>; Tue, 21 Jun 2011 16:56:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2B7F621F8501 for <>; Tue, 21 Jun 2011 16:56:19 -0700 (PDT)
Received: from ( []) by with ESMTP id p5LNuHaW027793 for <>; Tue, 21 Jun 2011 16:56:18 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=beta; t=1308700578; bh=9nyvHtGkm0x2sGktXC7gfFiL5Kw=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=XQm+ClA4ABAI7JAQs8UdZLIV7QgrU4Vs4kcE4wnYEn/i19jg/O7I4GVCe6MHAj2NM nlt2EM6YhJQH+d4aTmYSQ==
Received: from iym1 ( []) by with ESMTP id p5LNtXLu023282 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <>; Tue, 21 Jun 2011 16:56:16 -0700
Received: by iym1 with SMTP id 1so278620iym.29 for <>; Tue, 21 Jun 2011 16:56:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dlFvssLmojNJFA8JRJdDPGRWuWrc3BbFctRBwP/tYXs=; b=YJyx+9XQwBy7DnZYx8G3DNJcoM/r23B7DOfONz4kf0wWGTfWuOwapwlu+ScoQe/t7D sS9BZHGKHeXRyep2y+WA==
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=hDg0pqF4LmSCnBFCGcorXD41CrAvSZNgVVbGos9v/R3IDY+gHqsbtB7B2D2wUrYFmk M6gj3NVwE6Ke6O4rHMKg==
MIME-Version: 1.0
Received: by with SMTP id a24mr26214ibr.58.1308700575752; Tue, 21 Jun 2011 16:56:15 -0700 (PDT)
Received: by with HTTP; Tue, 21 Jun 2011 16:56:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <4898.1308659426.327742@puncture> <> <>
Date: Tue, 21 Jun 2011 16:56:15 -0700
Message-ID: <>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <>
To: Alexey Melnikov <>
Content-Type: multipart/alternative; boundary=001636920a1aef631004a6419809
X-System-Of-Record: true
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 23:56:20 -0000

I guess my problem is that I think people have found it useful during
development to have this field, and I believe it's not unlikely that there
will be further development on a next version at some time in the future. I
would like people doing such experimentation to be able to use a
Sec-WebSocket-Version > 9 without the risk of collision. First Come First
Served would actually work fine for something like this, and would perhaps
alleviate these issues? That way people can experiment in the future, if
there's a next version that goes through multiple drafts it will be able to
re-use that field, and we don't have to come up with additional mechanisms.

(To be clear, I'm not talking about revving the protocol version to support
extensions, I'm talking about core changes.)

I really don't think it matters if Sec-WebSocket-Version:8 is the first
widely supported version and the next one happens to be
Sec-WebSocket-Version:325. The numbering scheme is not important.

On Tue, Jun 21, 2011 at 3:02 PM, Alexey Melnikov

> Peter Saint-Andre wrote:
>  On 6/21/11 6:30 AM, Dave Cridland wrote:
>>> On Fri Jun 17 21:07:22 2011, Ian Fette (イアンフェッティ) wrote:
>>>> On Fri, Jun 17, 2011 at 10:25 AM, Peter Saint-Andre
>>>> <>wrote;wrote:
>>>>> Section 11.12 says that assignment of WebSocket Version Numbers shall
>>>>> be
>>>>> "RFC Required", but then requests assignment of version numbers 0-8 to
>>>>> prior submissions of this Internet-Draft. The requested assignments are
>>>>> at odds with the stated policy.
>>>> RFC Required is different from Standards Action. RFC Publication
>>>> (either as
>>>> an IETF submission or as an RFC editor independent submission) suffices.
>>>> Standards Action requires Standards Track RFCs approved by the IESG. My
>>>> understanding from this as that an I-D counts as an IETF submission?
>>> Yes, but it only counts as an RFC once it's published...
>>> The solution is to assign these to this document, but note in this
>>> section that versions 1-8 are older versions.
>>> One might even ask IANA to maintain a note saying that, when creating
>>> the registry.
>>> 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'd have thought that we want standards-track here, and in any case, the
>>> version numbers would be handled by Obsoletes/Updates perfectly well.
>> Seems reasonable, yes.
>>  I tend to agree with the "cause chaos" argument, so Standards Track RFC
> or IETF Consensus (i.e. any RFC in the IETF Stream) is Ok.
> I would still prefer to have a registry, as some people (especially people
> not doing IETF standards for long time) are not as skilled as others in
> navigating chains of references. But I don't feel strongly enough about
> this.
> My 2p.
> ______________________________**_________________
> hybi mailing list