Subject: [hybi] comments on draft-ietf-hybi-websocket-requirements-00

From: gabriel montenegro <[email-masked]>
Date: Thu, 8 Jul 2010 11:20:15 -0700 (PDT)

Hi folks,
I've had some conversations with collegues at Microsoft and we'd like 
to provide some feedback on the requirements document. 
Please find it interspersed with the text of the draft below 
(between "---" markings). Hopefully, it is not too late for the 
revision before next Monday's deadline.
thanks,
Gabriel Montenegro
Windows Networking, Microsoft

[initial text elided]
1.  Introduction
   HTTP [RFC2616] is a client/server protocol, where the HTTP servers
   store the data and provide it when it is requested by clients.  When
   used to used to retrieve data from an HTTP server, the client sends
---
/used to//
---
   HTTP requests to the server, and the server returns the requested
   data in HTTP responses.  So the client has to poll continuously the
   server in order to receive new data.
   Recently techniques that enable bidirectional communication over HTTP
   have become more pervasive.  Those techniques reduce the need to poll
   continuously the server thanks to the usage of HTTP hanging requests
   and multiple connections between the client and the server
   [I-D.loreto-http-bidirectional].
---
Replace with I-D. ietf-hybi-design-space
---
   The goal of HyBi is to provide an efficient and clean two-way
   communication channel between client and server.
   The communication channel will:
   o  allow each side to, independently from the other, send data when
      is willing and ready to do it;
   o  rely on a single TCP connection for traffic in both the
      directions.
   o  reduce the high overhead produced by HTTP headers in each request/
      response.
---
Given the verbage above about ‘recent techniques’ it is better to be 
explicit about the fact that the WG is not going to standardize any 
of the existing hacks that reuse HTTP (or extended HTTP), but rather to 
UPGRADE the connection to a separate protocol with the right semantics 
satisfying the requirements set forth in this document.
Suggest adding this bullet to the list above:
   O  Use HTTP UPGRADE to set up the communication channel between 
      client and server using the WebSocket Protocol. 
---
   The goal of this work is to provide the set of requirements the
   WebSocket Protocol MUST meet.
   In the following sections we list and analyse the requirements from
   the perspective of clients and servers.

2.  Terminology
   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
   levels for compliant implementations.
2.1.  HyBi Terminology
   This document uses the following HyBi-related terms:

Wilkins & Stachowiak    Expires November 11, 2010               [Page 3]
 
Internet-Draft         HyBi WebSocket Requirements              May 2010

   connection:  A transport layer virtual circuit established between a
      client and a server for the purpose of communication.
   frame:  The basic unit of WebSocket communication, consisting of a
      structured sequence of octets matching the syntax defined in the
      actual protocol and transmitted on the established communication
      channel.
   message:  user message: a block of related data with identified
      boundaries.
   origin server:  The server on which a given resource resides or is to
      be created.
---
Suggest adding definitions for the 3 aspects of the protocol along 
these lines:
WebSocket handshake: The process involving the HTTP UPGRADE and 
associated capability negotiation that sets up the WebSocket 
communication channel
WebSocket communication channel : After the WebSocket handshake is 
complete, the resultant bi-directional communication path between 
client and server over the transport (e.g., TCP, or SSL over TCP) 
that was used by HTTP up to and including the UPGRADE.
WebSocket sub-protocol: The negotiated sub-protocol for use on a 
WebSocket communication channel that dictates framing, encoding, 
compression, etc.
The chronological relationship among these is:
        HTTP(s) session
           |
           |
           V
        WebSocket Handshake [including Sub-Protocol negotiation]
           |
           |
           V
        WebSocket communication channel 
           |
           |
           V
        WebSocket Sub-protocol 
             (uses framing, encoding, compression, etc as dictated
              by the sub-protocol)
---
3.  WebSocket Requirements
   The following requirements fro WebSocket Protocol have been
---
/fro/for the/
---
   identified both in the HyBi wg input document
   [I-D.hixie-thewebsocketprotocol] and in the HyBi mailing list
   dicussion.
   REQ. 1:  The WebSocket Protocol MUST run directly on top of a
      transport protocol (e.g.  TCP, UDP or SCTP, DCCP).
---
No need to say anything, as the point is that whatever HTTP was 
running over should continue to be used after the upgrade. Typically 
this is TCP, yes. So how about rewording thus:
   REQ. 1:  The WebSocket Protocol MUST run directly on top of 
      the transport over which the initial HTTP handshake was running 
      (typically TCP).
---
   REQ. 2:  The WebSocket Protocol MUST be able to handle (send and
      receive) messages on top of a TCP data stream connection.
---
Suggest rewording:
   REQ. 2:  The WebSocket Protocol MUST be able to handle (send and
      receive) messages up to a maximum size (TBD) on top of the transport 
      over which the initial HTTP handshake was running (typically TCP).
---

   Reason: transfer data as message prevents the receiver to parse/
   handle partial content.
