[AFS3-std] Re: rxgk-afs SetCallBackKey: one token or two?

[Benjamin Kaduk]

On Wed, 13 Feb 2013, Andrew Deason wrote:

> This kind of thing is why it sounds like the callback channel is a
> separate rxgk-using service to me (with its own tokens), which is not
> required for rxgk use pre-XCB. Which is why I have been suggesting it
> could really be a separate draft, and we wouldn't have to worry about it
> for now to get basic rxgk functionality through.

I don't think that SetCallBackKey is needed for any rxgk functionality 
prior to the introduction of extended callbacks, and I would support 
moving it to a separate document.  This discussion seems to be making 
clear that the existing text is incomplete and does not correspond to a 
complete understanding of extended callback operation.  (To be fair, the 
main deficiency is in the sentence "In rxgk's case this is an XDR encoded 
RXGK_Token structure" and the rest of it should not be very hard to fix 
up.)

In consideration of Jeff's comments, it seems that we would want to define 
a new XDR structure to hold an (opaque) token (i.e., a TokenContainer) and 
a key and maybe a TokenInfo to get the enctype.  I'd need to think more 
about exactly what key the encrypted part of the token would be encrypted 
in and how that key would be identified in the token container; I'd rather 
spend my time thinking about the core rxgk functionality right now.

-Ben