[AFS3-std] Re: XDR extensible union type

[Andrew Deason]

On Sun, 31 Jul 2011 19:53:40 -0400
Tom Keiser <tkeiser@sinenomine.net> wrote:

> I pushed draft-keiser-afs3-xdr-union-03 (incorporating Derrick's
> grammatical corrections) to the IETF last week.  Comments are hereby
> solicited.
> 
> http://tools.ietf.org/html/draft-keiser-afs3-xdr-union-03

On re-reading this, I'm not sure I agree with the suggested algorithms
in sections 3.3 and 3.4. Both of them suggest encoding/decoding the leg
to/from an opaque blob, and encoding the opaque blob as a separate step
as according to XDR. Doesn't it make more sense to just encode/decode on
the fly as normal XDR encoding/decoding, without needing to keep the
entire blob in memory? This is an implementation detail, though, so I
don't think this much matters.

However, I find this part in 3.4. to be odd:

>>   3.  If this is a known discriminant:
>>
>>      1.  Look up the discriminant, and compare the expected length
>>          with the length of the previously-decoded XDR variable-length
>>          opaque;
>>
>>      2.  If the expected and actual lengths match:
>>
>>          1.  The implied leg's payload should be XDR decoded
>>              (according to the type definition of the type specified
>>              for this discriminant value in the ext-union definition);

The leg may not be (and I would think will usually not be for our
purposes) a constant size. If there is a variable-length array in the
leg or other variable-size structure (like an extended union), you don't
know the length until after the decoding has been performed. So it seems
like you'd need to decode first, and check the lengths afterwards.

-- 
Andrew Deason
adeason@sinenomine.net