Re: Design: Ignored Unknown Frame Types and Intermediaries

I believe that, if one does remove/ignore such frames the session may not
be as optimal as it might otherwise be, but the rule, by definition,
precludes the use of anything which would hinder interop if emitted, but
then ignored by the receiver.
The rule is that one MUST NOT send a frame if its removal would cause
session corruption/termination/problems.
So, can you provide an example? :)


I think the version string is the most robust way to ensure that an
intermediary does the right thing-- If an intermediary sees a version
string it doesn't recognize, it simply doesn't allow the negotiation of
that variant.
This is more simple because the lack of an explicit negotiation for this
will lead to either:
1) implementations which ignore the spec, since their mission is to provide
security and consistency
2) Clients, servers, and proxies all maintaining a heuristic and
table/history about when and why sessions were terminated when a not
standardized opcode was
 I don't want to have to have maintain a table of endpoints which have sent
me some error-code or terminated my session because I included an unknown
opcode type (that would be pretty complicated). This would have to be done
for both sides, for that matter.

I'd prefer to say that an intermediary MUST NOT touch things in the session
which it does not recognize if it doesn't know the version, but allowed the
version to be negotiated, and it MAY remove things it doesn't know from a
session when the version is one which is fully specified.

That allows the intermediary to simply not negotiate things it doesn't like
on a per-connection basis, instead of having to have this complex cache of
'this feature doesn't work when X,Y,Z'.

James has pointed out that a reverse proxy may still have some difficulties
with this, assuming it wishes to support an unknown extention, but, I think
that trade (no longer requiring clients and servers to have to worry about
this, while having the proxy continue to worry about it) is reasonable.

-=R



On Mon, May 13, 2013 at 2:13 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

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