---
Not sure I could parse the above. Is this closer to the intent?:
Reason: transfer data as message obviates the need for the receiver to parse/
   handle partial content.
---
   REQ. 3:  It MUST be possible to sent a message when the total size is
---
/sent/send/
---
      either unknown or exceeds a fixed buffer size.
---
/size/size (TBD)./
---
   Reason: This will allow dynamic messages to be constructed and sent
   without the need to buffer the entire message.
   REQ. 4:  Textual data MUST be encoded as UTF-8.
---
Good that this only applies to textual data. But it is not clear what 
"text data" refers to: either metadata used in capability negotiation 
during the handshake or textual data in the data stream in the 
established communication channel.
---
   REQ. 5:  The protocol MUST be designed to support different frame
      types (e.g. binary).
---
Suggest changing to different "data types" to be consistent with REQ 4,
which uses the expression "textual *data*". So how about something like
this:
   REQ. 5:  The protocol MUST be designed to support negotiation among 
       multiple possible framing mechanisms (e.g. binary, textual). 
---
   REQ. 6:  The WebSocket protocol MUST allow HTTP and WebSocket
      connections to be served from the same port.  Consideration MUST
      be given:

Wilkins & Stachowiak    Expires November 11, 2010               [Page 4]
 
Internet-Draft         HyBi WebSocket Requirements              May 2010
 
         * to provide WebSocket services via modules that plug in to
         existing web infrastructure.
         * to making it possible and practical to implement standalone
         implementations of the protocol without requiring a fully
         conforming HTTP implementation.

   Reason: Some server developers would like to integrate WebSocket
   support into existing HTTP servers.  In addition, the default HTTP
   and HTTPS ports are ofter favoured for traffic that has to go through
   a firewall, so service providers will likely want to be able to use
   WebSocket over ports 80 and 443, even when running a We server on the
   same host.  However there could be scenarios where it is not
   opportune or possible to setup a proxy on the same HTTP server.
   REQ. 7:  When sharing host and "well known" port with HTTP, the
      WebSocket protocol MUST be HTTP compatible until both ends have
      established the WebSocket protocol.
---
What is the difference between fully conforming HTTP and HTTP compatible?
Also, to clarify what aspects of the protocol are being referred to,
I suggest rewording as follows:
   REQ. 7:  When sharing host and "well known" port with HTTP, the
      WebSocket protocol handshake MUST be HTTP compatible until both ends have
      established the WebSocket protocol communication channel.
---
   Reason: when operating on the standard HTTP ports, existing web
   infrastructure may handle according to existing standards prior to
   the establishment of the new protocol.
   REQ. 8:  The protocol SHOULD make it possible and practical to reuse
      existing HTTP components where appropriate.
   Reason: the re-usage of existing well-debugged software decreases the
   number of implementation errors as well as the possibility to
   introduce security holes especially and at the same time speed up the
   development especially when the Web Socket server is implemented as
   modules that plug in to existing popular Web servers.
---
Here's one more requirement:
Req # TBD: WebSocket sub-protocols MUST be able to support different 
framing and encoding and be able to reuse existing security mechanisms 
(e.g., upgrading to a TLS-enabled session for XMPP).
---
3.1.  WebSocket Client Requirements
   REQ. 9:  The WebSocket Client MUST be able to set up a communication
      channel sending to a WebSocket Server a well defined handshake.
---
Slight rewording suggested:
   REQ. 9:  The WebSocket Client MUST be able to set up a communication
      channel with a WebSocket Server using a well defined handshake.
---
   REQ. 10:  WebSocket Protocol MUST provide for graceful close of an
      active WebSocket connection on request from the user Application.
   Reason: a clean shutdown signals that the other endpoint has
   definitely received all the messages sent prior the the close, so
---
/the the/to the/
---
   there is no protocol uncertainty about what has been processed / what
   can be retried on another connection.

Wilkins & Stachowiak    Expires November 11, 2010               [Page 5]
 
Internet-Draft         HyBi WebSocket Requirements              May 2010

   OPEN ISSUE:  WebSocket Protocol MUST also allow ungraceful close,
      either on request from the user application or as a result of a
      detected error condition.
---
Can’t be avoided (e.g., if one end stops responding or crashes), 
so MUST is correct.
---
   REQ. 11:  The WebSocket Client MUST be able to request the server,
      during the handshake, to use a specific WebSocket sub-protocol.
---
Suggest rewording as follows:
   REQ. 11:  During the handshake ,the WebSocket Client MUST be able 
to send one or more WebSocket sub-protocol proposals to the server 
so that the server can select one.,This results in the use of a specific 
WebSocket sub-protocol.
---

   REQ. 12:  The WebSocket Client MUST have the ability to send
      arbitrary text content to the server on the established
      communication channel, in the form of ordered discrete blocks.
   REQ. 13:  The WebSocket Client MUST have the ability to send
      arbitrary binary content to the server on the established
      communication channel, in the form of ordered discrete blocks.
