On June 5th, around thirty people sat down around a huge table in a conference room on the 4th floor in the Google offices in New York City, with a heavy rain pouring down outside.
It was time for another IETF http2 interim meeting. The attendees were all participants in the HTTPbis work group and came from a wide variety of companies and countries. The major browser vendors were represented there, and so were operators and big service providers and some proxy people. Most of the people who have been speaking up on the mailing list over the last year or so, unfortunately with a couple of people notably absent. (And before anyone asks, yes we are a group where the majority is old males like me.)
Most people present knew many of the others already, which helped to create a friendly familiar spirit and we quickly got started on the Thursday morning working our way through the rather long lits of issues to deal with. When we had our previous interim meeting in London, I think most of us though we would’ve been further along today but recent development and discussions on the list had actually brought back a lot of issues we though we were already done with and we now reiterated a whole slew of subjects. We weren’t allowed to take photographs indoors so you won’t see any pictures of this opportunity from me here.
We did close many issues and I’ll just quickly mention some of the noteworthy ones here…
Extensions
We started out with the topic of “extensions”. Should we revert the decision from Zurich (where it was decided that we shouldn’t allow extensions in http2) or was the current state of the protocol the right one? The arguments for allowing extensions included that we’d keep getting requests for new things to add unless we have a way and that some of the recent stuff we’ve added really could’ve been done as extensions instead. An argument against it is that it makes things much simpler and reliable if we just document exactly what the protocol has and is, and removing “optional” behavior from the protocol has been one of the primary mantas along the design process.
The discussion went back and forth for a long time, and after almost three hours we had kind of a draw. Nobody was firmly against “the other” alternative but the two sides also seemed to have roughly the same amount of support. Then it was yet again time for the coin toss to guide us. Martin brought out an Australian coin and … the next protocol draft will allow extensions. Again. This also forces implementation to have to read and skip all unknown frames it receives compared to the existing situation where no unknown frames can ever occur.
BLOCKED as an extension
A rather given first candidate for an extension was the BLOCKED frame. At the time BLOCKED was added to the protocol it was explicitly added into the spec because we didn’t have extensions – and it is now being lifted out into one.
ALTSVC as an extension
What received slightly more resistance was the move to move out the ALTSVC frame as well. It was argued that the frame isn’t mandatory to support and therefore easily can be made into an extension.
Simplified padding
Another small change of the wire format since draft-12 was the removal of the high byte for padding to simplify. It reduces the amount you can pad a single frame but you can easily pad more using other means if you really have to, and there were numbers presented that said that 255 bytes were enough with HTTP 1.1 already so probably it will be enough for version 2 as well.
Schedule
There will be a new draft out really soon: draft -13. Martin, our editor of the spec, says he’ll be able to ship it in a week. That is intended to be the last draft, intended for implementation and it will then be expected to get deployed rather widely to allow us all in the industry to see how it works and be able to polish details or wordings that may still need it.
We had numerous vendors and HTTP stack implementers in the room and when we discussed schedule for when various products will be able to see daylight. If we all manage to stick to the plans. we may just have plenty of products and services that support http2 by the September/October time frame. If nothing major is found in this latest draft, we’re looking at RFC status not too far into 2015.
Meeting summary
I think we’re closing in for real now and I have good hopes for the protocol and our progress to a really wide scale deployment across the Internet. The HTTPbis group is an awesome crowd to work with and I had a great time. Our hosts took good care of us and made sure we didn’t lack any services or supplies. Extra thanks go to those of you who bought me dinners and to those who took me out to good beer places!
My http2 document
Yeah, it will now become somewhat out of date and my plan is to update it once the next draft ships. I’ll also do another http2 presentation already this week so I hope to also post an updated slide set soonish. Stay tuned!
Wireshark
My plan is to cooperate with the other Wireshark hackers and help making sure we have the next draft version supported in Wireshark really soon after its published.
curl and nghttp2
Most of the differences introduced are in the binary format so nghttp2 will need to be updated again – it is the library curl uses for the wire format of http2. The curl parts will need some adjustments, for example for Content-Encoding gzip that no longer is implicit but there should be little to do in the curl code for this draft bump.
What about that accusation that claimed that http2 was broken and had to be redone because of privacy issues? Was that discussed? I think his name was Poul Henning-Kemp that made the accusation.
Ok, I’ll stick out my neck a bit here.
PHK’s claims have been discussed a lot, both on the list and in meetings. (But were they really concerning privacy issues?) To me however, his stunts are mostly just drama and shouting from the sidelines (although I’m sure he does so out of a belief he is right) with no real attempts to actually help the process nor the protocol, while most people involved in the http2 work actually try to produce a protocol (spec) to deploy and run. I don’t think many us expected PHK to “bless” the protocol and I’m not sure anyone can make such a protocol except perhaps PHK himself.
It is very easy to just criticize, it is much harder to offer technical solutions and make something that everyone agree with and can ship.
The thing about extensions is that they are optional. The thing about optional parts of a spec is that not everyone will implement them. The thing about not everyone implementing them is that you can’t rely on them to be present. The thing about something not being reliable is that people tend not to use it.
What is the impact of this being true for Alt-Svc? Will it, for example, make optimistic upgrade to TLS less likely or less widespread? That would be sad.
@Gervase: I agree completely and I personally was against making ALTSVC an extension.
This frame and header mostly has support from Mozilla and Akamai though. The other browser vendors (both!) seem reluctant to do opportunistic encryption at least untill we (Firefox and friends) have shown that it works and that it does good to users.
So, I don’t think ALTSVC being an extension or not is what’s going to make it a hit or not. But if isn’t “taking off” at least it won’t clutter the main spec when made as an extension. The frame was also optional to support in draft-12 so most implementations were already just ignoring it.
@Ok, thanks for that explanation.