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

[Graham B. <gb...@po...>]

On Mon, Jun 12, 2000 at 07:20:16AM -0700, Kurt D. Zeilenga wrote:
> 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).

I would suggest a hybrid. Have one value in the protocol error code
space that indicates a client API error. Information about the exact
error in the client API can be help elsewhere.


> >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?

That is the whole point. The API cannot know, only the user knows what codes
to expect. So unless local API codes and protocol codes can live in the
same space you are forcing the programmer to do two checks just to
determine if there was an error. IMO that is quite an overhead for error checking.

All I am suggesting is that one value in the protocol error codes be used
to indicate a local error. local error handling itself can have a different
space. That way there is only one place to initially check that there was an error.


> >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.

Hm, good point. Given that protocol error codes are non-negative.

Graham.