---
#12 and #13 can be combined into one. Suggest rewording #12 as follows and
deleting #13:
   REQ. 12:  The WebSocket Client MUST have the ability to send
      arbitrary content to the server on the established
      communication channel, as dictated by the WebSocket 
       sub-protocol in effect.
---
3.2.  WebSocket Server Requirements
   REQ. 14:  The WebSocket Server that accept to set up, with a
      WebSocket Client, a communication channel MUST send back to the
      WebSocket Client a well defined handshake.
---
Suggest rewording as follows:
   REQ. 14:  The WebSocket Server that accepts to set up 
      a communication channel with a
      WebSocket Client MUST use a well defined handshake.
---
   REQ. 15:  The WebSocket Server MUST have the ability to send
      arbitrary text content to the client on the established
      communication channel, in the form of ordered discrete blocks.
   REQ. 16:  The WebSocket Server MUST have the ability to send
      arbitrary binary content to the client on the established
      communication channel, in the form of ordered discrete blocks.
---
#15 and #16 can be combined into one. Suggest rewording #15 as follows and
deleting #16:
   REQ. 15:  The WebSocket Server MUST have the ability to send
      arbitrary content to the client on the established
      communication channel, as dictated by the WebSocket sub-protocol 
      in effect.
---
3.3.  WebSocket Proxies Requirements
   Todo
----
Suggest adding the requirement as follows, as nything short of this is not practical:
   REQ. TBD: WebSocket MUST work over existing proxies to the same extent 
      as HTTP or HTTPS already does.
----
3.4.  WebSocket Security Requirements
   REQ. 17:  The WebSocket Protocol MUST use the Origin-based security
      model commonly used by Web browsers to restrict which Web pages
      can contact a WebSocket sever when the WebSocket protocol is used
      from a Web page.
   REQ. 18:  When used directly (not from a Web page), the WebSocket
      Protocol MUST use an equivalent security model.

---
"origin-based" security is not directly translatable to non-browser
 usage, so requiring an "equivalent" model is problematic.  There may 
be different models available outside the browser world so this 
is a very narrow view. Outside of the browser, there is precedent 
in direct HTTP(S) usage (e.g., via utilities such as curl) so that 
usage should be allowed.
Suggest rewording as follows:
   REQ. 18:  When used directly (not from a Web page), the WebSocket
      Protocol MUST use a security model equivalent to that of direct 
      HTTP or HTTPS usage.
---

Wilkins & Stachowiak    Expires November 11, 2010               [Page 6]
 
Internet-Draft         HyBi WebSocket Requirements              May 2010
 
   REQ. 19:  WebSocket should be designed to be robust against cross-
      protocol attacks.  The protocol design should consider and
      mitigate the risk presented by WebSocket clients to existing
      servers (including HTTP servers).  It should also consider and
      mitigate the risk to WebSocket servers presented by clients for
      other protocols (including HTTP).
---
These terms should reuse thjose discussed in the HTTP security 
analysis work in HASMAT or defined here.
---
   Reason: As the Web Socket protocol is expected to be mainly used in
---
/mainly/often/
"mainly" implies other usages are not as important or are 2nd class citizens,
contrary to what the charter says: "Wide browser support is a goal for 
the bidirectional communication mechanism, however the solution should 
also be suitable for clients other than Web Browsers." 
---
   browsers, a careful design is necessary to mitigate the chances for
   hostile JavaScript to use WebSocket for a cross-protocol attack
   against vanilla HTTP resources or non-HTTP servers.  More the design
   should prevent the possibility for cross-site XMLHttpRequest (using
   CORS or XDomainRequest) to be used for a cross-protocol attack
   against WebSocket resources, potentially violating integrity (though
   not confidentiality).

[rest of the text elided...]

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 9 Jul 2010 10:28:29 +1000

Gabriel,

I'm no longer editor of the requirements, but I've commented below as
an individual.

>       the transport over which the initial HTTP handshake was running

+1

>       over which the initial HTTP handshake was running (typically TCP).

I don't think we should mix in size requirements here.

>        multiple possible framing mechanisms (e.g. binary, textual).

I think "negotiation" is a loaded word for this protocol, and I think some are
very much opposed to any negotiation and prefer a declarative (or assumed)
approach.

I actually think that there is no requirement to support different framing.
The requirement is that we must be able to transport both binary and text
messages - if one framing mechanism can do both, then great!  So how
about:

    REQ. 5:  The protocol MUST be designed to support both binary and
   textual data.

> What is the difference between fully conforming HTTP and HTTP compatible?

I have long argued that we should require "compliance" rather than
compatibility.
Compliance implies a more than compatibility in that telnet could be said to be
HTTP compatible because you can telnet to port 80 and interact with a HTTP
server.  But telnet is not HTTP compliant, because it can also be used to send
illegal HTTP.    Compliance means that the HTTP conversation needs to be
legal HTTP up until the websocket communication channel is established (for
which I agree with your extra wording).

>       established the WebSocket protocol communication channel.

+1 (specially if we s/compatible/compliant/)

