W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

RE: Header Compression: Reference set choice

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Thu, 1 Aug 2013 08:06:59 +0000
To: James M Snell <jasnell@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E52F45955A@ADELE.crf.canon.fr>
I agree that this adds some complexity to the compression mechanism.

At the same time, I think that the complexity is rather limited on the implementation point of view. You're not required to add anything to the encoder, you have only a few lines to add to your decoder.

In addition, at runtime, using this can allow for some reduced complexity for the encoder, with only a small or no impact on the compaction side.

From: James M Snell [jasnell@gmail.com]
Sent: Wednesday, July 31, 2013 02:34
Cc: ietf-http-wg@w3.org
Subject: Re: Header Compression: Reference set choice

Given an initial review... I believe this proposal moves us even
further into the "Being Too Clever" category without any significant
benefit. The current header compression mechanism (in my opinion)
already adds too much additional unwarranted complexity and this would
just add more to support one possible optimization whose benefits are
undemonstrated and unproven. At this point, I'd rather spend effort
finding ways to trim back the complexity and not add to it further.

On Tue, Jul 30, 2013 at 7:53 AM, RUELLAN Herve
<Herve.Ruellan@crf.canon.fr> wrote:
> We did some work on the diff part of the header compression format, and are proposing enhancements to the choice of the reference set used to encode a new header set (i.e. the starting point for the diff). This is detailed in a draft:
> http://tools.ietf.org/html/draft-ruellan-reference-set-definition-00
> This is still work in progress, as we didn't have time to do enough measurement, in particular on long lasting connections.
> Comments are welcome,
> Hervé.

Received on Thursday, 1 August 2013 08:07:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC