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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
