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

Andrew Deason adeason@sinenomine.net
Mon, 7 Mar 2011 15:23:37 -0600


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.

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

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

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.

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.

-- 
Andrew Deason
adeason@sinenomine.net