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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
