On Mon, Mar 7, 2011 at 4:23 PM, Andrew Deason <[email protected]> wrote: > On Mon, 7 Mar 2011 15:46:22 -0500 (EST) > Tom Keiser <[email protected]> wrote: > >> I've published a new I-D, based upon the on-list consensus from the >> other week, defining a new discriminated union primitive type. >> Feedback and comments are hereby invited... > > Front matter: > > I thought the agreed "Workgroup" and "Intended Status" for AFS-3 I-Ds > were "N/A" and "Informational", respectively. But I could be wrong. >
Hi Andrew, That is quite possible; is N/A permitted by the RFC editor? I thought I read somewhere that individual submissions were supposed to use either 'Network Working Group', or 'IETF' as the working group string... "Intended Status: BCP" is my mistake. I'll change to it to 'Informational' for -01. > Section 3.1: > >>> Each standards-track afs-union will have to define its own semantics >>> for handling unknown discriminants. > > I have trouble reading this sentence. I know what you mean; that each > RPC or whatever needs to define whether and how to fail on unknown > discriminants. But the phrase "standards-track afs-union" doesn't make a > lot of sense to me; I'm not sure if that's just some terminology I'm > unfamiliar with. I'd probably write it as something like this, but it's > just a suggestion: > > "The semantics for handling unknown discriminants is left up to each RPC > or structure definition that includes a field of type afs-union." > Sounds good. I'll incorporate that text. >>> The AFS-3 discriminated union is encoded on the wire as: a 4-octet >>> discriminant, followed by a 4-octet arm length, and finally the >>> variable-length implied arm. The arm length field shall count the >>> total octets present in the union encoding: 8 octets for the header, >>> plus the total length of the implied arm. > > This may just be me, but it seems odd to describe the encoding to some > extent here, and then only describe the rest of it in Section 3.3. I > would have expected this to be in 3.3, or at least provide a reference > to it or something. > Fair point. My original goal was to separate the descriptive text of the wire encoding octet stream (3.1) from the algorithmic description of a way/the recommended way of producing said encoding (3.3, and its decoding analogue 3.4). In retrospect, it appears my text failed to live up to that goal... > Section 3.4 > >>> 4. However, if this is an unknown tag: >>> 1. The union SHALL be marked as failed to decode. > > Some kind of note here about how this is then handled by the > protocol-specific semantics of unknown tags would be nice. > Ok. > 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? Cheers, -Tom _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
