Re: Encouraging a healthy HTTP/2 ecosystem

On Wed, Jul 2, 2014 at 3:37 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <
> CABaLYCsvLCZPcDObg2A2yP8yG+aunsT1ZPyy_Ha9hGBCY15Heg@mail.gmail.com>, Mike
> Belshe writes:
>
> >> We have two (or more ?) major-ish browsers nixing HTTP/1 upgrade.
> >
> >protocol upgrade has always been optional at the client discretion.  this
> >is not new with http/2.
>
> Absolutely, just like my decision to implement HTTP/2 or not
> implement HTTP/2 is entirely discretionary.
>
> But such discretionary decisions people will make really big
> footprints on the future success of HTTP/2 in the wider web,
> so these "political statements" should weigh heavy in the
> judgement of the drafts future prospects.
>
> Of course if the only thing cares about are a few $BigWWW sites,
> then that doesn't matter, but if the question is if HTTP/2.0 is
> worthy of its name, it matters a LOT.
>

Your argument is full of name calling (political/bigwww) and nothing more.


>
> >> We have a number of proxies (involved in about 30-50% of all HTTP1
> >> content delivery) nixing CONTINUATION and we have a lot of webmasters
> >> who have yet to see any evidence that adding HTTP/2 support would
> >> ever be worth their while.
> >>
> > continuation is not a "throw the whole thing out" issue.
>
> Actually it is.
>
> It's a clear indication of technical ineptitude when it comes to
> good and clean protocol design.  I'm 100% certain that you'd get
> flunked by Andy Tanembaum for a END_STREAM flag which doesn't, and
> if that doesn't do it, a framesize with a maximum payload of (2^n-1)
> certainly will.
>

As usual, you're relying on name calling to amplify an otherwise minor
point.

Some of these features are artifacts of the standardization process which
wouldn't be my first choice either.  But they are good enough.


>
> >So now you're saying we should nix http/2, because you started talking
> >about http/3.
>
> I'm saying that if we rush into Last Call with the draft we have
> now, we have no choice but to start talking about HTTP/3 right away,
> because it is simply not good enough.
>
>
It is a misrepresentation to call HTTP/2 "rushed".   To the contrary, I
HTTP/2 may have more implementation experience from a more diverse set of
implementors than pretty much any protocol in the history of the IETF.  I
can't be certain of this claim, but it is undeniable that we have a lot
more experience with this protocol than most being standardized.  On the
time metric, we've now been working on it for over 2 years.  It's not
rushed at all.

I realize you disagree with the items you enumerated.  But lets not call
them 'rushed' just because you don't like them; its not rushed.

mike

>
>