Re: Extended Request Response Behavior

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:26 PM 1/30/2004, Siva Kollipara wrote:
>Hi Kurt,
> I was trying to use PasswordModify Extended Operation through OpenLDAP
>API, WinLDAP API and OpenVMS LDAP API. slapd doesnt return the ResponseOID
>for any extended operation - this isnt a problem for openldap clients, but
>is certainly a problem for WinLDAP and OpenVMS ldap clients.

Note that many extended operations have no response OID, or it
is optional (even if the specification which defines it calls
it mandatory).  This because a server cannot be expected to
know how to respond to request which it does not implement.
Even where it implements the operation, it may always be able
to return a particular response OID (this due to allowed freedom
in server-side error handling).  That is, client MUST NOT expect
response OID to be returned.  This will be clarified when the
LDAP technical specification, currently only a Proposed Standard,
is revised.  Note as a Proposed Standard, it is considered to be
an immature specification (see RFC 2026).

The Password Modify operation, as defined in RFC 3062, does define
a response OID and specifically says:
   A Password Modify response is an ExtendedResponse where the
   responseName field is absent and ....


>Current Response frmo slapd:
>ldap_write: want=14, written=14
>  0000:  30 0c 02 01 04 78 07 0a  01 00 04 00 04 00         0....x........
>
>OpenVMS client output:
>%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
>address=000000000000
>0000, PC=FFFFFFFF8098C8E8, PS=0000001B

I suggest you report this error to the developer of the client
(or client library).

>WinLDAP client output:
>        1 - Operations Error

I suggest you report this error to the developer of the client
(or client library).

>So, I modified extended.c to return the OID and thus allow winLDAP and
>openVMS clients work for the moment.

But in doing so you have broken slapd(8).


>Modified Response from slapd:
>ldap_write: want=39, written=39
>  0000:  30 25 02 01 04 78 20 0a  01 00 04 00 04 00 8a 17   0%...x .........
>  0010:  31 2e 33 2e 36 2e 31 2e  34 2e 31 2e 34 32 30 33   1.3.6.1.4.1.4203
>  0020:  2e 31 2e 31 31 2e 31                               .1.11.1

That is bogus.  That OID identifies the request, not the response.
The response has no OID.  See RFC 3062.

>this makes all the clients happy.

It may make the few clients you tested happy.... but it won't make
all clients happy.  I know of clients which expect the response
name, if provided, to be the right OID.  There is no "right"
OID for password modify response, hence, those clients will choke.

Also, note, it seems that these clients do seem to care what the
response OID is, just that there be one.  If so, that's quite
bogus as one should not mandate that an OPTIONAL field always be
present.

>Question 1:
> I remember you telling me that RFC 3062 was under revision and this
>requirement of sending repsonseOID back is under consideration - So does
>this mean that the revision would remove this requirement ?

I think I said RFC 2830 is under revision.  I have (as the author
of RFC 3062) no current plans on updating RFC 3062.

>Question 2:
> Can we have a configuration flag that allows us to follow 3062 verbatim ?

The current code behaves consistently with RFC 3062.

Kurt