Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item

[Greg Wilkins <[e-mail]>]

On 2 March 2012 09:26, John Tamplin <[e-mail]> wrote:

> On Thu, Mar 1, 2012 at 3:04 PM, Takeshi Yoshino <[e-mail]>wrote:
>
>> I also wonder if it's useful to make it able to negotiate whether to use
>> compression bit or not on opening handshake.
>>
>
> Personally, I think that complicates things too much.  When we reserved
> the bit, one of the things we were reserving it for was per-frame
> compression.


I agree - we should either use a reserve bit or not - optional use is
probably the worst of both worlds.


The options I see we have are:

a) Just use the bit in this extension.  Any other extension that uses the
same bit will be incompatible and we leave it undefined how we work that
out.
b) Nominate the bit as some kind of general purpose per frame compression
bit, available to multiple compression extensions.
c) Come up with a system of dynamically allocated reserved bits. The
extension requests to use a bit and the server allocates one and indicates
which in the handshake response.  This would allow multiple reserve bit
using extensions to co-exist... up until our limit of reserved bits.
d) Don't use a reserved bit.  Use the first byte of the payload to indicate
if the frame is compressed or not.
e) Don't use a reserved bit. Compress all frames.

I see c) as probably too complex and too limited to be worth the effort.
So failing dynamic reserve bit allocation, I think if we don't allocate a
reserved bit for frame compression, then we will never allocate them for
anything.
If we don't allocate a reserved bit, I think there is enough previous
discussions to show that e) compress everything is not optimal.   d) is not
too bad, specially if meanings could be assigned to other bits in that byte
(eg a reset dictionary bit, a use dictionary but don't update it bit etc.)

So I think b) or d) are viable options

cheers