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

[Takeshi Yoshino <[e-mail]>]

On Thu, Sep 1, 2011 at 16:23, Len Holgate <[e-mail]> wrote:

>  4.2.1 step 6 should probably say "value of 13".
>

Yes, it's a bug.


>  Why doesn't 5.1 use MUST and MUST NOT when talking about client to server
> and server to client masking. Up until now I was under the impression that
> the server COULD mask data if it really wanted to (hence the need for the
> masking bit rather than simply assuming that client -> server == masked and
> server -> client != masked. The text in 5.1 now seems to imply that the
> server SHOULD NOT mask but it doesn't say so. I realise that client ->
> server masking is required and is specified with MUST in another part of
> the
> document but I think it should be made clear that a server CAN mask if it
> really wants to so that we don't end up with client implementations that
> don't expect to receive masked frames. One situation where I might wish to
> mask a frame from server to client would be in a pong where there's no need
> for me to unmask the data if I simply echo the ping directly back...
>

This is continuation of this thread. I think we should clarify this, i.e.
use MUST NOT or MAY here, or we'll see the same question repeatedly in the
future.
http://www.ietf.org/mail-archive/web/hybi/current/msg07768.html

If we allow the server to mask frames, clients need to implement logic for
unmasking to prepare for them. As we don't know any important use-case of
server-to-client masking, I think we should just forbid it.
OLD: All frames sent from the server to the client are not masked.
NEW: All frames sent from the server to the client MUST NOT be masked.

Let's also change
OLD: All frames sent from the client to the server are masked to avoid ...
NEW: All frames sent from the client to the server MUST be masked to avoid
...

Thanks,
Takeshi