> (e.g., upgrading to a TLS-enabled session for XMPP).

I don't agree with this one.   Websocket should be a specific
protocol, with specific
framing.   If you want to carry XMPP, then you need to define a
binding for XMPP to
websocket framing.  I think this subprotocol should represent this
binding and not
a different framing mechanism.

>       channel with a WebSocket Server using a well defined handshake.

+1

> so that the server can select one.,This results in the use of a specific

Firstly I don't think the requirements document should actually talk about
the handshake.  Handshaking is an implementation detail.

So the requirement should be just about establishing sub protocols.
But again we come down to the two different approaches - should the
sub-protocol be negotiated (in which case your list of sub-protocol proposals
makes a lot of sense), or should it be declarative (and the server can only
accept or reject).

I like negotiation... but then if we negotiate one thing, we should probably
negotiate more.

So maybe the requirement is to support sub protocols - if a particular
solution support negotiation, then great, but it is not actually required?

>       communication channel, as dictated by the WebSocket

+1

(although it duplicates REQ5 a bit)

>       WebSocket Client MUST use a well defined handshake.

Why is it a requirement to use a handshake?
I think that is implementation detail and this REQ can be dropped.

>       communication channel, as dictated by the WebSocket sub-protocol

+1

(although it duplicates REQ5 a bit)

>       as HTTP or HTTPS already does.

I think that is a bit strong, because I don't think it is possible to
work with all existing
proxies.    How about

    REQ. TBD: WebSocket SHOULD work over existing proxies that do not impede
    the flow of a websocket communication channel.

Ie - if a proxy like haproxy can be made to work with websocket
without upgrading
the proxy, then we should work with it.

cheers

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 9 Jul 2010 07:15:14 +0200

Greg, I'm adding a precision below.

On Fri, Jul 09, 2010 at 10:28:29AM +1000, Greg Wilkins wrote:
> > 3.3.  WebSocket Proxies Requirements>    Todo> ----> Suggest adding the requirement as follows, as nything short of this is not practical:>    REQ. TBD: WebSocket MUST work over existing proxies to the same extent>       as HTTP or HTTPS already does.
> I think that is a bit strong, because I don't think it is possible towork with all existingproxies.    How about
>     REQ. TBD: WebSocket SHOULD work over existing proxies that do not impede    the flow of a websocket communication channel.
> Ie - if a proxy like haproxy can be made to work with websocketwithout upgradingthe proxy, then we should work with it.

We must be careful to always distinguish two points :
  - proxies
  - reverse-proxies

Proxies are explicit on the client side. The client may very well use
the CONNECT method to establish the bidirectionnal tunnel over the
proxy, it has worked for many years now. Squid is a good example of
such a proxy, where CONNECT already works. However, from my experience,
HTTP Upgrade through proxies does not often work. My squid is quite
old here (2.6.STABLE13) and does not support it. Some other products
I've tried this through did not support it either (some of them being
anti-virus proxies). In all cases, the behaviour is very clean because
the proxy simply closes the connection after the 101 response, which
is easily detected by the client. But I still think the CONNECT method
is safer.

Reverse proxies are either on the server side, or implemented in any
intermediate (eg: a load balancer in front of proxies on the client
side, or an HTTP-aware firewall somewhere in the path). Haproxy is
such a reverse proxy. Thus it will have to understand the proxy mode
if installed in front of client-side proxies (so CONNECT is OK), or
to understand the server-side protocol when installed in front of
servers (HTTP UPGRADE is already OK).

I'm sure most of us are aware of the differences between those two
usages, but since I've sometimes confused people myself by employing
the term "proxy" to designate a reverse-proxy, I find it better to
clarify.

Regards,
Willy

---

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 09 Jul 2010 07:36:57 +0200

>       the transport over which the initial HTTP handshake was running

I think the requirement should be removed then. The requirements shouldn't  
constrain us to a HTTP handshake.

>       over which the initial HTTP handshake was running (typically TCP).

Why should we constrain size in the requirements?

> so that the server can select one.,This results in the use of a specific

I don't think this is needed. It's also something that can easily be added  
later if application authors find a need for it.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Micheil Smith <[email-masked]>
Date: Fri, 9 Jul 2010 18:13:18 +1000

I think there's only one change, in what I've read of this thread (since the message
from Gabriel, 9th July 2010) that I could argue against as a protocol implementor
and active maintainer of a near spec-compliant server.

The only thing that does stand out is the message size constriants, which would
not be a good idea. If a client sends a message that is too large, then it is up to
the server-side developer to decide if they want to disconnect the socket for that
reason.

The second point I find interesting is the sub-protocol negotiation point, this is
something that I think would possibly be a good idea, but may add unneeded
complexity.

Also, I am that micheil person from #whatwg on irc.

Yours,
Micheil Smith
--
BrandedCode.com

On 09/07/2010, at 3:36 PM, Anne van Kesteren wrote:

