Subject: SASL API: should sasl_errdetail be human readable or deprecated?

From: Chris Newman <[email-masked]>
Date: Tue, 08 Apr 2003 14:26:59 -0700

When I added the sasl_errdetail call to the SASL API, my intent was that it 
would provide human readable strings intended for IMAP NO and POP -ERR style 
text response messages, and suitable for display to end-users.

The current API spec is too imprecise about the purpose of that function:
  <http://www.ietf.org/internet-drafts/draft-newman-sasl-c-api-01.txt>

Given there is already a logging callback in the SASL API, I would argue that 
sasl_errdetail serves no purpose unless it is intended for end-user 
consumption.  However, the CMU implementation generates cryptic error strings 
which are not suitable for end-user consumption and which leak security 
sensitive information (like the distinction between user not found and bad 
password).

That leaves us a choice:

1. Clarify that sasl_errdetail is intended to return error strings suitable to 
be passed back over protocol and presented to an end-user.  This would require 
clarification to the spec and some changes to the CMU implementation.  I am 
willing to propose the code changes to CMU if there is consensus for this 
option.

2. Deprecate sasl_errdetail and sasl_seterror and rely on the numeric error 
codes as the only way to determine what text messages to pass back to the 
end-user.  Use the logging callback for all detailed error logging.

I propose option 1 as the correct choice.  My theory is that attempting to 
enumerate all errors which require different behaviors on the client side is a 
tractable problem, but attempting to enumerate all errors which are useful to 
inform the user is not a tractable problem and thus a text string to pass back 
to the user is important.

If there are no objections, I will propose changes to the API spec to Alexey 
and changes to the CMU implementation to Rob.

                - Chris