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

I like option "d."  One framing byte of overhead is practically nothing and
enables lots of opportunities for tuning and control.  If the byte of
overhead is too much for some people, perhaps there could be a
configuration parameter during the handshake to allow the user to opt into
across-the-board compression settings that would eliminate the byte and
just apply to every frame.  That would allow users with
consistently compressible data to eliminate the one byte overhead.

Alternatively, we could define a control frame to configure the compression
extension that could turn the per-frame control byte on or off.

Brian

On Thu, Mar 1, 2012 at 4:11 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
>
> On 2 March 2012 09:26, John Tamplin <jat@google.com> wrote:
>
>> On Thu, Mar 1, 2012 at 3:04 PM, Takeshi Yoshino <tyoshino@google.com>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
>
>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>