Slashdot Mirror
HTTP/2 - the IETF Is Phoning It In
An anonymous reader writes HTTP/2 is back in the spotlight again. After drawing significant ire over a proposal for officially sanctioned snooping, the IETF is drawing criticism for plowing ahead with its plans for HTTP/2 on an unrealistically short schedule and with an insufficiently clear charter. A few days ago the IETF announced Last Call for comments on the HTTP/2 protocol.
Poul-Henning Kamp writes, "Some will expect a major update to the world's most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve their privacy. Others will more cynically suspect the opposite. There may be a general assumption of 'faster.' Many will probably also assume it is 'greener.' And some of us are jaded enough to see the "2.0" and mutter 'Uh-oh, Second Systems Syndrome.' The cheat sheet answers are: no, no, probably not, maybe, no and yes."
"Given this rather mediocre grade-sheet, you may be wondering why HTTP/2.0 is even being considered as a standard in the first place. The Answer is Politics. Google came up with the SPDY protocol, and since they have their own browser, they could play around as they choose to, optimizing the protocol for their particular needs. SPDY was a very good prototype which showed clearly that there was potential for improvement in a new version of the HTTP protocol. Kudos to Google for that. But SPDY also started to smell a lot like a 'walled garden'."
"The IETF, obviously fearing irrelevance, hastily 'discovered' that the HTTP/1.1 protocol needed an update, and tasked a working group with preparing it on an unrealistically short schedule. This ruled out any basis for the new HTTP/2.0 other than the SPDY protocol. With only the most hideous of SPDY's warts removed, and all other attempts at improvement rejected as 'not in scope,' 'too late,' or 'no consensus,' the IETF can now claim relevance and victory by conceding practically every principle ever held dear in return for the privilege of rubber-stamping Google's initiative."
Poul-Henning Kamp writes, "Some will expect a major update to the world's most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve their privacy. Others will more cynically suspect the opposite. There may be a general assumption of 'faster.' Many will probably also assume it is 'greener.' And some of us are jaded enough to see the "2.0" and mutter 'Uh-oh, Second Systems Syndrome.' The cheat sheet answers are: no, no, probably not, maybe, no and yes."
"Given this rather mediocre grade-sheet, you may be wondering why HTTP/2.0 is even being considered as a standard in the first place. The Answer is Politics. Google came up with the SPDY protocol, and since they have their own browser, they could play around as they choose to, optimizing the protocol for their particular needs. SPDY was a very good prototype which showed clearly that there was potential for improvement in a new version of the HTTP protocol. Kudos to Google for that. But SPDY also started to smell a lot like a 'walled garden'."
"The IETF, obviously fearing irrelevance, hastily 'discovered' that the HTTP/1.1 protocol needed an update, and tasked a working group with preparing it on an unrealistically short schedule. This ruled out any basis for the new HTTP/2.0 other than the SPDY protocol. With only the most hideous of SPDY's warts removed, and all other attempts at improvement rejected as 'not in scope,' 'too late,' or 'no consensus,' the IETF can now claim relevance and victory by conceding practically every principle ever held dear in return for the privilege of rubber-stamping Google's initiative."
I think the submitter doesn't like Google.
First, 'SPDY was a very good prototype' followed by 'the most hideous of SPDY's warts removed' was summed up with 'the IETF can now claim relevance and victory by conceding practically every principle ever held dear in return for the privilege of rubber-stamping Google's initiative.'.
Adopting and modifying a demonstrably working improvement for a standard is no cause for ire. Besides, this is the IETF we're talking about, be glad this is a modicum of improvement and not as blatant as something like this. http://arstechnica.com/security/2013/12/critics-nsa-agent-co-chairing-key-crypto-standards-body-should-be-removed/
As a web guy, I still use primarily XHTML. I may call it HTML5 when I need to use an HTML5 tag, but for a true developer/designer who doesn't use a GUI, properly nesting tags is a must. And with HTML5 being so loose, most XHTML documents are also valid HTML5 documents.
Also - being able to load another web site's XML-compliant DOM to scrape data (for personal use)? Priceless.
The Tao of IETF still mentions:
"We reject kings, presidents and voting. We believe in rough consensus and running code"
http://www.ietf.org/tao.html
Maybe it's just me, but might it apply here ?
Before the httpbis working group started looking at proposals for HTTP/2.0 SPDY was already implemented and deployed in the field by mutliple browser vendors, library builders for servers and several large websites. A bunch of research documents was written. And a protocol specification document draft existed. SPDY wasn't created in the open perse, but it was iterated with the help the community.
So the IETF WG let people suggest proposals:
http://trac.tools.ietf.org/wg/...
And then they voted.
SPDY got selected.
Also the SPDY draft was used as a basis for writing the new HTTP/2.0 draft.
Is anyone surprised ?
There might fundamental parts of the protocol which might have turned out differently if they would have gone through a open collaborative process.
But at first glace it doesn't look that bad.
I can see the appeal of rubberstamping what already exists.
New things are always on the horizon
ways in which IPv6 sucks or sucked.
1: mechanisms for interoperability were bolted on later, not included as core features that every client and router should support and enable by default. The result is that relays for the transition mechanisms are in seriously short supply on the internet and often cause traffic to be routed significantly out of it's way.
2: the designers were massively anti-nat, as a result we don't have any interoperability mechanisms that go with the flow of NAT, instead we have two incompatible interoperability mechanisms one of which doesn't work with NAT at all and the other of which makes itself unnessaceraly fragile by fighting the NAT rather than going with it. The company behind the latter mechanism also disabled it by default for machines on "managed networks"*, presumablly because they were afraid of annoying corporate network admins.
3: there was lots of dicking around with trying to solve other problems at the same time rather than focusing on the core problem of address shortage. For example for a long time it was not possible to get IPv6 PI space because of pressure from people who wanted to reduce routing table size. Stateless autoconfiguation and the elimination of NAT seemed like good things at the time but they raised privacy issues and added considerable complexity to home/small buisness deployments.
4: there was little incentive to support it and so the time when you can use an IPv6 only system as a general internet client or server without resorting to transition mechanisms seems as far off as ever.
* Defined as any network with something windows thinks is a domain controller.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
The "problem" with HTML and browsers is that they have always worked with, and will always be expected to work with invalid code. Feed invalid code into a C compiler, a Java compiler, or XML interpreter, and if the syntax is incorrect, it will return an error and refuse to process anything. Browsers on the other hand are supposed to take invalid HTML and try to do something useful with it. If browser developers didn't have to spend so much time trying to make their code interpret invalid syntax, they could probably fix a lot of the other bugs that actually affect valid code.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Two remarkable things about HTTP/1.1.
One, it remained a relatively simple protocol. Yes there are a lot of nuances around content negotiation, transfer encodings and such but at its core it is a simple, flexible and effective protocol to use, and can be implemented quite efficiently via persistent connections and pipelining. It was designed for response caching as well, and the CDN infrastructure is in place to make use of caching whenever possible.
Two, despite the simplicity of HTTP/1.1, a shocking number of implementations get it wrong or don't use it efficiently. Pipelining is disabled in many implementations due to compatibility concerns, and few applications can use it effectively. Many applications make excessive and unnecessary use of POST requests which are inherently not cacheable and result in many synchronous requests performed over high-latency connections. (SOAP was notorious for that.)
I'm skeptical that any protocol revision can improve on HTTP/1.1 sufficiently without making it harder to implement correctly than it already is.
If there were a broad initiative to begin to use the features of HTTP/1.1 properly, as they were designed, most of the shortcomings would vanish without the need for a new protocol.
They just tools that write it for them after drawing it in Photoshop.
Should that be "they just use tools" or "they just are tools"?
Yes.
What PHK is not telling you is that he fought, successfully, against mandatory encryption in HTTP/2.
I'd argue that IPv6 is a variable availability problem, unlike Y2K. Y2K had a single cutoff date for everybody - 1/1/2000, as opposed to the various dates that the RIRs are running out of. Which is why Asia and Europe were already there, and ARIN just got there last year.
It is a good idea to start designing in IPv6 networks and introducing them in organizations now before running out of IPv4 addresses. That way, services can make use of IPv6 addresses, while the IPv4 addresses can be just transition addresses b/w IPv6 and IPv4 points.
Even NAT, or more precisely, NAPT, is now available for IPv6 if people must have it: it eliminates many:1 mapping which was the main issue w/ IPv4, but has all the other advantages that NAT does.