Re: agenda/charter brainstorming

Hi PHK,

Glad you brought that up. People have been quietly talking about this in the background. While it's still too early to talk about this for any great length of time in the WG, I do think that we should start discussing what HTTP/3 might look like. 

We'll likely talk about this *briefly* in Toronto; I'm still thinking about how to make the effort productive and representative.

Cheers,


On 23 Jun 2014, at 7:06 pm, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> In message <53A7E8BA.8090809@gmx.de>, Julian Reschke writes:
>> Hi there,
>> 
>> here are some ideas for what the WG could/should work on in the 
>> post-HTTP2-LC time:
> 
> HTTP/3.0
> --------
> 
> A non-backwards compatible, heavily cleaned up HTTP and much simpler
> HTTP protocol for the longer future:
> 
> Goals:
> 
>    Scale towards Tbit/s speeds on contemporary silicon
> 	Fiber to the home is coming, we need to deal
> 	with it.
> 
>    Improve privacy in ways which does not force a crypto-arms-race.
> 	Indiscriminately adding crypto in the face of laws
> 	just means that the crypto will be circumvented or trojaned.
> 	We need to pay the king his shilling, in a way that means
> 	he doesn't have to take the entire pound.
> 
>    Reduce cruft and simplify the semantics of HTTP.
> 	HTTP has become too complex through accumulation of
> 	successive "convenient quick fixes" many of which
> 	nobody uses and most of which don't work reliably
> 	end-to-end any more.
> 
> Means:
> 
>    Define "routing-envelope" fields always sent in plaintext
> 	This enables load-balancing, also of otherwise secured
> 	transactions.  Eliminates need for certs on load-balancers
> 
>    Reduce the number of headers proxies need to pay attention to
> 	For speed and privacy.
> 	
>    Replace cookies with client chosen session identifiers
> 	This increases transmission performance a LOT and
> 	solves the problem EU's "cookie directive" tried to
> 	address.
> 
>    Allow privacy protected and plaintext requests on the same connection.
> 	Less connection-churn when upgrading.
> 	Better connection-aggregation by proxies.
> 
> Consequences:
> 
>    Semantic changes will force website designers to think more
>    clearly about privacy and thus this will not be a direct
>    "invisible" upgrade from prior HTTP versions.
> 	
> 
> 
> 
> -- 
> 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.
> 

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

Received on Tuesday, 24 June 2014 01:07:18 UTC