Re: Our Schedule

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.

HPACK is too damned complex. Sure, there are very smart people all over the
world who will get it right but as we see with things like heartbleed, it
only takes one bug in one popular implementation to cause major problems
for everyone. If the complexity is not justified, the risk that comes along
with that complexity is even less so.

So far, in this thread, there have been quite a few voices willing to speak
up and question whether HPACK is the right choice. And while some of those
voices may have a "flair for the dramatic", I trust that they are very
intelligent voices that are worth listening too.

As far as I'm concerned, I'm strongly -1 on moving forward on the proposed
schedule with an http/2 that normatively requires HPACK.
On May 26, 2014 6:13 AM, "Cory Benfield" <cory@lukasa.co.uk> wrote:

> On 26 May 2014 at 13:27:45, Michael Sweet (msweet@apple.com) wrote:
> > ...
> > If we leave out HPACK for 2.0 (or adopt a simpler HPACK) we can get some
> > operational experience to determine whether further complexity is
> required or
> > justified.
>
> +1. I’d like to discuss the idea of simplifying or abandoning HPACK.
>
>