Subject: Re: Extended operation errors

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 10 Aug 2000 13:52:25 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 8/9/00 5:46:58 PM >>>
>>The other has to do with extended operations that need to report error conditions that are not currently defined. For example, say there's an extended operation that starts the replication process, an error may need to be returned that states that the replication agreement is not defined correctly. In this case, none of the existing LDAP resultCodes can sufficiently communicate the problem.  I propose that each extension define its own error reporting mechanism (if appropriate), and we either create yet another result code called extendedOperationError, or just use other to signal that one should look at the results of the extended operation.
>> 
>>Any other ideas?
>
>I suggest the specification defining the extended operation define
>additional resultCodes as needed.

Are you suggesting that the new result codes be returned in the resultCode field of the LDAPResult, or that the extended response provide an alternate field to report them? The former method won't work with 2251 (4.1.10, "If a client receives a result code which is not listed above..."). We could easily fix this in the bis doc.

---

From: Mark Wahl <[email-masked]>
Date: Thu, 10 Aug 2000 15:19:56 -0500

An extension SHOULD NOT use the resultCode field as it is an INTEGER value:
to prevent collisions, each extension which wants to signal additional 
information back to the client beyond the overall operation status needs to
define a control or an extended response which it can return to the client.
A client which has issued an operation with a control would normally look in 
the operation response PDU to see if the extension has provided a response
control.

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance