Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-01.txt

[James Graham <[e-mail]>]

On 09/02/2010 12:45 AM, [e-mail] wrote:

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-01.txt

A few initial comments:

The framing sections seem to have a lot of SHOULDs. This is worrying as 
SHOULD-level conditions can't really be tested (it is not an error to 
violate them) and can be a source of interoperability problems. I would 
prefer that we make all behaviour mandatory unless there is a good 
reason to do otherwise.

Some specific clauses seem problematic. For example:

"""A receiver MUST be prepared to accept arbitrarily fragmented
       messages, even if the sender sent the message in a single frame."""

"be prepared to accept" seems like poor wording. I would just say 
"Clients and servers MUST support recieving both fragmented and 
unfragmented messages". The clause "even if the sender sent the 
message..." seems odd because it is not clear how the recipient can know 
how the message is originally sent. In any case it seems redundant. This 
whole clause could be avoided with normative processing requirements 
that require support for fragmented and unfragmented messages (see below).

"""Ping

       Upon receipt of a Ping message, an endpoint SHOULD send a Pong
       response as soon as is practical.  The Pong response MUST contain
       the payload provided in the Ping message, though an implementation
       MAY truncate the message at an implementation-defined size which
       MUST be at least 8 _(TBD)_ bytes."""

It seems simpler and less error prone to require truncation always in 
case servers come to depend on the behaviour of specific implementations 
here.

"""      Ping frames MAY be sent as a keep-alive mechanism, but if so 
the interval SHOULD be configurable."""

I have no idea what this SHOULD is trying to require. Is it supposed to 
be a requirement on browser UI? On server implementations? Something 
else? In any case, we can't really require that things are configurable.

"""Close:

       Upon receipt of a close frame, an endpoint SHOULD send a Close
       frame to the remote recipient, if it has not already done so,
       deliver a close event to the application if necessary, and then
       close the WebSocket."""

It is not clear what the scope of the SHOULD here is. Since this is 
nested inside a MUST clause I guess "and then close the connection" is 
supposed to be a requirement. I'm not sure why sending the close frame 
is "SHOULD". I don't think it is necessary to talk about "deliver[ing] a 
close event to the application" since the interaction between the 
application and the protocol is for the application to determine. For 
the specific case of the JS API we just need to ensure we use the right 
terminology so that the description in the API document is correct (i.e. 
this needs to match section 7.3 of the protocol draft and section 5 of 
the API draft).


There seems to be a general lack of processing requirements. I don't 
know if this is just something that is missing from the first draft, but 
without such requirements there are a lot of missing details. For 
example it is unclear what happens if the first frame a client receives 
has opcode=0 (aside: it seems like we can design around this particular 
problem by e.g. ditching opcode=0 and just ignoring opcode after the 
first frame in a fragment). It is also not defined what should happen if 
any of the reserved bits are set or if the opcode is in the reserved 
range. All of these things are essential for interoperable implementations.