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

Please admit defeat (was: Our Schedule)

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 26 May 2014 06:34:25 +0000
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <1282.1401086065@critter.freebsd.dk>
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 06:34:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 26 May 2014 06:34:52 UTC