[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapmodify/LDIF problem



I finally took the time to review this post (originally to -bugs):
http://www.openldap.org/lists/openldap-bugs/9907/msg00015.html
and my reply:
http://www.openldap.org/lists/openldap-bugs/9907/msg00016.html


At 03:45 PM 7/8/99 +0100, Martin Evans wrote:
>Hello all,
>
>We may have discovered a bug with the the interpretation of the
>changetype replace mode of the LDIF file format used by the ldapmodify
>command line tool. And would like some advice.
>
>The problem is illustrated by the with following LDIF:
>
>dn: cn=A Person, ou=my dept, o=The College, c=GB
>changetype: modify
>replace: mail
>-
>
>The book `LDAP - Programming Directory-Enabled Applications with
>Lightweight Directory Access Protocol' (Howes & Smith, MacMillan 
>1997) claims that if the "replace: mail" line is not followed by any
>attribute lines (e.g. mail: m.person@college.ac.uk). It is meant to
>delete any mail attribute in the directory entry and not generate an
>error if they do not exist. It does not do so - in fact it does not
>change the entry or generate an error.

That's LDAPv3 prescribed behavior.  RFC2251: LDAP/Modify/replace:
"A replace with no value will delete the entire attribute if it exists,
and is ignored if the attribute does not exist."

>Is the books interpretation of LDIF correct?

For LDAPv3, yes.  For LDAPv2, the behavior of a replace with no values
is not prescibed by RFC 1777.  As such, the current LDAPv2 behavior is
acceptable.

>Is there a current LDIF specification (RFC?) available
>(preferably on the web - for free).

There is a draft specification for LDIF authored by Gordon Good.
  http://search.ietf.org/internet-drafts/draft-good-ldap-ldif-04.txt.

However, the key here is LDAPv2 (RFC1777) vs LDAPv3 (RFC2251).  LDIF
changetype records have a one-to-one relationship with LDAP operations.

>I've modified a local version of the ldapmodify.c from the 1.2.3
>distribution to impliment this behavior as it is useful to our LDAP
>implimentation. However, the only  way I could prevent `Constraint
>voliation' errors being returned was to replace and delete a null the
>attribute from entry. e.g. When no replace: attribute lines have been
>read in I call
>
>              addmodifyop( &pmods, LDAP_MOD_REPLACE, value, NULL,0 );
>              addmodifyop( &pmods, LDAP_MOD_DELETE, value, NULL,0 );

This is not appropriate.  It violates the one-to-one relationship of
"changetype: replace" with LDAP/Modify/replace operation.

I committed a change to slapd (back-ldbm/bdb2) to implement the
LDAPv3/Modify/Replace behavior when no values are provided.

http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-ldbm/modify.c.diff?r1=1.31&r2=1.32


	Kurt