HTTP/2 reaching its Working Group Last Call – figuratively, not literally

With the publication of the fifth implementation draft, the technical requirements for HTTP/2 are being finalized and the Working Group Last Call (WGLC) process has figuratively started. I’m not one to confuse literally with figuratively. Let’s see how the IETF HTTPbis working group chair describes the current status:

… if I read the WG correctly, we don't have support to make such invasive changes at this stage …

Since the document has outstanding issues (that shouldn't affect the wire protocol greatly, but will change spec wording), I'm going to hold off making a WGLC until we've disposed of those issues. That said, please treat the protocol design itself as if it's in WGLC; we still aim to finish that process in September, as stated in NYC.

Recall that we held our first HTTP/2 interim meeting in Tokyo in late January 2013. This is amazing progress and reflects the commitment and discipline of the IETF HTTPbis working group. In the months after Tokyo, we’ve been meeting extensively to perform interoperability testing between our implementations and make hard decisions about the issues that are openly tracked on the HTTP/2 github repository.

HTTP/2 Interim in New York City

Speaking of which, I recently returned from a productive interim HTTP/2 meeting hosted at the Google offices in New York City where we closed on decisions for the current implementation draft. Gabriel Montenegro and Mike Bishop from Microsoft attended the interim meetings with me. Rob Trace, also from Microsoft, participated remotely.

Interim Meeting in NYC

The related meeting materials are available:

The entire meeting focused on closing the remaining issues and preparing for WGLC.


At the previous HTTP/2 Zurich interim meeting, we reached consensus that Frame Type Extensibility was not required because the core protocol was complete and stable. Perhaps we were simply too optimistic. Following the Zurich meeting, new frame types were added for optional features such as Alternate Services, BLOCKED, and Per-Frame Compression

There was a concern that the schedule would slip further if more optional or experimental features were proposed that required breaking changes to the “bits on the wire.” Mike Bishop from Microsoft shared an Extension Frames in HTTP/2 proposal on the HTTPbis mailing list prior to the NYC meeting. The proposal resonated with many participants since it reflected discussions from an earlier interim meeting hosted by Microsoft in Bellevue. The HTTP/2 editor, Martin Thomson, simplified and refined the proposal for discussion at the interim meeting.

After hours of intense debate at the interim meeting, a coin toss was proposed because all agreed that progress was more important than winning. Extensions won the coin toss and was adopted. Both Alternate Service and BLOCKED were removed from the core protocol and modeled as extensions. Per-Frame Compression was simply removed from the protocol.

Update on Application Layer Protocol Negotiation (ALPN)

The Internet Engineering Steering Group (IESG) approved Application Layer Protocol Negotiation (ALPN) as a Proposed Standard. The draft is currently in the RFC Editor’s Queue awaiting the Authors’ Final Review (AUTH48) – the final stage before publication.

ALPN support is planned for the OpenSSL 1.0.2 feature release. ALPN status for open source libraries and languages is tracked here. The Jetty server will also support ALPN “very shortly”.

Are we there yet? Almost.

As discussed at the NYC interim, the proposed schedule for completing HTTP/2 looks like this:

“Soon” - 9/1

Working Group Last Call – During this period, the protocol is not updated again unless a major flaw is discovered that must be addressed.


Start IETF Last Call


Address IETF Last Call issues at IETF 91 as necessary


IESG Telechat to review HTTP/2 as Proposed Standard


Address IESG comments and submit to RFC Editor


Publish HTTP/2 as RFC

Now is the time to commit to deploying an implementation and then sharing your experiences on the mailing list. We’ll continue to update you on the status of this important standard and Microsoft’s support.