Design: Frame type extensibility issues

[James M Snell <[e-mail]>]

https://github.com/http2/http2-spec/issues/95

(btw, I'm posting these so that the issues are documented.. if there's
no time to discuss these issues now, or if it makes more sense to
discuss them later on in the process, that's obviously perfectly fine)

There are a couple of issues relating to frame type extensibility:

1. Are frames end-to-end or hop-by-hop? This is currently undefined.
Control frames appear to always be hop-by-hop, Header bearing frames
might or might not be hop-by-hop, Data frames appear to always be
end-to-end. What about new extension frame types?

2. Are new unsupported frame types subject to flow control? How can we
differentiate new control frame types vs. data frame types?

3. There is no prescribed mechanism for rolling out support for new
standard frame types vs. private use frame types.

Recommendation:

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.