Re: Design Issue: Must Ignore Rule for Unknown Frame Types

I think this is a good clarification.


On Thu, Apr 25, 2013 at 4:20 PM, James M Snell <jasnell@gmail.com> wrote:

> Ok, then if we go with MUST Ignore, we need to be explicit about
> requiring that unknown frame types cannot modify session / connection
> state. The most significant effect of this is that new frame types
> must not contain compressed header blocks that utilize the same shared
> compression state as known frames. That does not rule out the use of
> header compression in those frames, it just dictates that the state
> management for those occur at a higher level in the stack.
>
> On Thu, Apr 25, 2013 at 4:14 PM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> > If "MUST ignore", then it follows that "cannot modify session/connection
> state".
> >
> > I prefer "MUST ignore" because it allows for new frame types within a
> > standardized negotiated protocol without fatal errors.  If you want to
> > have new frame types modify session state, then you can negotiate a
> > new protocol (HTTP/2.infinity)".
> >
> > BTW, that's a standard response we came up with informally at the
> > Tokyo interim.  If someone wants to break the protocol, they are free
> > to break their own because negotiating new protocols is going to be
> > easy ... we hope.
> >
> > On 25 April 2013 15:58, James M Snell <jasnell@gmail.com> wrote:
> >> 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?)
> >>
>
>