[hybi] call for feedback on Masking alternatives

[Salvatore Loreto <[e-mail]>]

(as HyBi wg co-chair)


Hi there,

Last Tuesday, during the HyBi wg session at the IETF meeting, we 
discussed the masking issue.

Based on that discussion, the decision is **only between two alternatives**:
whether to (1) mask the entire frame, as in the current 06 spec,
or to (2) mask only after the op codes and length.

In the wire format for (1), the 32-bit masking-key appears first, and 
then the entire frame masked (as in 06):

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------------------------------------------------------+
      |                       Masking-key                             |
      +-+-+-+-+-------+-+-------------+-------------------------------+
      |F|R|R|R| opcode|R| Payload len |    Extended payload length    |
      |I|S|S|S|  (4)  |S|     (7)     |             (16/63)           |
      |N|V|V|V|       |V|             |   (if payload len==126/127)   |
      | |1|2|3|       |4|             |                               |
      +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
      |     Extended payload length continued, if payload len == 127  |
      + - - - - - - - - - - - - - - - +-------------------------------+
      |                               |         Extension data        |
      +-------------------------------+ - - - - - - - - - - - - - - - +
      :                                                               :
      +---------------------------------------------------------------+
      :                       Application data                        :
      +---------------------------------------------------------------+


In the wire format for (2), the masking-key appears after the op codes 
and length fields.
This is where 06 shows the "Extension data". The extension data and the 
rest of the frame would be shifted 32 bits and it would all be masked.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-------+-+-------------+-------------------------------+
      |F|R|R|R| opcode|R| Payload len |    Extended payload length    |
      |I|S|S|S|  (4)  |S|     (7)     |             (16/63)           |
      |N|V|V|V|       |V|             |   (if payload len==126/127)   |
      | |1|2|3|       |4|             |                               |
      +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
      |     Extended payload length continued, if payload len == 127  |
      + - - - - - - - - - - - - - - - +-------------------------------+
      |                               |         Masking-key           |
     +---------------------------------------------------------------+
      |    Masking-key (continued)    |         Extension data        |
      +-------------------------------+ - - - - - - - - - - - - - - - +
      :                                                               :
      +---------------------------------------------------------------+
      :                       Application data                        :
      +---------------------------------------------------------------+

In both cases, everything after the Masking-key is masked.

Several folks have already expressed themselves on this issue either 
recently on the mailing list, or in person at the IETF meeting this week.

Gabriel and I, as HyBi wg chairs, would like to solicit only those who 
have not yet expressed themselves on this issue, to do so now.

We will wait for additional feedback **until Friday April 8**, and based 
on the feedback will make a decision shortly afterward.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com