Re: Focusing our discussion on issues

In message <>, Mark Nottingham wri

>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

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

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


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