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

> As chair, I note that the agreement regarding masking (client MUST mask to server) was one of the main points behind the VERY hard fought consensus. I think this is one of those things we can revisit in version 1.1, along with others we've been noting recently.

I think I understood that consensus slightly differently, more as a capability + operational practice than a protocol requirement.  Like I said to John, whatever the text says, masking will be appropriate in most cases.

> As an individual, the MAY mask on Server to client seems to gain nothing (I'm with John Tamplin on this one) and potentially lose something (sendfile), so I'd rather say MUST NOT here.

It doesn't rule out sendfile, since the server can choose not to apply masking.  All the proposed text does is clarify that the server has the choice (as it does in the current text).

--Richard 

> 
>> -----Original Message-----
>> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
>> Peter Saint-Andre
>> Sent: 08 September, 2011 09:15
>> To: Richard L. Barnes
>> Cc: hybi@ietf.org
>> Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt
>> 
>> On 9/8/11 9:06 AM, Richard L. Barnes wrote:
>>> [trimmed for brevity]
>>> 
>>> On Sep 7, 2011, at 10:17 AM, John Tamplin wrote:
>>> 
>>>> On Wed, Sep 7, 2011 at 8:32 AM, Takeshi Yoshino <tyoshino@google.com>
>> wrote:
>>>> Yes. That's unexpected side-effect of addition of MASK bit. Without the flag,
>> there was no information in a frame if it's masked or not so client just had to
>> follow what the spec says. So, client never encountered such situation.
>>> 
>>> It should also be noted that if the MASK bit is eliminated, then the recipient of
>> a frame can't even parse it in the current format, since it doesn't know whether
>> the first four octets are a masking key or not.
>>> 
>>> 
>>>> I expect it will get used as a WS-variant when dealing with non-browser
>> clients -- ie, between a frontend which handles
>> masking/aggregation/deaggregation/SSL and the ultimate backend, I would not
>> be surprised if there were unmasked client->server frames.  As long as all the
>> browser clients all enforce masking on their connections, the problem masking
>> was added for is averted.
>>> 
>>> This seems to argue against Gabriel's proposed "c2s MUST / s2c MUST NOT".
>> Proposed alternative:
>>> 
>>> OLD: "All frames sent from the server to the client are not masked."
>>> NEW: "Frames sent from the server to the client MAY be masked."
>>> 
>>> OLD: "All frames sent from the client to the server are masked to avoid ..."
>>> NEW: "Frames sent from the client to the server SHOULD be to avoid ..."
>>> 
>>> NEW: "Servers MUST NOT reject un-masked frames, unless masking is required
>> by local policy."
>> 
>> Personally (not as your Area Director), that's fine with me.
>> 
>> As your Area Director, I'd appreciate feedback from WG participants so
>> that we can reach closure on this issue.
>> 
>> Peter
>> 
>> --
>> Peter Saint-Andre
>> https://stpeter.im/
>> 
>> 
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
> 