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

[Sylvain Hellegouarch <[e-mail]>]

On Wed, Sep 7, 2011 at 7:55 AM, Takeshi Yoshino <[e-mail]> wrote:

> 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
> ...
>
>
Since the masking and unmasking are the same operations, I fail to
understand the added complexity of server-to-client masking. Clients already
know how to unmask since they can mask in the first place with the same
operation. In my mind you'll get more questions on the reason why it's one
way only as opposed to mask both ways. In fact the spec creates more
questions than it ought to when it suggests intermediaries may have problems
on client-to-server communication but not the other way around.

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach