On Tue, Mar 8, 2011 at 10:26 AM, Andrew Deason <[email protected]> wrote: > On Mon, 7 Mar 2011 22:28:39 -0500 > Tom Keiser <[email protected]> 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. >
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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
