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

Re: HTTP 2.0 mandatory security vs. Amateur Radio

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Sun, 17 Nov 2013 08:30:16 +0000
To: Amos Jeffries <squid3@treenet.co.nz>
cc: ietf-http-wg@w3.org
Message-ID: <55957.1384677016@critter.freebsd.dk>
In message <528829EB.2010403@treenet.co.nz>, Amos Jeffries writes:
>On 16/11/2013 9:06 a.m., Nicolas Mailhot wrote:
>> 
>> Le Ven 15 novembre 2013 18:31, Roberto Peon a écrit :
>> 
>> I'm not convinced at all using a new port is infeasible. Yes, it would be
>> devilishly hard for a new corner-case protocol. But the web as a whole is
>> something else entirely and a new way to access it won't be dismissed so
>> easily.

The same exact thing was said about IPv6, almost 20 years ago.

This argument only applies if you s/new/much improved/

In my not at all humble opinion, the current draft is nowhere near
that.  Ratifying the current fraft on port 100 would be pointless.

>Exactly the same arguments apply to staying with port-80 in the first
>place. There will be initial pain, but things will straighten out
>eventually.

The two thing which have started to worry me about staying on port
80 is:

A) HTTP/2.0 benefits will only materialize after a couple of RTT's
   because of the upgrade kabuki dance.

B) HTTP/1.1 infrastructure will be compromised while people iron the
   bugs out of their HTTP/2.0 code.


I'd say that our best shot is:

1) Make HTTP/2.0 simpler to implement than HTTP/1.0 (by eliminating
   and simplifying the semantics, and not adding new complexity.)

2) Make HTTP/2.0 faster than HTTP/1.0 (encoding + mux + pipeline +
   shaving cookies so all requests fit a packet)

3) Avoid time-wasting undecidable political issues (aka: encryption)

4) Define a new port *AND* an upgrade method.

5) Sit back and see if people like it.

-- 
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 Sunday, 17 November 2013 08:30:41 UTC

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