Re: The TLS hammer and resource integrity

In message <CAP+FsNeB8d0i=8ZCkhWZygYw7wUcfGtHRqoiJw1EWENZy_YnUg@mail.gmail.com>
, Roberto Peon writes:

>I'm not sure that SPDY with its one SSL today is more expensive than
>today's HTTP with its 6 to 40-something connections per page.

You seem to miss the point:

There are at least four relevant protocols to discuss:

1. HTTP/1.1 as we know and hate it.

2. SPDY

3. A newly design HTTP/2.0 fast-bulk-transport.

4. The idea much better than 1, 2, & 3 nobody has thought about yet.

You talk as if there is only 1 & 2, ignoring #4 is particularly
shortsighted.

But lets stop beating about the bush:

SPDY is designed for Googles needs, and it probably serves Google well,
in particular by imposing end-to-end-TLS to keep telcos out of googls
data and giving end-to-end user identification.

But not everybody are Google, and just because Google hacked together
SPDY does not mean that it should be rammed through IETF the way
Microsoft managed to ram OOXML through ISO.

Right now we have two complementary HTTP protocols, and I think that
works because they are exactly that:  Complementary.  One offers
cryptographic services, the other offers speed.

I have *REPEATEDLY* tried to inject into the HTTP/2.0 discussion that
what we need are pluggable transport protocols, because the same
complementary needs exist and exactly to be future compatible.

HTTP/2.0 should be standardized as the semantics of the transported
messages, and the protocols which transport the messages.

Amongst these protocols should be one supporting crypto-services
and high-feature-levels, for the money-bearing transactions on
the web.  SPDY would fill that niche well I think.

But there also needs another to showel pink bits across the net
as fast as possible, with as little latency and overhead as possible,
so the big spikes are possible to serve. (Think CNN on 9/11!)

All I am really asking is that SPDY becomes *a* HTTP/2.0 transport,
rather than become *the* HTTP/2.0 transport.

-- 
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, 28 March 2012 18:22:34 UTC