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

Re: Call for Consensus: Remove "reference set" from HPACK (to address #552)

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 16 Jul 2014 16:59:22 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <FC70FBE4-6D68-4A48-9E42-B86F4B6F6B09@mnot.net>
To: Cory Benfield <cory@lukasa.co.uk>, Johnny Graettinger <jgraettinger@chromium.org>

On 16 Jul 2014, at 4:54 pm, Cory Benfield <cory@lukasa.co.uk> wrote:

> On 16 July 2014 03:31, Mark Nottingham <mnot@mnot.net> wrote:
>> What do people think of this proposal?
>> So far, my reading of the WG is that we want to get rid of the reference set, and are just talking about the details of how to do so.
> Myself and a few others are hesitating here. Roberto and Johnny have
> both suggested that they believe the reference set _is_ helpful, and I
> believe Johnny is collecting data to prove the point. I'd like to be
> forward-looking where we can, so I'm inclined to want to wait a week
> or so to see what data Johnny can collect.
> Is that problematic from the perspective of our timetable?

Last we heard from him on this AFAIK was:

> It would still be interesting to do, but only if there's honest engagement and buy-in from the list. Setting up something like this takes time, and is not compatible with the rate-of-change in arguments we're seeing on the list lately.

and then:

> The core metric of interest seems to be the compression performance (aggregated byte-length ratio) of a delta encoder + Huffman. We can provide separate ratios for an encoder with and without the reference set.
> This should hopefully inform the question before us, but is of little utility for future experimentation with compressors. That's unfortunate, but I think it's just the trade-off for getting good coverage.

Johnny, would you be able to provide any indication in a short time frame, or are we talking about something longer-term?

Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 16 July 2014 06:59:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC