On Sat, 3 Nov 2012 15:28:25 -0400 (EDT) Benjamin Kaduk <[email protected]> wrote:
> On Sat, 3 Nov 2012, Simon Wilkinson wrote: > > >>> 1) Whichever one the server picks from the client-provided list. [...] > I think this is the least bad way to get to a fully/usefully specified > CombineTokens operation. (That is, I think we should do it.) I don't have much to say here, but I would like to +1 this. On Sat, 3 Nov 2012 19:48:17 +0000 Simon Wilkinson <[email protected]> wrote: > > A zero-length new_token would indicate failure, but there might be > > some sense in reusing the RXGK_ClientInfo errorcodes here. > > In AFSCombineTokens, a zero length new_token has a specific meaning - > it means "the target endpoint doesn't support rxgk, so you can safely > fallback to rxkad". I don't think fallback is necessarily what you > want if there is an error in the negotiation, so I would agree that we > should include an error code here. Of course, this reopens the can of > worms of assigning meaning to these error codes. Well, keep in mind we don't have to cover all possible errors at first; we can always add more later. It's easy enough to divide the 'errorcode' field into standard and application-specific regions (e.g. 0-0x7FFFFFFF, 0x80000000-0xFFFFFFFF) if we want to use 'errorcode' for both. Or just have two separate fields (application-specific vs not); either way sounds fine. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