> On Thu, 08 Jul 2010 20:20:15 +0200, gabriel montenegro <[email-masked]> wrote:
> I think the requirement should be removed then. The requirements shouldn't constrain us to a HTTP handshake.
> 
> 
>> ---
> I don't think this is needed. It's also something that can easily be added later if application authors find a need for it.
> 
> 
> -- 
> Anne van Kesteren
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 9 Jul 2010 18:20:05 -0700 (PDT)

Hi Greg and requirements authors,

Please find my responses inline...

----- Original Message ----
> From: Greg Wilkins <[email-masked]>
> To: ; gabriel montenegro <[email-masked]>
> Cc: ; [email-masked]; [email-masked]
> Sent: Thu, July 8, 2010 5:28:29 PM
> Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00
> 
> Gabriel,

I'm no longer editor of the requirements, but I've commented 
> below as
an individual.

[gm] sorry to see you go.

On 9 July 2010 04:20, gabriel 
> montenegro <> href="mailto:[email-masked]">[email-masked]> 
> wrote:

>    REQ. 
> 1:  The WebSocket Protocol MUST run directly on top of
>       the 
> transport over which the initial HTTP handshake was running
>       
> (typically TCP).

+1

[gm] Cool.

> ---
>    REQ. 2:  The 
> WebSocket Protocol MUST be able to handle (send and
>       receive) 
> messages on top of a TCP data stream connection.
> ---
> Suggest 
> rewording:

I don't think we should mix in size requirements 
> here.

