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

[Greg Wilkins <[e-mail]>]

Gabriel,

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



On 9 July 2010 04:20, gabriel montenegro <[e-mail]> wrote:

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

+1



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

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




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

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

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.





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

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


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

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



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

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.


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

+1


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

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?



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

+1

(although it duplicates REQ5 a bit)

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


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


+1

(although it duplicates REQ5 a bit)


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