Re: Our Schedule

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.

-P