Re: resultCode vs API error code (Was: Testing successful bind)

[Kurt D. Z. <Ku...@Op...>]

At 11:04 AM 6/12/00 +0100, Graham Barr wrote:
>On Fri, Jun 09, 2000 at 07:15:36AM -0700, Kurt D. Zeilenga wrote:
>> At 11:35 PM 6/8/00 -0700, Paul Heinlein wrote:
>> >On Thu, 8 Jun 2000, Yann Ramin wrote:
>> >
>> >> I've noticed that no error code is returned when a bind operation uses
>> >> invalid credentials.  ?  How can I test if a bind was successful or
>> >> not?  This is my main LDAP authentication scheme :)
>> 
>> Return of a success resultCode.
>
>> For the upcoming C API specification, the authors and I
>> are discussing two approaches to resolve this issue.
>> 	1) have API routines return an API error code
>> 		and provide separately protocol results
>> 		(including resultCode)
>> 	2) using negative values codes to indicate
>> 		API error codes (because resultCodes must be
>> 		non-negative).
>> 
>> If I was designing a new API, I'd choose option 1.  With
>> the C API, some (not I) prefer option 2 because it is
>> less intrusive to older programs.  And some are
>> willing to assume that clients and servers will be
>> well behaved (despite operational experience to the
>> contrary).
>> 
>> It appears that net:::LDAP makes the same mistake.
>
>Maybe, but that is only because to some extent it was based on the C API.

Basing anything on RFC 1823 (Informational) C API (or latest IETF
C API drafts) is unwise.  It's error handling is known to be
inadequate and fundamentally flawed.  I've been working with the
IETF on a new C API specification.  We are currently discussing
how to redesign the API to provide appropriate error handling.

We've come done (I hope), to these basic conclusions:
	1) the application must be able to determine an API
	failure has occurred.
	2) the application must be able to distinguish an
	API failure from any and all possible protocol results.
	3) the application must be provided with unmodified
	protocol results.

Though we are still discussing the options, and they do vary,
I suspect we'll either a) completely separate API error handling
from protocol result handling or b) separate the code
space (negative API error codes).

>However, I think the current approach is close to what is wanted.

I understand that simplicity of interface is desirable.
However, overloading/masking protocol results is a dangerous
simplification.

>Having to check two places for an error is not optimal.

But, given extensions and control unknown to the API,
what result codes indicate a successful protocol operation?

>I had always planned to extend the current scheme to allow better local
>errors. But I intended to do this by using a single code from the protocol
>(LDAP_LOCAL_ERROR) and then have the Message object store extended information
>about the local error.

You might consider using the value -1 instead of LDAP_LOCAL_ERROR
for this purpose.  A server (incorrectly) could (and, IIRC, have)
returned the localError code.  The "liberal in what you accept,
strict in what you produce rule" suggests the API should be able
to handle this as any other unknown or unrecognized result code.
It's my view that APIs should pass result codes through to the
application as the API may not be aware of the extension (extended
op/control) in use which caused the unrecognized (or unknown) result
code to be produced in the first place.  Of course, applications
should treat any unrecognized result code as an unknown error.

Kurt