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. 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 [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
