Re: [hybi] Review of draft-ietf-hybi-thewebsocketprotocol-13

[Iñaki Baz Castillo <[e-mail]>]

2011/9/6 Richard L. Barnes <[e-mail]>:
> Clearly it already has to be WebSocket aware, and it already has to read the opcode in order to distinguish data frames from control frames.  Adding on a requirement to break at code point boundaries does not seem hugely onerous.  It's three lines of C:

No please. WS framing is like a "transport" layer, not application layer.

> In contrast, *not* requiring breaking at UTF-8 code points means that clients can't do any meaningful validation on text frames.  Which means you might as well get rid of text frames entirely.

I strongly propose changing the meaning of 1007 status code from:

      1007 indicates that an endpoint is terminating the connection
      because it has received data that was supposed to be UTF-8 (such
      as in a text frame) that was in fact not valid UTF-8 [RFC3629].

to:

      1007 indicates that an endpoint is terminating the connection
      because it has received a message that was supposed to be UTF-8
      that was in fact not valid UTF-8 [RFC3629].


WS message format MUST be validated when receiving all the frames
belonging to such message, as message inspection/usage belongs to the
WS application, rather than the WS "transport" layer (frames).

As I've said before, these issues are caused due to the lack of
*logical layers* in the protocol spec.

-- 
Iñaki Baz Castillo
<[e-mail]>