[AFS3-std] rxgk CombineTokens and enctypes

[Benjamin Kaduk]

On Tue, 11 Dec 2012, Jeffrey Hutzelman wrote:

> On Tue, 2012-12-11 at 21:12 -0500, Benjamin Kaduk wrote:
>> Replying to myself with some comments, trawling for other input...
>>
>> On Wed, 28 Nov 2012, Benjamin Kaduk wrote:
>>
>>> On Tue, 27 Nov 2012, Simon Wilkinson wrote:
>>>
>>>> I haven't reviewed the series completely yet, but I wonder if initial error
>>>> list for CombineTokens is far too verbose. It isn't clear to me the
>>>> situation in which many of the suggested errors would occur, and I'm wary
>>>> of over specifying here.
>>>
>>> It's quite possible that the current list is too large.  I was essentially
>>> brainstorming when coming up with it, and some of the scenarios may be
>>> application-specific (and thus end up in the high half of the range).
>>> I consider the list quite flexible at the moment and welcome more input.
>>> I'll include the current list below for the mailing list to comment.
>>>
>>> -Ben
>>>
>>>
>
> I don't see that an "application-specific block" is needed.  Rx RPCs,
> including this one, either succeed (which the library represents as a
> return value of 0) or abort with a non-zero error code.  With the
> exception of errors emittted by the rx core, code generated by rxgen,
> and (for historical reasons only) the volume package, our errors come
> from com_err.  rxgk should concentrate on defining error codes that are
> relevant to the rxgk error or for which interoperability and reasonable
> code-sharing require that a code for an application-level failure not be
> application-specific.  For example, it would be appropriate to define an
> rxgk error code for a policy violation that application-independent code
> might reasonably handle in some specific way other than just passing the
> error upwards.  For application-specific policy issues, applications are
> free to define their own error tables, and have probably already done
> so.

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.

Separate mail about other updates on github coming soon.

-Ben