[AFS3-std] rxgk: Version numbers in XDR structures

[Simon Wilkinson]

Hi,

I'm just updating the rxgk specification to match the implementation I =
have produced for OpenAFS. In doing so, I've run in to a few questions, =
that I'm going to raise here. I'll use a different email for each, in =
the hopes of keeping the threads manageable.

In the current spec, I have included a "version" field in the =
XDR-marshalled Challenge and Response structures - the idea of which was =
to provide an upgrade path to newer versions of rxgk. However, having =
this field within an XDR marshalled structure doesn't actually help =
provide an upgrade path. If the structure is different, then the XDR =
unmarshalling will fail. An implementation that wishes to take advantage =
of the version field needs to either "peek" into the XDR structure, or =
base its decision on the structures size (as rxkad does currently). So, =
this version field doesn't seem useful in its current form.

I'm intending on removing the version field entirely from the Response, =
and just specifying that a response must always match the version =
contained in the Challenge. This leaves the question of what to do with =
the Challenge version

There are a number of solutions that I can see here
  1/ Leave the version field, and expect implementations to peek into =
the first 32 bytes of the XDR structure
  2/ Move the version field out of the structure, and define a challenge =
as 4 octets of version information, followed by an XDR encoded structure
  3/ Remove the version field, and expect clients to use structure =
length to determine the version (which works as long as there are never =
variable length elements in the challenge)
  4/ Rewrite the challenge definition in terms of either the proposed =
new afs-union structure (which seems to me to break abstraction layers), =
or as a

     struct RXGK_ChallengeContainer {
       afs_int32 version;
       opaque    challenge;
     }

What are other peoples thoughts on this?

Cheers,

Simon.