[edit] It's a bit ironic that this story was delivered to many of us (via Hacker News) over SPDY--HTTP/2.0's dominant source of inspiration.
Phk has had issues with the process for quite some time, and I feel that his embitterment about the process has jaded his view of the protocol. Phk on SPDY/HTTP/2.0 http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...
Which he has done: https://www.varnish-cache.org/docs/trunk/phk/http20.html
It's a pet peeve of mine when people just fling this sort of accusation about as if every word-count limited column isn't any good unless it's 20 times longer and basically includes half of Wikipedia transitively. It's a column in a trade magazine. There isn't a place for a detailed technical discussion there, so complaining that there isn't one is complaining about something that can't be fixed.
Besides, cards on the table, I think he's basically correct, cynicism and all here. Sometimes the right answer is to just say no, and failure to say no is not good thing when that is what is called for.
You are highlighting my point. The arguments made here are far more pragmatic.
My qualms are with how his points are made in the original blog post, not with what points he is making; many of which are quite valid.
With that said, the totality of his argument allows the perfect to be the enemy of the good. Which in my opinion is an invariably flawed position.
https://www.w3.org/Search/Mail/Public/search?hdr-1-name=from...
Results : 889
He's not just some guy who stirs up a bunch of outrage (and zero useful contribution) every year, regardless of what you may think of his arguments.
To me, that's the most fascinating, and entirely relevant (read: not self-serving or self-important) piece of what the author is talking about.
PHK wanted to do the sort of ground up work that would have taken ten years rather than 3.
Instead of spending 10 hypothetical years of their own time, doing the ground up work, they spent a small portion on HTTP/2.0. That portion is, in fact, smaller than the time spent on SPDY overall. So, how much standards-ing style work did they do? How much actual forethought was given besides making SPDY acceptable enough for a draft?
That's my takeaway.
The IETF mailing list archives are open if you'd like to see what 3 years of standardsing looks like. You can also go to the chair's blog (mnot.net) to read the evolution. Or Roy Fielding's presentations on Waka which were one of the early (2002) catalysts among the IETF-orbiters that lead to HTTP/2. http://gbiv.com/protocols/waka/200211_fielding_apachecon.ppt
Ultimately Waka was already a decade late, Google had SPDY which had some similarities and was already deployed, and people didn't want to wait another decade to build something no one might adopt. There were aspects of SPDY that needed changing to make it a true protocol standard rather than just a shared library, and a few features that out of rough consensus were changed.
That's how successful standards processes actually work - codifying what's already working, implemented in the field. Implementing a standard no one uses? See Atompub. See XHTML2.
SPDY was the only really viable option for the IETF to choose - it was running at scale and there was knowledge out there about deploying it and it's performance.
Although SPDY was the prototype, HTTP/2 isn't SPDY anymore it's evolved and moved on taking some of the concepts from SPDY and introducing it's own.
Given how long it took HTTP/1.1 to get ratified we suck at ten year standardisation processes.
If the IETF wanted a fresh look at HTTP, they would not have set such a short deadline for submissions.
It was evident from the start that this was about gold-plating & rubber-stamping SPDY, and people saw that and said so, already back then.
HTTP/2 isn't compatible with SPDY any more, but there is no significant difference between them, only a few deck-chairs were arranged differently in HTTP/2
The fact that people spend ages chewing the cud on a "clarification" of HTTP/1.1 has no impact on how long time it would take to define a HTTP/2 protocol.
Quite the contrary, HTTP/2 was a chance to jettison many of the horrors and mistakes that made the HTTP1.1bis effort so maddening.
You can see some of my thinking about what HTTP/2 should have been doing here:
That would be pushing HTTP/2 to irrelevancy the same way HTML5 (for good or for worse) pushed back on XHTML. Sad way to go but if need be ...
The really annoying thing about his rant is the number of assertions he makes without backing them up with data