Re: [hybi] -09: IANA considerations

[Ian Fette (イアンフェッティ) <[e-mail]>]

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
<[e-mail]>wrote:

> 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
>>>> <[e-mail]>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
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailman/listinfo/hybi>
>