Re: Design: Ignored Unknown Frame Types and Intermediaries

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

On Mon, May 13, 2013 at 2:13 PM, Martin Thomson
<[e-mail]> wrote:
> On 13 May 2013 11:37, Roberto Peon <[e-mail]> wrote:
>> James:
>> Can you construct a case where, if you follow the rule spelled out in my
>> earlier email, you fail to achieve interop (because I can't)?
>
> It's trivially possible to construct a scenario where this happens,
> but only if you don't write down a "MUST ignore" rule.  Once the rule
> is in place, then you are constraining future extensibility.  A "MUST
> ignore" rule is the easiest rule to get right, but there are other
> models you can use.
>
>> The rule is, essentially:
>> If a party to the communication ignores (or removes) something it don't
>> understand, that must not screw up the session.
>
> The ignore/remove distinction is very important.  You can't
> selectively remove; it's all or nothing.  Either remove everything you
> don't know about or leave it all in.
>
> This consideration, along with James' hop-by-hop question does suggest
> a relatively simple way out:
>
> All unsupported/unknown frames that have a non-zero stream identifier
> MUST be ignored.  If a stream is forwarded by an intermediary, all
> unsupported/unknown frames MUST either be forwarded or removed; an
> intermediary MUST NOT selectively forward unsupported frame types.
> Unsupported/unknown frames with a zero stream identifier MUST be
> ignored and MUST NOT be forwarded.
>

I would go one step further and say that if an intermediary does not
wish to forward an unknown frame, it MUST NOT forward ANY additional
frames and ought to respond with an RST_STREAM. Removing only some
frames from the stream could cause significant data corruption or data
loss, especially if you don't know why those frames are there.

>> That implies that, when you add anything that must be interpreted, it then
>> must be declared in the version string (i.e. new version) and thus agreed
>> upon by both parties up front, and if you don't negotiate that other
>> version, you don't get to add frames whose removal would screw up the
>> session.
>
> Yeah, we addressed that early on.  If you want to guarantee that the
> other guy is going to support something, either work out how to agree
> in-session (with those ignored frames) or negotiate a new protocol.

Agreeing without prior coordination (must ignore or reject the stream)
is, in my opinion, the best approach for long term evolution and
growth. The "come up with a new version string" reminds me far too
much of things like XML namespaces. It's one of those things that
sounds like it ought to work in theory but when it gets down to real
world implementation, it ends up being a bigger mess than anticipated.

- James