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

Re: Our Schedule

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Mon, 26 May 2014 10:45:33 -0400
Message-ID: <CAOdDvNqT9BdA3mG3GvGRAjxhr_VuLr+XN68dQhpfDa+XtTbvUA@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Cory Benfield <cory@lukasa.co.uk>, Mark Nottingham <mnot@mnot.net>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Michael Sweet <msweet@apple.com>
On Mon, May 26, 2014 at 10:07 AM, James M Snell <jasnell@gmail.com> wrote:

> Mark has asked for technical arguments. My point of view is this:
> From day one, there has never been a strong technical argument *in favor*
> of HPACK... At least not one that justifies the significant increase in
> complexity. Header compression qualifies as a "nice to have" but is
> certainly not critical to preserving http semantics or even the operation
> of the framing protocol. HPACK should not be a normative requirement in
> http/2. If our concern is about saving bytes on the wire, there are less
> complicated ways to do so.

I disagree. the fundamental value of http/2 lies in mux and priority, and
to enable both of those you need to be able to achieve a high level of
parallelism. Due to CWND complications the only way to do that on the
request path has been shown to be with a compression scheme. gzip
accomplished that but had a security problem - thus hpack. Other schemes
are plausible, and ones such as james's were considered, but some mechanism
is required.

this is well worn ground. Forgive me if I don't weigh in on every episode
re-run while we do the implementation work to actually get this tested and
deployed. Looking forward to testing with everyone some more.

Received on Monday, 26 May 2014 14:46:00 UTC

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