I was puzzled because the structure of the spec read like nothing I’d ever encountered; in particular nothing I’d ever seen in the IETF, where the work was sort of being done. I went so far as doing a strawman alternate draft in a more conventional style, as an exercise in comparison.
Subsequently, I got involved slightly in the IETF working group, and found that the process was as strange as the spec it was producing; an attempt to embed the idiosyncratic WHATWG process in the IETF context; which is at least as idiosyncratic, but well-worked out and has produced some pretty good results, for example the Internet.
It was obvious that there was a pretty complete disconnect between the two worlds; both in the ways that issues were addressed, and in the goals. I have never understood why the WHATWG has tried to embed parts of its work in other organizations like W3C or the IETF; and after observing this episode, I still don’t.
I’m not going to revisit the bizarre turns the conversation took; but today I ran across a long-buried browser tab containing the announcement of RFC6455, the WebSockets protocol, as a finished IETF work product. It’s in the traditional IETF style and was built in the traditional way. So long strange stories sometimes if not always have ends.
I should note that to this day, there are some who are extremely skeptical of the benefits, indeed the architectural soundness, of WebSockets, seeing it as another attempt to use Port 80 to route around all those annoying security restrictions that get in people’s way.
I don’t know, myself; I haven’t worked on any apps in recent years that needed this sort of persistent-binary-connection architecture. I have noted a buzz of conversation in the last few days around BrowserQuest, a Mozilla.org offering based on lots of HTML5 gooey goodness notably including WebSockets. So maybe they really are a big deal.