Hi Simon, This does make sense. It has been understood that extended callback invocations other than "cancel" must be restricted to a secure channel (when this security model is in force, Jeff Altman has mentioned another profile which might be used in restricted circumstances, I don't know if that is still under consideration). Since "cancel" is nothing more than BCB with another name, there is no benefit to using the extended callback interface, except potentially for implementation convenience.
Regards, Matt ----- "Simon Wilkinson" <[email protected]> wrote: > > Only RPCs which are authenticated with identities on this list would > be eligible for extended callbacks. RPCs with different client > identities, or which are issued over non-rxgk security classes, would > not receive extended callbacks. Where we have callbacks for the same > object requested by multiple different client identities, the key of > the most recent identity used would be used to encrypt the callback. > > Making all of this work complicates things significantly at the > client, which must now maintain an rxgk token signing service, so that > it can issue a proper token to the server for each key that it has in > play, such that it can then pull the key out of that token. > > Does that make sense? > > Cheers, > > Simon. > > _______________________________________________ > AFS3-standardization mailing list > [email protected] > http://lists.openafs.org/mailman/listinfo/afs3-standardization -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
