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

On Mon, 9 Dec 2013, Chris Burdess wrote:

> 1. NPN/ALPN is not supported in many development frameworks. Especially Java 
> doesn't even have it on the roadmap for the next version, it's been reported 
> as an issue but is currently not even assigned. Python does have it but only 
> since 3.3. This will harm uptake since it will take a long time to even 
> start development and even when that's happened, many deployment 
> environments cannot be upgraded to the latest whizzy features.

This argument has been mentioned over and over again and it is doesn't get 
better even when repeated. Nobody is forced to use inferior software or 
products, nobody is preventing anyone from contributing to open source 
products.

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 don't believe in standards adapted for the lowest common denomimator. And I 
hate to even start thinking where that might be...

> The only solution for developers is to create their own entire TLS libraries

There's only like 8 or something quite capble existing open source TLS 
libraries already that will accept your contributions today. And another bunch 
of commercial ones you can probably pay to get things done for. But sure, you 
can also create yet another lib if that's your game.

> 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.

Yes there are challenges involved in relying on new TLS features. But if those 
features greatly help us, I think they should be properly explored and not 
dismissed only because not everyone has kept up with development.

-- 

  / daniel.haxx.se

Received on Monday, 9 December 2013 22:06:11 UTC