Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)

[Adam Rice <[e-mail]>]

On 15 February 2013 00:56, Barry Leiba <[e-mail]> wrote:

>
> OK... so how do you folks propose that your ADs resolve this errata report?
>
> The options are as follows:
>
> 1. It's just wrong, and we should mark it "Rejected".  (This doesn't
> seem like where you're going.)
>
> 2. It's absolutely correct as it is, and we should mark it "Verified".
>  (It doesn't seem like it's this either.)
>
> 3. It's essentially correct, but needs some editing.  You can provide
> the edits and we can edit it and then mark it "Verified".
>
> 4. It's true that there's a problem, but the resolution is beyond the
> scope of an erratum.  We can either leave it as it is or edit it (to
> tweak the proposed resolution and/or to explain the difficulty in
> resolving it), and then mark it "Held for Document Update".


I would like to take option 3. I would like to propose the following text
to clarify the intent of RFC6455 while preserving the meaning:

   2.  If the client already has a WebSocket connection to the same IP
       address and port pair, even if the remote host is known by another
       name, the client MUST wait until that connection has been established
       or for that connection to have failed.  There MUST be no more than
       one connection in a CONNECTING state.  If multiple connections to the
       same IP address and port pair are attempted simultaneously, the
       client MUST serialize them so that there is no more than one
       connection at a time running through the following steps.

The following paragraph already indicates what must be done in the case
where the IP address cannot be determined, so this change should not create
any difficulties in the case where the connection is tunnelled via an
HTTP(S) or SOCKS5 proxy.

I think the issue that this section creates problems for WebSocket proxies
and non-browser clients cannot be handled without changing the meaning of
the text, and so I would like to deal with that separately.

Thank you,
Adam Rice