[AFS3-std] rxgk CombineTokens and enctypes

[Jeffrey Hutzelman]

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
> >
> >
> >   RXGK_CT_SUCCESS  The CombineTokens operation completed successfully.

This cannot be anything other than zero; I see no point in defining a
symbol for it.


> >   RXGK_CT_NOT_IMPL  The server will refuse all CombineTokens requests.

The code for this is RXGEN_OPCODE.


> >   RXGK_CT_EXPIRED  One or more of the input tokens was already expired.
> 
> This seems similar to BAD_{LEVEL,ENCTYPE}.

Does this need an error distinct from the one RXGK would normally return
for an expired token?


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.

-- Jeff