Re: [hybi] Masking only Payload/Extension Data

[John Tamplin <[e-mail]>]

On Wed, Mar 9, 2011 at 1:41 PM, <[e-mail]> wrote:

> Let me join in the voices for +1 on the use of reserved bit.
>
> I agree with your points of debate in the following messages:
>  - http://www.ietf.org/mail-archive/web/hybi/current/msg06631.html
>  - http://www.ietf.org/mail-archive/web/hybi/current/msg06633.html
>
> Reasons:
>
>  o Sniffers can choose whether to go ahead and parse masked payload
>    based on the bit without having to capture from the start.
>    (It greatly helps us in debugging or trouble shooting)
>

I agree this is useful, but I disagree that this is sufficient to warrant
the cost.


>  o Ability to turn off masking for debugging/trouble shooting.
>    (this should not be manipulable by user code, of course, just to be
> clear)
>

This is orthogonal to whether to use a bit in the frame, and from previous
discussions there is little support for being able to disable it.


>  o It is worthier allocating a bit for this than reserving it
>    for something we don't even know especially when we still have
>    at least a few bits left.
>

The problem is there are only a few reserved bits, and we don't know how
many it would be useful to have.  One thing that was discussed earlier that
would require allocation of a reserved bit would be per-frame compression,
so you can avoid compressing non-compressible data.  Another possibility is
that we generally allocate more opcodes for extensions, in which case we
would like to be able to allocate some of the reserved bits to the opcode
field.  We won't know we used too many until we need more than we have, at
which point it becomes expensive (50% additional overhead for small frames)
to get more.  When we came up with this framing, this was the compromise
between cost and leaving options open for the future that everybody could
live with.

Think about it from an efficiency point of view -- you are suggesting
allocating a bit in every frame that is going to be the same for every frame
in the same direction.  How can that possibly be good stewardship of limited
resources, rather than specifying it once in the header (or not at all if it
is known to be set or clear based on which side is initiating the
connection)?

 o Lacking the bit seems to be the source of sense of asymmetry -
>    as in the frame not being self-descriptive for what's in the
>    payload (not to be confused by 'understanding' the payload),
>    seems to be a bad protocol design choice.
>

The frame is already not self-descriptive -- if compression is negotiated,
you have to know that (plus the current compression state) in order to
interpret the frames.  Likewise, other extensions will likely modify
interpretation of the payload.

I still think it is not worth allocating a reserved bit to indicate masking
is present, but if most people want it I won't object too strenuously.

-- 
John A. Tamplin
Software Engineer (GWT), Google