W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Focusing our discussion on issues

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Fri, 15 Nov 2013 08:45:13 +0000
To: Mark Nottingham <mnot@mnot.net>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <42427.1384505113@critter.freebsd.dk>
In message <242B6E8E-BC39-44A0-8668-EEBDEBE4A416@mnot.net>, Mark Nottingham wri
tes:

>We've seen a lot of discussion of the proposed response to pervasive 
>monitoring, as well as a number of new participants (welcome!).
>
>The volume (in both senses of the word) of this discussion was perhaps 
>predictable, but it doesn't help us move forward.

First, I think everybody needs to step away from the keyboard and
re-read the chapter named "Second Systems Syndrome" in The Mythical
Man-Month.

By all means read all of the book while you're at it, and don't
worry if it will take you some days to buy the book first:  It will
save you much more time later in life.

Presently people are trying to make HTTP/2.0 resolve all their
current grieveances, be they related to HTTP or not, by cramming
their particular agenda into the proposed protocol.

That is not going to give us a good new protocol, certainly not
soon and likely not ever.

I motion that we call a timeout while people read up on their
classics, and propose that the WG:

A)      Define a successor to HTTP/1.1, which moves HTTP objects
	across *any* transparent byte-pipe with better performance
	than HTTP/1.1.

B)	If sensible, define an upgrade mechanisem from HTTP/1.1 to
	the new protocol, that reuse the underlying byte-pipe.

C)      Decide that discussions about selection of, and mapping of
	URI scheme to, byte-pipe carriers, is unnecessary and
	unproductive.


In re A:  Emphasis on *any*, if we can't beat HTTP/1.1 on *any*
	  connection, we're not doing a good enough job.

In re B:  This has proven much harder in terms of protocol-trickery,
	  port 80 is a lot less of transparent byte-pipe in
	  practice than some of us expected and it costs us a
	  performance hit during startup.
	  
In re C:  If we design HTTP/2.0 to be encryption agonistic, it
	  will not go down when any particular encryption protocol
	  policy sinks.  There is no point and no benefit in tying
	  ourselves to the mast

Thanks,


-- 
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 Friday, 15 November 2013 08:45:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC