[AFS3-std] Re: AFS-3 XDR discriminated union primitive type I-D

[Andrew Deason]

On Mon, 7 Mar 2011 22:28:39 -0500
Tom Keiser <tkeiser@sinenomine.net> wrote:

> > Also, to me, this says that an unknown tag has the same failure mode
> > as a known tag with a bad length. I thought a known tag with a bad
> > length was an instant decoding error of the entire payload, as it
> > represents a discrepancy in the .xg of the endpoints. But I suppose
> > the idea is that we should continue, since it's possible? My concern
> > is that with afs-union types where unknown tag errors are
> > effectively ignored, a problem in decoding known tags will go
> > unnoticed, even though a problem like that seems like it's always a
> > serious problem.
> 
> My intent was to leave the ultimate decision of how to handle a
> length/.xg mismatch up to the standards document describing the
> specific RPCs/types in question, as this maximizes flexibility in
> error handling.  My general concern is that proscriptive text limiting
> error handling behavior--to what we perceive to be correct
> behavior--represents an unwarranted loss of generality...  To counter
> your specific fear, I'll note that automatically failing to decode the
> entire XDR stream due to a single unexpected length seems overly
> harsh, and could potentially cause a complete breakdown of
> communications between two peers--when otherwise avoidable.  Perhaps
> we should have an explicit warning to the effect that implementations
> should properly distinguish between unknown tags and length mismatches
> for known tags during error handling?

Well, that's why these are recommendations, are not requirements. If we
just noted that implementations SHOULD NOT ever ignore arm length
mismatches, that may be fine. 

It's just, to me, "oops this ipv6 address is 5 octets long" seems like a
much more serious condition than "oops this is an ipv7 address and I
have no idea what ipv7 is". The former seems much more likely to be
indicative of some internal consistency error, and warrants bailing out
sooner.

-- 
Andrew Deason
adeason@sinenomine.net