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

Re: Please admit defeat (was: Our Schedule)

From: Mike Belshe <mike@belshe.com>
Date: Mon, 26 May 2014 01:00:07 -0700
Message-ID: <CABaLYCsctbiG9hJiV8TypkCaNV9B5PgvJW1L8_JuRGznJBUtig@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>

On Sun, May 25, 2014 at 11:34 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> In message <315A1736-1C33-403D-AC5F-6E488B880FAE@mnot.net>, Mark
> Nottingham wri
> tes:
> >The overwhelming preference expressed in the WG so far has been to work
> >to a tight schedule. HTTP/3 has already been discussed a bit, because we
> >acknowledge that we may not get everything right in HTTP/2, and there
> >are some things we haven't been able to do yet.
> This is probably the most damning thing in this entire fiasco:
> The Mythical Man-Month was published in 1975, and without even
> the slightest hint of room for exceptions, it told us to:
>         "Always throw the prototype away."
> The WG took the prototype SPDY was, before even completing its
> previous assignment, and wasted a lot of time and effort trying to
> goldplate over the warts and mistakes in it.
> And rather than "ohh, we get HTTP/2.0 almost for free", we found
> out that there are numerous hard problems that SPDY doesn't even
> get close to solving, and that we will need to make some simplifications
> in the evolved HTTP concept if we ever want to solve them.
> Now even the WG chair publically admits that the result is a qualified
> fiasco and that we will have to replace it with something better
> "sooner".
> So what exactly do we gain by continuing ?
> Wouldn't we get a better result from taking a much deeper look
> at the current cryptographic and privacy situation, rather than
> publish a protocol with a cryptographic band-aid which doesn't solve
> the problems and gets in the way in many applications ?
> Isn't publishing HTTP/2.0 as a "place-holder" is just a waste of
> everybodys time, and a needless code churn, leading to increased
> risk of security exposures and failure for no significant gains ?
> Wouldn't it be faster to go straight after the real goal, an
> protocol which CAN replace HTTP/1.1 in all scenarios and be
> an improvement in ALL scenarios ?
> Please admit defeat, and Do The Right Thing.
> I move that we:
>   * Credit SPDY as a very good and worthwhile prototype,
>   * Acknowlege that SPDY overwhelmingly showed that there are a lot
>     of room for improvement over HTTP/1.1,
>   * But cognizant of the problems we've run into, and in respect
>     for Fred Brooks sage advice we throw it out, now that we have
>     learned all that we can from it.
> and
>   * Immediately start the design a successor protocol to
>     HTTP/1.1, which through necessary simplifications of HTTP
>     semantics and based on what we learned from the SPDY prototype,
>     will become better than HTTP/1.1 for all uses and users.
> Poul-Henning
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 26 May 2014 08:00:34 UTC

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