On Sun, 31 Jul 2011 19:53:40 -0400 Tom Keiser <[email protected]> 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 [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
