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

[Tom Keiser]

On Tue, Mar 8, 2011 at 10:26 AM, Andrew Deason <adeason@sinenomine.net> wro=
te:
> 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. =A0My general concern is that proscriptive text limiting
>> error handling behavior--to what we perceive to be correct
>> behavior--represents an unwarranted loss of generality... =A0To 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. =A0Perhaps
>> 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.
>

Hi Andrew,

That's fair.  I'll add text to that effect.

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

While it's mooted by the above, I don't necessarily agree with this
argument: this is specific to your example.  We've already reached
consensus that "decode criticality" is to be deferred--it shall be
part of the semantic specification of each afs-union upper-layer type.
 Additionally, I can envision cases where an unknown-discriminant is
potentially more serious than a length mismatch for a known
discriminant (e.g., consider a case where a non-critical XCB
notification has a bad length, but a critical XCB notification
discriminant is unknown by the decoding peer).

Cheers,

-Tom