Design Issue: Must Ignore Rule for Unknown Frame Types

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

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

In the current draft (-02) we say, "Implementations MUST ignore
unsupported and unrecognized frame types." but we give no guidance
that I can find about handling unknown frames that potentially modify
session state. For example, suppose some extension comes up with a new
frame type that includes a compressed header block. The receiving
endpoint will have no way of interpreting the content, but if it
ignores the frame entirely, it's stored session state can unknowingly
fall out of sync with the sender.

Recommendation: rather than a "MUST IGNORE" rule here, unknown and
unrecognized frame types ought to be a Session Error because the
receiver cannot determine whether and how those frames may have
changed the session state on the sending side. It would not be safe
for the receiver to continue attempting to communicate with the sender
on that session.

This obviously has an impact on the extensibility of the framing
layer. In short, a sender would not be able to use a new frame type
unless it knows the receiver can interpret it. The only solution for
that would be to have some kind of negotiation occur where the sender
effectively ask the recipient if particular extensions are supported
(as part of the session header perhaps?)