Subject: Re: [hybi] -09: abstract and introduction

From: Alexey Melnikov <[email-masked]>
Date: Thu, 07 Jul 2011 20:12:12 +0100

Peter Saint-Andre wrote:

>I've started reviewing -09. For several reasons (mostly because my
>review time keeps getting interrupted), I'll provide feedback by
>section. This set of comments is mostly editorial.
>
>The abstract seems over-specific. I suggest deleting the parentheticals
>
I've done that in my copy ...

>and putting them in a slightly-longer first paragraph in the intro
>(before Section 1.1).
>
... but I haven't done that part yet.

>Section 1.1 has always struck me as strange. It sounds as if we're
>developing an IM protocol here! I suggest:
>
>   Historically, creating Web applications that need bidirectional
>   communication between a client and a server (e.g., instant messaging
>   and gaming applications) has required an abuse of HTTP to poll the
>   server for updates while sending upstream notifications as distinct
>   HTTP calls. [RFC6202]
>
I've used your text, thanks!

>I think it would also be helpful to provide an additional paragraph at
>the end of Section 1.1 with a bit of justification for why people who
>want to write bidirectional Web applications can't simply use existing
>application protocols such as IRC and XMPP. Yes, port 80 is the one true
>port, and developers complain that it would be a pain to build protocols
>like IRC and XMPP directly into a browser, but nothing says it's impossible.
>  
>
I am afraid I will need some help with such text.

>BTW [I-D.ietf-httpstate-cookie] is now [RFC6265] (thanks, Adam!).
>
Updated.

>Section 1.3 says:
>
>   If the
>   server does not wish to accept connections from this origin, it can
>   choose to reject the connection by sending an appropriate HTTP error
>   code.
>
>Which code?
>  
>
The section is informative. Do you really want the specific error 
code(s) listed?

>Section 1.3 says:
>
>   A JavaScript application cannot set a header starting with "Sec-" via
>   XHR.
>
>Why not? What is the nature of the restriction?
>
I think you got an answer to this on the mailing list.

>Section 1.3 says:
>
>   If the |Sec-WebSocket-Accept|
>   value does not match the expected value, or if the header is missing,
>   or if the HTTP status code is not 101, the connection will not be
>   established and WebSocket frames will not be sent.
>
>Do we really mean the following?
>
>   If the |Sec-WebSocket-Accept|
>   value does not match the expected value, or if the header is missing,
>   or if the HTTP status code is not 101, the browser MUST NOT
>   establish the connection and MUST NOT send WebSocket frames.
>
I think you got an answer to this on the mailing list: the section is 
informative, so it would be better to avoid using RFC 2119 language here.

>Section 1.4 uses the term "man-in-the-middle proxies". The term "man in
>the middle" might lead people to think of man-in-the-middle attacks as
>in RFC 4949 (BTW, an informational reference to RFC 4949 would be good
>in Section 2.1). I suggest "middlebox proxies" or "intermediate proxies"
>or some more neutral term.
>
I've changed that to "intercepting proxies", I think that is the correct 
term.

>In Section 1.5, I suggest...
>
>OLD:
>   It is expected
>   that metadata would be layered on top of WebSocket by the application
>   layer, in the same way that metadata is layered on top of TCP by the
>   application layer (HTTP).
>
>NEW:
>   It is expected
>   that metadata would be layered on top of WebSocket by the application
>   layer, in the same way that metadata is layered on top of TCP by the
>   application layer (e.g., HTTP).
>
Changed, thanks.

>This paragraph is hard to read:
>
>   Conceptually, WebSocket is really just a layer on top of TCP that
>   adds a Web "origin"-based security model for browsers; adds an
>   addressing and protocol naming mechanism to support multiple services
>   on one port and multiple host names on one IP address; layers a
>   framing mechanism on top of TCP to get back to the IP packet
>   mechanism that TCP is built on, but without length limits; and
>   includes an additional closing handshake in-band that is designed to
>   work in the presence of proxies and other intermediaries.  Other than
>   that, it adds nothing.  Basically it is intended to be as close to
>   just exposing raw TCP to script as possible given the constraints of
>   the Web. It's also designed in such a way that its servers can share
>   a port with HTTP servers, by having its handshake be a valid HTTP
>   Upgrade request mechanism also.
>
>I suggest breaking it up into bullet points:
>
>   Conceptually, WebSocket is really just a layer on top of TCP that
>   does the following:
>
>   * adds a Web "origin"-based security model for browsers
>
>   * adds an addressing and protocol naming mechanism to support
>   multiple services on one port and multiple host names on one IP
>   address;
>
>   * layers a framing mechanism on top of TCP to get back to the IP
>   packet mechanism that TCP is built on, but without length limits
>
>   * includes an additional closing handshake in-band that is designed
>   to work in the presence of proxies and other intermediaries
>
>   Other than that, WebSocket adds nothing.  Basically it is intended
>   to be as close to just exposing raw TCP to script as possible given
>   the constraints of the Web. It's also designed in such a way that
>   its servers can share a port with HTTP servers, by having its
>   handshake be a valid HTTP Upgrade request mechanism also.
>
Changed. I will review later on if the text is actually correctly 
describe the protocol.

>Section 1.7 says:
>
>   By default the WebSocket protocol uses port 80 for regular WebSocket
>   connections and port 443 for WebSocket connections tunneled over TLS
>   [RFC2818].
>
>I know this has been discussed on the list, but how can an entity
>discover if WebSocket is offered on ports other than 80/443? Would the
>web server use a redirect to do that? Could it define SRV records?
>  
>
I think that was also extensively discussed on the mailing list.

>Section 1.9 says:
>
>   These subprotocol names should be registered as per Section 11.10.
>   To avoid potential collisions, it is recommended to use names that
>   contain the domain name of the subprotocol's originator.
>
>Following the trail, we find this in Section 11.10:
>
>   Subprotocol Identifier
>      The identifier of the subprotocol, as will be used in the Sec-
>      WebSocket-Protocol header registered in Section 11.9 of this
>      specification.  The value must conform to the requirements given
>      in Paragraph 10 of Paragraph 4 of Section 5.1 of this
>      specification, namely the value must be a token as defined by RFC
>      2616 [RFC2616].
>
>In RFC 2616 we find:
>
>       token          = 1*<any CHAR except CTLs or separators>
>
>And in RFC 5234 we find:
>
>         CHAR           =  %x01-7F
>                                ; any 7-bit US-ASCII character,
>                                ;  excluding NUL
>
>So a Subprotocol Identifier is limited to 7-bit ASCII. Given that the
>domain name of the subprotocol's originator might be an IDNA, how will
>the originator be able to include their domain name in the identifier?
>This needs to be specified.
>
I think just saying "ASCII domain name" in Section 1.9 should be 
sufficient. If you think the document should have a reference to the 
most recent IDNA specs, such reference can be added.