So, I'm looking at registration procedures for error codes for the
GSSEAP registry.

Our implementation uses a library called com_err to handle error codes
for GSSEAP.
This is commonly used in Kerberos implementations as well.

It has the kind of undesirable side effect that it splits error codes
into  255-entry tables.
If you use that library you can easily get into a situation where you
have difficulty dealing with errors greater than 255.  Kerberos made
things worse and actually got into a situation where two of the major
implementations have trouble with errors greater than 127. I recommend
we do not make that mistake.


I was thinking of addressing com_err concerns in the following way:

1) Add a note that implementations need to be able to deal with the
entire range of error codes.
In practice all this means is that you should design your APIs for
mapping from protocol errors to whatever errors your implementation uses
so that they will work if you're trying to map say more than 255 errors
that you might encounter.

2) Reserve the lower 127 values for standards action.

3) Say 128-255 specification required.

4) Reserve the rest of the range noting that future registration
policies may permit assignment from the greater range.


Thoughts?
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

Reply via email to