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

[Alexey Melnikov <[e-mail]>]

Peter Saint-Andre wrote:

>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 <[e-mail]> 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 ..."
>>    
>>
I assume you've missed out "masked" after "SHOULD be".

>>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.
>  
>
Personally (not as an editor), I am fine with this text as well.

>As your Area Director, I'd appreciate feedback from WG participants so
>that we can reach closure on this issue.
>  
>