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

[Tom Keiser]

On Mon, Mar 7, 2011 at 4:23 PM, Andrew Deason <adeason@sinenomine.net> wrot=
e:
> On Mon, 7 Mar 2011 15:46:22 -0500 (EST)
> Tom Keiser <tkeiser@sinenomine.net> 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. =A0The 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.=A0 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).=A0 In retrospect, it appears my text failed to
live up to that goal...


> Section 3.4
>
>>> 4. =A0However, if this is an unknown tag:
>>> =A0 =A01. =A0The 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