Re: HTTP/2.0 draft, NPN/ALPN, and TLS

On 09/12/13 22:05, Daniel Stenberg wrote:
> ... Nobody is forced to use inferior software
> or products

In the real world, most people are forced to work with whatever they're
told to.

> Let's have rough consensus and running code guide us. If that means
> leaving some sub-groups behind for a while, then so be it. They'll adapt
> in one way or another.

I'm a fan of prototyping as much as anyone else, but that doesn't mean
you should ship the first prototype you make that works. The sub-groups
that you leave behind will create horrible hacks in order to adapt.
These horrible hacks will plague their communities and be exploited
ruthlessly by black hats. You can prevent that happening through design.

>> it [ipsec + ipv6] may well happen before there is widespread deployed
>> support for the current NPN/ALPN proposal.
> I would claim that browsers and others so far have shown that in the
> application layer things move MUCH faster than in lower layers when it
> comes to development and adaption on the wider internet. Compare SPDY vs
> SCTP. Compare TLS 1.2 support vs how ipsec or ipv6 are rolling out.

SPDY deployment is basically 100% Google. The only reason it has had the
traction it currently has is because Google controls both the server and
Chrome. Although Firefox now has some support there are basically no
non-Google SPDY servers outside of single organizations with specific
requirements like Facebook.

TLS/1.2 is not a huge success story either. The vast majority (>90%) of
TLS traffic uses TLS/1.0 because it "just works". Even SSLv3 has more
traction than TLS/1.1 or TLS/1.2. For instance:

Arguably even IPv6 rollout is going faster than that. And the thing is
that IPv6 is already there and has been for years at the endpoints. All
it really needs is for the carriers to pull the switch and connect them
up, which can happen a lot more quickly than developing and deploying
new application software.

Received on Tuesday, 10 December 2013 07:58:36 UTC