[gm] Perhaps I've misunderstood what Req. #2 and #3 are for.
How do they differ? Also, both client and server requirements talk about "ordered discrete blocks"
(#12, #13, #15, #16). I imagine when one talks about blocks, there is some limit on those at least
for DoS protection but also to be able to interoperate ("what is the largest block we can exchange?").

I also notice that the protocol draft in section 4.2 (Data Framing) item 3.6 mentions length of the messages
and the fact that some lengths may not be reasonable, but no mention as to what that value is. 

> established communication channel.

Agreed the 
> reference to textual data is poorly defined.. see below:

>    REQ. 
> 5:  The protocol MUST be designed to support different frame
>       types 
> (e.g. binary).
> ---

I think "negotiation" is a loaded word 
> for this protocol, and I think some are
very much opposed to any negotiation 
> and prefer a declarative (or assumed)
approach.

[gm] Ok, others have also tripped on the choice of word here. The word is not as important
as stating what it is that should be supported (we can worry about the mechanism later).

I actually think that 
> there is no requirement to support different framing.
The requirement is that 
> we must be able to transport both binary and text
messages - if one framing 
> mechanism can do both, then great!  So how

> textual data.

[gm] Having the "native" WebSocket wire protocol support both is definitely an improvement over the original version, yes. But if one wanted to use, say, XMPP over websockets, for that session there is no need for the native wire
protocol, so the above is not enough, but perhaps the sub-protocol requirement captures that.

> HTTP and HTTP compatible?

I have long argued that we should require 
> "compliance" rather than
compatibility.
Compliance implies a more than 
> compatibility in that telnet could be said to be
HTTP compatible because you 
> can telnet to port 80 and interact with a HTTP
server.  But telnet is 
> not HTTP compliant, because it can also be used to send
illegal HTTP.  
>   Compliance means that the HTTP conversation needs to be
legal HTTP up 
> until the websocket communication channel is established (for
which I agree 
> with your extra wording).

[gm] I'm still not clear on the difference, cuz if one's doing black-box testing then I wouldn't know
how you've implemented your HTTP stack (heck, it might be written in perl using a telnet client). And even
a native HTTP stack could be misused, I do agree
that we want whichever word implies a stronger adherence to HTTP up to the Upgrade. So perhaps we
can simply state what is desirable instead of relying on the right choice of words. See below. 

[gm] So to sidestep the compatible/compliant debate, how about this?: 

REQ. 7:  When sharing host and "well known" port with HTTP, the
       WebSocket protocol handshake MUST be indistinguishable from HTTP until both ends have
       established the WebSocket protocol.

> (e.g., upgrading to a TLS-enabled session 

I don't agree with this one.  Websocket should be a 
> specific
protocol, with specific
framing.  If you want to carry XMPP, 
> then you need to define a
binding for XMPP to
websocket framing.  I 
> think this subprotocol should represent this
binding and not
a different 
> framing mechanism.

[gm] In keeping with the goal of providing a TCP-like channel while adding as little
as possible it would be best if existing components (e.g. XMPP, etc) could be reused
as they are over TCP. Establishing the end-to-end communication channel via websockets
is great, but I don't see why the endpoint applications or sub-protocols cannot use 
whatever framing they are used to and understand after that. That is not to say that there
should be one native framing to guarantee interoperability (with support for both text and binary),
but why does it follow that it has to be the *only* one possible? For example, we could call the native 
wire format and framing the "Native" Sub-Protocol with the implication that unless otherwise
specified, that is the one to use, but still allow for other sub-protocols to use different framing.

>    REQ. 9:  
> The WebSocket Client MUST be able to set up a communication
>       

+1

[gm] Cool.

> so that the server can select one.,This results in the use of a 

Firstly I don't think the 
> requirements document should actually talk about
the handshake.  
> Handshaking is an implementation detail.

So the requirement should be 
> just about establishing sub protocols.
But again we come down to the two 
> different approaches - should the
sub-protocol be negotiated (in which case 
> your list of sub-protocol proposals
makes a lot of sense), or should it be 
> declarative (and the server can only
accept or reject).

I like 
> negotiation... but then if we negotiate one thing, we should 
> probably
negotiate more.

[gm] I think the proposed wording above is actually what you call
"declarative". What is proposed is for the client to state and the 
server can only accept or reject ("...the server can select one..."). 

So maybe the requirement is to support sub 
> protocols - if a particular
solution support negotiation, then great, but it 
> is not actually required?

[gm] yes, that's fine, the above wording actually does not
use the word "negotiation".

>    REQ. 12:  The 
> WebSocket Client MUST have the ability to send
>       arbitrary content 
>        sub-protocol in 
> effect.

+1

[gm] I think

>    REQ. 14:  The 
> WebSocket Server that accept to set up, with a
>       WebSocket Client, a 
> communication channel MUST send back to the
>       WebSocket Client a 
> well defined handshake.
> ---
> Suggest rewording as 
> follows:

Why is it a requirement to use a 
> handshake?
I think that is implementation detail and this REQ can be 
> dropped.

>    REQ. 15:  The 
> WebSocket Server MUST have the ability to send
>       arbitrary content 
>       in 
> effect.

+1

[gm] Your proposed rewording for REQ5 does not capture the sub-protocol aspect,
unless we say that the native text/binary support is the implied "Native" sub-protocol.
Then Req15 would be all that's needed without need for Req5.

>       as HTTP or HTTPS already does.

I think that is 
> a bit strong, because I don't think it is possible to
work with all 
> existing
proxies.    How about

    REQ. TBD: 
> WebSocket SHOULD work over existing proxies that do not impede
    
> the flow of a websocket communication channel.

Ie - if a proxy like 
> haproxy can be made to work with websocket
without upgrading
the proxy, 
> then we should work with it.

[gm] This is more precise, yes. Perhaps saying saying "to the same extent of HTTP" was
overly optimistic. The fact is that after the upgrade, it won't be HTTP any more, so we
can't realistically expect every proxy to continue working as before, I'm sure something 
somewhere will break. Your wording is more realistic.

thanks,

Gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 9 Jul 2010 18:30:10 -0700 (PDT)

Hi Anne,

please see my comments inline...

> On Thu, 08 Jul 2010 20:20:15 +0200, gabriel montenegro <> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]> 
> wrote:
>    REQ. 1:  
> The WebSocket Protocol MUST run directly on top of a
>      
> No 
> need to say anything, as the point is that whatever HTTP was
> running 
> over should continue to be used after the upgrade. Typically
> this is 
>    REQ. 1:  The 
> WebSocket Protocol MUST run directly on top of
>      the 

I think the requirement should be removed then. 
> The requirements shouldn't constrain us to a HTTP handshake.

[gm] Hmmm... I was under the impression that the whole point was to 
start with HTTP and then via the Upgrade directive move into the
WebSocket protocol. Or are you saying that there might be other ways
to start other than HTTP?

> handshake was running (typically TCP).

Why should we constrain size in 
> the requirements?

[gm] Please see my response to Greg's message.

>    REQ. 11:  The WebSocket 
> Client MUST be able to request the server,
>      during 
> the handshake, to use a specific WebSocket sub-protocol.
> ---
> 
>    REQ. 11:  During the 
> handshake ,the WebSocket Client MUST be able
> to send one or more 
> WebSocket sub-protocol proposals to the server
> so that the server can 
> select one.,This results in the use of a specific
> WebSocket 
> sub-protocol.

I don't think this is needed. It's also something that can 
> easily be added later if application authors find a need for 
> it.

[gm] Are you disagreeing with the proposed rewording or with the original
wording?:

"   REQ. 11:  The WebSocket Client MUST be able to request the server,
      during the handshake, to use a specific WebSocket sub-protocol.
"

The rewording did not change the basic requirement for sub-protocol support, it
was just adding more text as to how that might happen.

thanks,

Gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 9 Jul 2010 18:35:52 -0700 (PDT)

Hi Micheil,

Please see inline...

----- Original Message ----
> I think there's only one change, in what I've read of this thread (since the 
from Gabriel, 9th July 2010) that I could argue against as a protocol 
> implementor

The 
> only thing that does stand out is the message size constriants, which 
> would
not be a good idea. If a client sends a message that is too large, then 
> it is up to
the server-side developer to decide if they want to disconnect 
> the socket for that
reason.

[gm] Please see my response to Greg's message on this topic. 
One thing that comes to mind is what if it's a legitimate client trying to figure out
what the largest message to the server is. finding this out by facing a series of
socket disconnects can be tedious.

The second point I find interesting is the 
> sub-protocol negotiation point, this is
something that I think would possibly 
> be a good idea, but may add unneeded
complexity.

[gm] Is this because of the unfortunate use of the word "negotiation"?

The original wording in the draft alrady called for sub-protocol support thus:

the proposed rewording just called out the fact that the client proposal 
might involve more than one sub-protocol, but the server would only choose
one. This is exactly how Upgrade works in HTTP1.1 already.

thanks,

Gabriel

---

From: "Anne van Kesteren" <[email-masked]>
Date: Sat, 10 Jul 2010 07:57:25 +0200

> to start other than HTTP?

Yes, but mostly I'm saying that the requirements document should not  
constrain the design to this level of detail.

> [gm] Please see my response to Greg's message.

Please see above. :-)

