There are a couple of issues relating to frame type extensibility:
One approach we can take to dealing with this is to segment the 8-bit frame type namespace into two distinct categories and reserve a limited number of frame types from each for "private use". That is,
0xxxxxxx => Control Frames
1xxxxxxx => Data Frames
Control Frames (0x00-7F) are always hop-by-hop and are not subject to flow control. Frame types 0x6B-7F would be reserved for "private use", meaning that these types could not be registered within the IANA registry.
Data Frames (0x80-FF) are always end-to-end and are subject to flow control. Frame types 0xEB-FF would be reserved for "private use".
The frame type of the existing DATA frame would change from 0x00 to 0x80, all other existing frame types would remain unchanged.
This approach gives us a clear way of dealing with extension frames, flow control, etc without introducing undue complexity.
To be covered by the Layering TF.
We really need a text proposal that covers this issue. I suspect that the issues that needs to address include:
Discussed in Seattle; no decisions yet, but covered:
Updated proposal: http://www.ietf.org/internet-drafts/draft-snell-httpbis-ext-frames-01.txt
Another proposal from about the same time as James'; including for completeness of the comments thread when it's reviewed: http://www.ietf.org/internet-drafts/draft-bishop-http2-extension-frames-00.txt
Discussion on the mailing list showed there are some fundamental philosophical differences here, and they need to be resolved by the WG and not by us individually.
What are the goals for extensions? Are we trying to prevent protocol variants by making experimentation easy within HTTP/2.0, or prevent fragmentation by tightly regulating the creation of new extensions? Or are we just trying to close the spec ASAP by leaving extensions out entirely and saying that adding extensions creates a new protocol that we (or someone) will tackle later?
All are good goals, and we have a draft each for the three directions once we pick one.
Discussed in Zurich; we will do extensibility, maybe. Need some more time to look at the proposals.
Discussed (again) in Zurich; agreed to drop frame type extensibility completely (i.e., IANA registry), along with settings. Recipient of unknown frame types MUST conn error; recipient of unknown settings MUST conn error.
The WG discussed this extensively, and decided that ALPN identifiers were the primary mechanism for extensibility. Allowing extensions to change connection state was an issue of particular concern, and without those, the motivation for allowing extension frame types was much less. There was also a dearth of proposals for use cases.
Feel free to bring up on-list, of course.
Removing extensibility for frames and settings. Closes #95.
remove description of unsupported or unrecognized settings
Extension of settings was dropped in #95
Reopening after further discussion on-list.
Discussed in NYC; will take Martin's proposal with some tweaks (e.g., addressing flow control).