Re: Please admit defeat (was: Our Schedule)

Poul-Henning,

On 26 May 2014, at 4: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”.

This is a gross mischaracterisation of what I said. I appreciate that you have a flair for the dramatic, but kindly refrain from putting words in my mouth.


> 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:

This isn’t a parliamentary body, nor are Roberts’ Rules in effect. We don’t need motions, we need good technical arguments.


>  * Credit SPDY as a very good and worthwhile prototype,

Done.


>  * Acknowlege that SPDY overwhelmingly showed that there are a lot
>    of room for improvement over HTTP/1.1,

I think we’re there.


>  * 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.

I don’t hear the engineers who have put a year and a half of work into this effort talking about "defeat" nor about it being a “fiasco.” They’re a very good representation of HTTP implementers, and from what I’ve heard to date, they think we’re getting close to shipping. 

If you want to come and make technical proposals in good faith, ask questions, argue for specific approaches, etc. you are — as always — welcome to participate. 


> 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.

Changing the semantics of HTTP are out of scope for good reason; if we change semantics, it creates incompatibility with the existing Web. As much as many people would like to get rid of Cookies — something you’ve proposed many times — doing it in this effort would be counter-productive.


Cheers,


--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 26 May 2014 09:14:59 UTC