> The rewording did not change the basic requirement for sub-protocol  
> support, it was just adding more text as to how that might happen.

The rewording suggests the client transmits one or more sub-protocols. I  
don't think we necessarily need to go there (too complex for v1 and  
probably not needed at all) and the requirements document should not  
constrain that. Having said that, I'm not even sure it makes sense to talk  
about sub-protocols in the requirements document. Requirements should be  
high-level.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 10 Jul 2010 08:38:25 +0200

> constrain the design to this level of detail.

But the original one is (unfortunately) even much more detailed. So
maybe what should be done is to detail only the WebSocket protocol
after the Upgrade, ensuring it works on top of raw TCP without the
HTTP Upgrade, then add a paragraph explaining how to use it after an
HTTP Upgrade when the port is shared.

And after all, that becomes logical and clear. We could state that
by default, the WS protocol consists in the framing we currently
see after the Upgrade. Clients explicitly talking to port 80 SHOULD
use the HTTP Upgrade method. Those passing through proxies must also
use the CONNECT method first (then either raw proto or HTTP upgrade
depending on the port). That would leave all combinations possible
and an easy way for the client to know which one to pick.

And after all, that's precisely what RFC2817 already suggests for
TLS over HTTP.

Regards,
Willy

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 12 Jul 2010 02:48:41 -0700 (PDT)

Hi Anne,

> From: Anne van Kesteren <[email-masked]>

> Yes, but mostly I'm saying that 
> the requirements document should not constrain the design to this level of 
> detail.

[gm] I think it is appropriate, given that we're supposed to be working on what
the charter set out to do:

"  The Hypertext-Bidirectional (HyBi) working group will seek
  standardization of one approach to maintain bidirectional
  communications between the HTTP client, server and intermediate
  entities, which will provide more efficiency compared to the current
  use of hanging requests.
"

That seems pretty clear about HTTP usage. 

> requirements?

Please see above. :-)

[gm] Not sure the above was specifically related to the size discussion, so perhaps
I'm missing something.

>> to send one or 
> more
>> so 
> that the server can
> I 
> don't think this is needed. It's also something that can
> easily be added 
> [gm] 
> Are you disagreeing with the proposed rewording or with the original
> 
> wording?:
> 
> The rewording 
> did not change the basic requirement for sub-protocol support, it was just 
> adding more text as to how that might happen.

The rewording suggests the 
> client transmits one or more sub-protocols. I don't think we necessarily need to 
> go there (too complex for v1 and probably not needed at all) and the 
> requirements document should not constrain that. Having said that, I'm not even 
> sure it makes sense to talk about sub-protocols in the requirements document. 
> Requirements should be high-level.

There was some discussion with Greg about this. There is some overlap with
Req.5 which does not actually talk about sub-protocols. That term is not as
important as somehow capturing that different framings should be allowed
(with one native format for interoperability).

thanks,

Gabriel

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 12 Jul 2010 12:10:22 +0200

On Mon, 12 Jul 2010 11:48:41 +0200, gabriel montenegro  
<[email-masked]> wrote:
>> the requirements document should not constrain the design to this level  
>> of detail.
>
> [gm] I think it is appropriate, given that we're supposed to be working  
> on what the charter set out to do:
>

Not to me. The main reason we are discussing what "HTTP compatible" means  
and how the "HTTP handshake" ought to look is because someone at IANA  
thought WebSocket should share a port with HTTP. It has nothing much to do  
with the charter. And frankly, it seems like things might be much easier  
if we did not share a port with HTTP.

> [gm] Not sure the above was specifically related to the size discussion,  
> so perhaps I'm missing something.

Effectively, too much detail for the requirements document.

> There was some discussion with Greg about this. There is some overlap  
> with Req.5 which does not actually talk about sub-protocols. That term  
> is not as important as somehow capturing that different framings should  
> be allowed

That is directly contrary to the draft proposal we have today. It only  
allows clients to use frames that are defined in the specification.

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 12 Jul 2010 03:19:42 -0700 (PDT)

Hi Willy,

Practically speaking, ports 80 and 443 are what 
will allow websocket connectivity to work, but I see what you mean.
Yes, specifying along the lines of RFC2817 might make sense. 

