Re: Design: Ignored Unknown Frame Types and Intermediaries

On 13 May 2013 11:37, Roberto Peon <grmocg@gmail.com> 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.

> 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.

Received on Monday, 13 May 2013 21:14:06 UTC