Re: Handling of Modify and NULLs By LDAP Servers

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

At 03:43 PM 10/6/99 +1300, Graeme Joyce wrote:
>We are using the Netscape Directory SDK 3.0 for C, and have found
>differences in the way that Netscape and OpenLDAP servers handle NULL
>values, and the modification of entries.

Note that NetscapeDS supports LDAPv3 and OpenLDAP 1.x is LDAPv2+.

In the context of LDAPv2, the behavior requirements offered by
RFC1777 are quite loose.  As such, there are significant differences
between LDAPv2 implementations.

RFC2251 clarifies a great deal of behavior when defining LDAPv3.
In many cases, this clarification may be applied to LDAPv2.
For sake of simplicity, we are updating our LDAPv2 implementation
based upon RFC2251 clarifications that do not conflict with RFC1777.
This is all part of our OpenLDAP 2.0 development efforts.

As this is the software list, my comments below are specific
to OpenLDAP 1.x.  Please direct any 2.0-devel enquires to our
devel list.

>1. According to the SDK documentation, a NULL value is interpreted in the
>following way by the ldap_modify_ext_s routine when using a mod_op value of
>LDAP_MOD_REPLACE:
>
>"If you set a NULL value for the attribute (either by setting the mod_values
>field to NULL, or by setting the mod_bvalues field to NULL when the mod_op
>field contains LDAP_MOD_BVALUES), the attribute will be removed from the
>entry."
>
>This works as documented on a Netscape server. However, an OpenLDAP server
>returns a "Protocol Error" in the same situation.

As RFC1777 (LDAPv2) doesn't specify the behavior in this case.
As such, it's implementation specific.

>2. If ldap_modify_ext_s is used with a mod_op value of LDAP_MOD_DELETE to
>delete a specific value from an attribute, a Netscape server will delete the
>actual attribute when its last value has been deleted; however, an OpenLDAP
>server retains the attribute even after its last value has been deleted. It
>is necessary to issue a further LDAP_MOD_DELETE, with a value of NULL, to
>delete the empty attribute from the server.

I believe this was fixed in OpenLDAP 1.2.5.

>3. If ldap_modify_ext_s is used with a mod_op value of LDAP_MOD_ADD to add
>an attribute that has a null value,
>the Netscape server stores a null string ("") as the value, and a subsequent
>call to ldap_get_values returns an array with a single value of "".
>
>In the same situation, an OpenLDAP server stores no value at all in the
>attribute, and a subsequent call to ldap_get_values returns NULL.

I'd have to dig on this one.  An attribute with no values is quite
different than an attribute with an empty value.  I'd have to examine
exactly what went over the wire (in both directions) and how the API
presented this to the application.

>Can anyone confirm whether the OpenLDAP server is behaving as intended?

The intent behavior of OpenLDAP 1.2 is to be compatible with
U-Mich LDAP 3.3 and other LDAPv2 servers.  Well designed clients
should interoperate with both LDAPv2 and LDAPv3 servers.  Given
the ambiguities of RFC1777, this might be challenging at times.