[hybi] -09: abstract and introduction

[Peter Saint-Andre <[e-mail]>]

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
and putting them in a slightly-longer first paragraph in the intro
(before Section 1.1).

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

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

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?

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?

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.

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.

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).

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.

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?

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.

More soon.

Peter

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