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

[gabriel montenegro <[e-mail]>]

Hi Greg and requirements authors,


Please find my responses inline...


----- Original Message ----
> From: Greg Wilkins <[e-mail]>
> To: ; gabriel montenegro <[e-mail]>
> Cc: ; [e-mail]; [e-mail]
> 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:[e-mail]">[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

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

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

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

[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
about:

    
> REQ. 5:  The protocol MUST be designed to support both binary and
  
> 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.





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

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

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

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

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

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


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

[gm] Cool.

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

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

[gm] I think

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

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

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

[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