On 3 Nov 2012, at 19:28, Benjamin Kaduk wrote: > Do we want a way for the server to indicate a problem with the request?
Perhaps, especially given the problem with aborts. > 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. > That said, I don't think that the rxgk-afs printout I have handy reflects the > quoted text. This was a change that I made in light of implementation experience. I don't think the text I wrote to describe it made it into the draft document I sent through to you. I'll dig out the diff and send it on. Cheers, Simon. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
