Re: Rechartering HTTPbis

In message <20120128074426.GF22945@1wt.eu>, Willy Tarreau writes:

>> Otherwise it will just be IPv4 vs. IPv6 all over again.
>
>IPv4 vs IPv6 is not a matter of spec size, but a matter of complexity to
>convert a lot of application code which used to stuff IPv4 addresses into
>integers and function return values (eg: inet_addr()).

Nope.

IPv4 vs. IPv6 *is* all about providing no tangible benefit that
warrants the effort to "sidegrade".

We fought hard to get some variant of "ISP-independent hosting"
into the spec, ("anycasting" were one such idea) so that customers
would not be locked into a single ISP, but could buy bandwidth
where it were cheapest.

That feature got killed by certain big ISP's who could see where
it led, and pretty much as a result of that, the only feature IPv6
ever had that could entice people to install it were gone.

Look around you:  The IPv4 shortage has not led to wide-spread
migration to IPv6, people still perceive the marketplace a much
more sensible solution than a new protocol.

>> If we start out at 29 pages, that means we'll end just shy of
>> 100 pages, which is a bit over the top, but livable.
>
>Transport and contents are two things different enough to be split.

Yes, absolutely, and I think we should go the full mile in HTTP/2.0
and make it a *transport only* protocol, that is what that second
'T' means and we should stick to it.

For all the content stuff we can just point back to HTTP/1.1(bis).

>> PS: Feel free to call me a grumpy old man.
>
>Come on, your uptime is far from wrapping. I'm sure there is even a
>fair number of participants with bit 6 set in this WG :-)

Not many of them wrote an OSI TP4 stack before they were 25 :-)

-- 
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 Saturday, 28 January 2012 08:13:59 UTC