There is a jurisdictional issue brewing over the future of internet standards – I know because I’m stirring the pot.  The dispute is between the WHATWG and the IETF regarding the specification process for the websocket protocol (which I have some concerns about, but none the less is supported by Jetty).

The IETF is the body that has been responsible for developing and/or standardizing the vast majority of protocols which run the internet: HTTP, FTP, SMTP, etc. It has an open collaborative based process based on working code and rough consensus and is overseen by the Internet Society, a non profit organization with membership open to all.

The WHATWG was formed in response to concerns about the W3C’s evolution of HTML
and has been instrumental in developing the HTML5 standards.  It is essentially a browser vendor consortium that is governed by an invitation only committee and lead by a Google employee.  While it’s process is conducted openly and all are invited to participate,  only the appointed editor has any power in the actual decision making process. The editor is appointed by the browser vendors.

The majority of the WHATWG efforts have been about HTML5, and most welcome the advances they are driving in the browsers. However, the websocket API and protocol have also come out of the HTML5 work and specify a new protocol that will run over ports 80/443, that will start off looking kind of like HTTP, but is expressly not HTTP.

Making the internet work well by producing quality standards is exactly the mission statement of the IETF.  So a new protocol running over port 80 is definitely something that falls within the scope of the the IETF mission.   The WHATWG were invited to submit their protocol as a IETF draft document, which they did and the IETF after due process has formed the hybi working group to ” take on prime responsibility for the specification of the WebSockets protocol”.   This appears to have shocked the WHATWG and they saying that they do not wish to relinquish editorial control of the protocol. It appears they were hoping for a rubber stamp from the IETF.

Meanwhile, Google’s Chrome browser has started shipping with the websocket protocol enabled and it is expected that other browser vendors in the WHATWG consortium will soon follow.  The argument has been made that it’s “already shipping”, so it’s too late to make any significant changes to the protocol.

The problem is that the protocol has been developed by only a fragment of the internet industry, and essentially by a single company within that fragment. There has been no consensus sought or obtained from the wider internet community – ie servers, routers, bridges, proxies, firewalls, caches, load balancers, aggregators, offloaders, ISPs, filters, corporate security policies, traffic monitoring, billing, accounting, shaping, application frameworks etc. etc.   These communities and vendors are waking up to a world where the traffic they expected over port 80/443 aint what it used to be. Their products and services will be broken, bypassed or at best co-opted for unintended usage.  They had no real voice in this change.  Many would not have even realized that the HTML5 effort was going to substantially change the wire protocol.

It is easy to present this state of affairs as a takeover of port 80 by Google so that they can get Wave to work better. That google  expect the rest of the industry to scramble to make the changes necessary to allow websockets to tunnel through the infrastructure unhindered by any concerns other than connectivity to Google.    I know that this characterization of the situation will be taken as personally insulting to the individuals involved, who I’m sure are acting in good faith and not as part of some conspiracy.  However, the power of group-think is significant and individuals are greatly affected by the environment that they operate in.  Conflicts of interest are avoided by not by peoples best intentions, but by not creating processes that are inherently conflicted.

I don’t mean to be too Machiavellian about this, but if the IETF does not assert is roll as the primary internet standards body, then the  outcome will essentially be that a Google led consortium has taken over port 80. Note that Google are also doing some great research on a HTTP replacement protocol called SPDY, which is showing some excellent promise. SPDY might be the way of the future, but do we really want it to arrive by having google simply start shipping it in Chrome?  If we let port 80 be taken by websockets without consensus, then could happen with HTTP as well (mwah ha ha ha)!

The websocket protocol as specified by the WHATWG might indeed be wonderful, but unless we follow due process, we will not really know that it is. The IETF has a truly open
process based on rough consensus in which all are welcome to participate. They have a proven track record and have overseen the standards that have withstood the unprecedented growth in the internet.  The IETF are the natural body to oversee standardization of internet protocols and there is no evidence that this task would be better handled by a closed industry consortium lead by Google.

My suggestion of how to break this impasse, is for the WHATWG to continue to be the editor of the current specification and to push forward with the deployment of 1.0, which essentially ignores intermediaries and proxies anyway.   In parallel, the IETF should continue with their working group to develop the 1.1 specification based on 1.0, but with an all-of-industry rough consensus.





Anne van Kesteren · 30/01/2010 at 19:12

Note that the protocol originally used port 81 and 815. It was changed on advice from IANA:

Ian Hickson · 31/01/2010 at 02:25

saying that they do not wish to relinquish editorial control of the protocol

That’s a fabrication; what I said is that the IETF and the WHATWG should cooperate.

Lars Vogel · 31/01/2010 at 09:31

Thank you for sharing this. I assumed that web sockets will just use the standard HTTP protocol and wasn’t aware of the changes.

uberVU - social comments · 31/01/2010 at 09:38

[Trackback] This post was mentioned on Twitter by jhannes: “It’s easy to present [web sockets] as takeover of port 80 by Google [to] get Wave to work better” @gregwilkins

Greg Wilkins · 31/01/2010 at 18:24