----- Original Message ----
> From: Willy Tarreau <[email-masked]>
> To: ; Anne van Kesteren <[email-masked]>
> Cc: ; [email-masked]; gabriel montenegro <[email-masked]>
> Sent: Fri, July 9, 2010 11:38:25 PM
> On 
> Sat, 10 Jul 2010 03:30:10 +0200, gabriel montenegro
> <> ymailto="mailto:[email-masked]" 
> Yes, but mostly I'm 
> saying that the requirements document should not
> constrain the design to 
> this level of detail.

But the original one is (unfortunately) even much 
> more detailed. So
maybe what should be done is to detail only the WebSocket 
> protocol
after the Upgrade, ensuring it works on top of raw TCP without 
> the
HTTP Upgrade, then add a paragraph explaining how to use it after 
> an

And after all, that becomes 
> logical and clear. We could state that
by default, the WS protocol consists 
> in the framing we currently
see after the Upgrade. Clients explicitly talking 
> to port 80 SHOULD
use the HTTP Upgrade method. Those passing through proxies 
> must also
use the CONNECT method first (then either raw proto or HTTP 
> upgrade
depending on the port). That would leave all combinations 
> possible

And 
> after all, that's precisely what RFC2817 already suggests for
TLS over 
> HTTP.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 12 Jul 2010 12:27:25 +0200

> if we did not share a port with HTTP.

If it does not share the port, then it will not replace existing protocols !

Also there are good reasons for sharing ports :
  - you can't reasonably assign new well-known ports, since most visitors
    from enterprise networks won't be able to access them for a long time,
    thus limiting adoption.

  - expecting a new address to be assigned for each service is not
    practical for shared hosting providers who manage hundreds or
    thousands of customers on shared equipments, all routed on the HTTP
    Host header only. Clearly those ones will not start assigning a
    dedicated IP to every customer that asks for one just for WebSocket.

  - in many environments there will be a need for Host-based forwarding
    or even cookie-based server stickiness. This is already possible on
    other HTTP-based mechanisms, and will be required for newcomers if
    the intent is to make long-polling disappear.

The fact that HTTP compliance is required might be the problem though.
I'd prefer to see the protocol described as the part after the HTTP
handshake, and simply state that people who want to use it over HTTP
will just have to perform the HTTP handshake first. Check RFC2817, it
explains the same principle for TLS over HTTP. This leaves a large
degree of freedom for implementers, allows for less overhead for those
who don't intend to share a port with HTTP, and allows for higher
accessibility for those who can't proceed differently.

In my opinion, the HTTP handshake should just be a paragraph in
the spec, not 90% of the spec.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Jul 2010 13:06:22 +0200

On 12.07.2010 12:10, Anne van Kesteren wrote:
> ...
> Not to me. The main reason we are discussing what "HTTP compatible"
> means and how the "HTTP handshake" ought to look is because someone at
> IANA thought WebSocket should share a port with HTTP. It has nothing
> much to do with the charter. And frankly, it seems like things might be
> much easier if we did not share a port with HTTP.
> ...

Was IANA actually asked? When? Why would *they* care, being just ther 
registry?

What should be relevant is the IETF consensus.

Best regards, Julian

---

From: Sander Striker <[email-masked]>
Date: Tue, 13 Jul 2010 11:31:31 +0200

On Mon, Jul 12, 2010 at 12:10 PM, Anne van Kesteren <[email-masked]> wrote:
>> [gm] I think it is appropriate, given that we're supposed to be working on
>> what the charter set out to do:
>>
> with the charter. And frankly, it seems like things might be much easier if
> we did not share a port with HTTP.

Come again?  Reading the threads here on this very list, the main
reason was reach.  Arbitrary ports are not likely to be reachable
through firewalls.  I thought that this was the reason Websocket
wanted to "piggyback" on HTTP.

Reasons like "someone at IANA said" seem a bit awkward.  I'd really
like to see IANA's official response if that is the real reason.

Cheers,

Sander

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 13 Jul 2010 19:44:39 +0900

> much easier if we did not share a port with HTTP.

I agree. Ports, especially those below 1024, are scare, so it's quite 
understandable that IANA was reluctant to allocate a new port number for 
an individual or a third-party organization. But we are an IETF WG. If 
we decide that we better use a separate port for websockets, we just say 
so in the spec, and some time between now and when the spec is published 
as an RFC, IANA will tell us what port number we get. For details, 
please see http://tools.ietf.org/html/rfc2780.

There are some good reasons to reuse the http ports, but there are also 
some good reasons to not do so.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 13 Jul 2010 13:34:54 +0200

> some good reasons to not do so.

In my opinion we should distinguish the *need* for reusing HTTP ports from
the need to use a separate ports. Those are two distinct things. The reuse
of the HTTP port is for the port, but not only, it's also for everything
belonging to HTTP (URL switching, virtual hosting, etc...). For this reason
it seems urgent to define the protocol as if the port was dedicated to it,
and then define how it can be upgraded from standard HTTP.

Regards,
Willy