Subject: [hybi] -09: IANA considerations

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 17 Jun 2011 11:25:27 -0600

Sections 11.1 and 11.2 both say:

      Characters in the host component that are excluded by the syntax
      defined above MUST be converted from Unicode to ASCII by applying
      the IDNA ToASCII algorithm to the Unicode host name, with both the
      AllowUnassigned and UseSTD3ASCIIRules flags set, and using the
      result of this algorithm as the host in the URI.  [RFC3490]

RFC 3490 has been obsoleted by RFC 5890 and RFC 5891. We'll need to
modernize this text.

Sections 11. and 11.2 both say:

   Interoperability considerations.
      None.

However, the template in RFC 4395 says:

   Interoperability considerations.
      If you are aware of any details regarding your scheme that might
      impact interoperability, please identify them here.  For example:
      proprietary or uncommon encoding method; inability to support
      multibyte character sets; incompatibility with types or versions
      of any underlying protocol.

Now, Section 5.1 of the WebSocket spec says:

   2.   The Method of the request MUST be GET and the HTTP version MUST
        be at least 1.1.

So it seems that the interoperability considerations of our URI
registration requests might need to say something about incompability
with HTTP 1.0.

Section 11.6 mentions private use tokens beginning with "x-". Ick. :)

Typo in Section 11.10: "Paragraph 10 of Paragraph 4 of Section 5.1 "

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.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Fri, 17 Jun 2011 13:07:22 -0700

> Typo in Section 11.10: "Paragraph 10 of Paragraph 4 of Section 5.1 "

Sadly this one is not a typo - that's a deeply nested section... :(

> 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?

>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 21 Jun 2011 15:20:31 +0300

On 6/17/11 11:07 PM, Ian Fette (イアンフェッティ) wrote:
> 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?

not completely sure...
Peter what do you think?

---

From: Dave Cridland <[email-masked]>
Date: Tue, 21 Jun 2011 13:30:26 +0100

On Fri Jun 17 21:07:22 2011, Ian Fette (イアンフェッティ)  
wrote:
> (either as

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.

Am I missing something?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Jun 2011 14:53:45 +0200

2011/6/21 Dave Cridland <[email-masked]>:
> 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
<[email-masked]>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 Jun 2011 11:45:22 -0600

On 6/21/11 6:30 AM, Dave Cridland wrote:
> On Fri Jun 17 21:07:22 2011, Ian Fette (イアンフェッティ) wrote:
> 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.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 21 Jun 2011 23:02:12 +0100

>>version numbers would be handled by Obsoletes/Updates perfectly well.
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.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 21 Jun 2011 16:56:15 -0700

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
<[email-masked]>wrote:

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