I think all agree that the IETF and the WHATWG should cooperate.
The issue is that the IETF WG’s charter says that it should take primary responsibility for producing the specification document. I took your recent responses to indicate that you did not agree with that as the WHATWG is still actively working on the protocol.
So if I have fabricated that sentiment, then the WHATWG is prepared to give the IETF the primary responsibility for editing the document?

Greg Wilkins · 31/01/2010 at 18:31

IANA had good reasons to suggest the usage of port 80/443, and I’ve actually got few objections to that happening. The upgrade mechanism is there in HTTP for a reason.
But the initial upgrade request should be a real HTTP request (not something that just looks like a HTTP request), and the entire internet community need to be involved in the process of developing the upgraded protocol – not just the browser vendors.

Ian Hickson · 31/01/2010 at 20:57

Neither the IETF nor the WHATWG should have “primary responsibility”, it should be a joint effort. That’s what cooperation is.
It’s worth noting also that the Web Socket protocol really wasn’t primarily designed by browser vendors. The original TCPConnection design was mostly my idea, but we threw most of that out and replaced it with a design from Michael Carter of Kaazing, a server-side developer, with input from Google (developers of the third largest Web server by active domains according to NetCraft), Squid, and many other server-side developers, including yourself.
The entire protocol is in fact designed to put amateur Web developers (the most common Web developers and those with the fewest resources) first.

Greg Wilkins · 31/01/2010 at 22:22

the IETF process does allow it to be a joint effort. The IETF relies on rough consensus, and obviously if the WHATWG and its members do not consent, the it would be very hard to present that even as a rough consensus. By contributing to the mailing lists as you have done, you are already part of the process and your voice already counts when the working group chairs have to make a determination of consensus. If you disagree with their calls, you have avenues of appeal.
The WHATWG process is that you are the sole editor, consensus is not required and there are no avenues of appeal.

Ian Hickson · 31/01/2010 at 23:08

Who makes the ultimate call in the IETF space, if, say, you and I can’t agree on something and are both adamant that we are right?

Greg Wilkins · 31/01/2010 at 23:37

the IETF process of rough consensus is described briefly here: and
in detail here
Basically the chair decides what is the consensus, without strictly taking a vote.
If it came down to a 50:50 split, then I believe the chair would not normally be justified making a call either way, and they would probably call upon additional experts to participate, or defer that particular decision.
If the chair does make a call on the consensus that is disputed, there are avenues of appeal (see 3.4).
The IETF process has dealt with many difficult technical differences.

Ian Hickson · 01/02/2010 at 00:48

That’s basically no different than the WHATWG process.

Greg Wilkins · 01/02/2010 at 13:01

Ian, now that’s a fabrication! Blind Freddie can see that the consensus view is that the http upgrade request/response should be legal http and not some binary look-a-like. You refuse to change and there is no appeal.
Similarly, I’ve seen zero support for your misguided belief that your algorithmic specification “sanely” captures error handling. No change, no appeal.
I could go on…

JE Bailey · 01/02/2010 at 13:40

The problem of course, is that they bothered to submit it to the IETF in the first place.

First, to point out, the IETF has no power what-so-ever. They are an internet standards body because that’s what they say they are. Additionally they have enough people as members who actually know what they are talking about that that usually the standards they come up with are pretty decent.

From a development perspective, it’s helpful since you can point and say “I’m basing my work on RFC blah blah blah” and you can usually be assured that the RFC has been well thought out. But they are a ton of protocols, processes, “standards” so to speak that are actively used out in the wild that has no RFC correlation. That never will, because no one can be bothered to go through the pain of submission. Because by submitting a proposal, you are essentially requesting a work group to review it.

Ian Hickson · 01/02/2010 at 16:19

So in the IETF, if the “consensus” was that it was ok to have a security bug in the spec, that’s what the “ultimate authority” would pick?
(In the WHATWG, the appeal is you convince the WHATWG members that I’m wrong and ask them to override me.)

Greg Wilkins · 01/02/2010 at 17:24

if you can’t get a consensus that it is a security bug, then the IETF will pick something that you might IYNSHO think is a security bug.

Conversely, I’ve argued that sentinel framing is a security vulnerability in websockets because it is susceptible to injection attacks (as is HTTP – but no reason to repeat mistakes), yet the WHATWG process goes with your opinion and ships anyway. Can you give me the emails of the WHATWG members so I can appeal your decision?

Ian Hickson · 01/02/2010 at 17:37

You just make your case on the list; if they agree with you, they’ll support you. If they don’t agree, or don’t care, then they won’t.

Greg Wilkins · 02/03/2010 at 00:47

this issue appears to have been resolved and all parties are now participating in the IETF process with apparent intent to produce and IETF standard.

Monica Keller · 02/04/2010 at 15:17

Sorry for my belated congratulations but this is excellent news. I have been reviewing in detail the open and result-driven process encouraged by the IETF and I am proposing for us to adopt it in the spec development community as well as recommending it to others as a good way to determine which specifications are worth contributing to.

Comments are closed.