[AFS3-std] Re: rxgk ClientInfo and TokenInfo

[Benjamin Kaduk]

On Tue, 12 Feb 2013, Andrew Deason wrote:

> On Tue, 5 Feb 2013 11:05:56 -0500 (EST)
> Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
>> It seems that the ClientInfo structure contains all of the fields of
>> the TokenInfo structure (in the same order, even!).  I would like to

When implementing I noticed that lifetime, bytelife, and errorcode are 
unsigned in the TokenInfo, but signed in StartParams and ClientInfo.  (So 
the fields are not actually the same.)

I that we should make the signedness agree in all locations, with the 
lifetime and bytelife unsigned, but the errorcode signed.

>> make ClientInfo contain a TokenInfo instead of repeating all the
>> fields.  Both structures are in the rxgk document already.
>
> I'm not sure if the 'errorcode' in those is conceptually the same?
> TokenInfo.errorcode is an error for CombineTokens/AFSCombineTokens,
> where ClientInfo.errorcode is an error for GSSNegotiate.

It could be seen as different, I suppose.  It's still an error producing 
the token that the structure is supposed to describe, though.

> I don't know if that really matters; they both need a 32-bit error, and
> they both have a 32-bit error. But it seems odd to me to either
> duplicate the errorcode field, or have the GSSNegotiate error be in
> ClientInfo.tokeninfo.errorcode (but maybe that's just me?).
>
> You could treat errorcode as separate, and just have the rest of the
> clients moved into another structure, TokenOptions or TokenDetails or
> something. But if that doesn't seem necessary, just putting a TokenInfo
> in ClientInfo seems fine.

I don't think there would be benefit in such a tokendetails structure.
However, given that the implementation is just going to have a 
source-of-truth data structure for the proto-token, and copy information 
from that into the ClientInfo and Token structure, I no longer see a real 
need to collapse the data types.

-Ben