Saturday, 4 August 2012
HTTP in Vancouver
The HTTPBIS Working Group is in a transitional phase; we’re rapidly finishing our revision of the HTTP/1.1 specification and just getting steam up on our next target, HTTP/2.0.
So, we met in Vancouver this week as part of IETF84. Here’s a quick summary.
Five years ago, we held a Birds of a Feather meeting at IETF69, discussing whether we should attempt to revise RFC2616, the specification of HTTP/1.1.
It’s turned out to be a massive job, but we’re close to the end. One of the first things we did was to split the specification up into seven parts, and the last four (for conditional requests, partial content, caching and the authentication framework) have gone through Working Group Last Call and are basically ready to go.
The remaining parts (messaging and semantics) are almost there; after discussing things with the editors and the Working Group, we’re shooting to get them into WGLC by the end of the month. Depending on the issues encountered there, we should be in IETF Last Call before the end of the year (hopefully much sooner).
While we were constrained by our charter to avoid changing or adding to HTTP (i.e., it’s still HTTP/1.1), we did improve specification quality and interoperability quite substantially; over 375 issues have been raised, discussed, and dealt with, meaning that the HTTP specification is better suited for the Web’s continued use and evolution.
The upshot is that, with a bit more work and some process to go through, we should expect to see RFC2616 obsoleted by a new set of RFCs by early next year.
The other major item on the table was the Working Group’s newer focus on defining HTTP/2.0, a successor protocol to 1.1. We’ve been collecting proposals for consideration since our Paris meeting, and at this meeting, there was agreement in the room to use SPDY as the starting point for our discussion on HTTP/2.0.
It’s important to understand that SPDY isn’t being adopted as HTTP/2.0; rather, that it’s the starting point of our discussion, to avoid a laborious start from scratch. Likewise, we’re not replacing all of HTTP — the methods, status codes, and most of the headers you use today will be the same. Instead, we’re re-defining how it gets used “on the wire” so it’s more efficient, and so that it is more gentle to the Internet itself (see Jim Gettys — one of the original authors of HTTP/1.1 — discussing buffer bloat for more on this).
What’s next? First we need to take the discussion to the mailing list, centred around the proposed new charter. If we can get consensus around that, as well as approval by the IESG, we should start working soon.
What we won’t be doing, by the way, is working on new HTTP authentication schemes. Although people know this is important, most seem to agree that this working group isn’t the right place for it; instead, there’s talk about spooling up new work in the Security Area.
Overall, it was a very exhausting week, and while it might have been boring at times, we did make significant progress.