Re: Focusing our discussion on issues

+1 to all of this.

Am 15.11.2013 um 09:45 schrieb "Poul-Henning Kamp" <phk@phk.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.
> 

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Received on Friday, 15 November 2013 08:51:34 UTC