[AFS3-std] rxgk CombineTokens and enctypes

Simon Wilkinson simon@sxw.org.uk
Wed, 2 Jan 2013 23:39:49 +0000


On 2 Jan 2013, at 22:17, Benjamin Kaduk wrote:

> Further discussion with Jeff convinced me that we should not try to =
standardize RPC-specific error codes, and instead use com_err tables for =
everything.  This makes us have RXGK-specific codes instead of =
RPC-specific codes, which is probably a good thing, and also lets =
application error codes come in naturally without a separate reserved =
block.  The com_err table is pretty easy to extend, so it doesn't have =
to be perfect or comprehensive right away.  Commits
> 3d56ed GSSNegotiate policy errors are com_err
> 7a9155e CombineTokens errors are com_err errors
> on https://github.com/kaduk/openafs/commits/prot make these changes =
for the language of the CombineTokens and GSSNegotiate RPCs, moving the =
list of error codes to an AFS-3 Registry Concerns section at the end.  =
Thanks to Simon for pulling up YFS's error table.

e3d56ed22fcbd08200033192b87ed04f6cb96e64 adds the reference to com_err =
codes, but doesn't add any reference explaining what com_err is - I =
think=20
we need something here - hopefully there's an easy reference we can =
steal?

7a9155e373320bfce4f3f1e87807fa11c7520b78 adds a number of error codes - =
I'd like to have a discussion in more detail about these, including the =
situations that they might be seen in the wild. I don't think the short =
descriptions provide enough detail for two implementations to be sure =
that they will use the same errors in the same situations.=20

Also, neither of these address Jeff's concern about why we're bothering =
with having an 'errorcode' field in ClientInfo, rather than using the RX =
abort code. If we're going to specify errors in detail, we need to =
provide guidance about when negotiation errors should be sent in an =
abort packet, and when sending them within ClientInfo makes sense.

Cheers,

Simon.