- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 20 Nov 2013 08:13:42 +0000
- To: Mark Nottingham <mnot@mnot.net>
- cc: James M Snell <jasnell@gmail.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
In message <87E9681E-64AF-44B9-B25E-7CD37A08F25B@mnot.net>, Mark Nottingham wri tes: >Much experience has shown us that MUSTs and SHOULDs are ignored when = >they're disconnected from implementation needs -- even if those = >requirements are intended for the greater good. Until we know how good or bad performance HTTP/2.0 has relative to HTTP/1.1, it is very hard to gauge how marketable HTTP/2.0 will be in what segments, and consequently what the implementation needs will be. I feel it is premature to try to decide 314, until we know the protocol we're talking about much better. That being said, my position is always that attempting to push a political agenda with technical means is fools errand, and the end-to-end principle of systems design certainly argues against attempting to do it with one of the bits in the middle. So I think we should give people maximum freedom: 1. HTTP/2 on separate port, unencrypted or with per trasaction encryption, for maximum performance. 2. HTTP/2 as upgrade on TLS. People tell us that there is a roboust negotiation mechanisem and sufficient transparency on 443. 3. Leave port 80 as HTTP/1 only because there is too much "pidgin HTTP" kit out there, and the RTT delay spent on upgrading would prevent pure HTTP/2 implementations and delay when HTTP/2 performance benefits kicks in. -- 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 Wednesday, 20 November 2013 08:14:10 UTC