[AFS3-std] rxgk CombineTokens and enctypes

[Benjamin Kaduk]

On Wed, 2 Jan 2013, Simon Wilkinson wrote:

>
> 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 we need something here - hopefully there's an easy reference we 
> can steal?

If no one pops up with something, I can take a look.

> 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.

Sure.  I meant to add to my original mail a note that "some discussion on 
Jabber made us question a couple of the error codes listed there; we will 
probably remove COMPOUND_IDENTITY and PRINTED unless they get support 
here".

> 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.

I think I misplaced the mail with Jeff's concerns therein.  (Which 
probably explains some of my confusion on Jabber as well!)

As you said on Jabber, these are ones which are security sensitive.  But 
we should have some text to this effect, yes.

-Ben