Hallvard B Furuseth wrote:

hyc@symas.com writes:

...

daveh@coreng.com.au wrote:

...

As a followup, I should point out that this behaviour worked in at least 2.2 and 2.3.

Yes, I recall changing this in the 2.4 code; I guess I didn't update the manpage.

Not sure which of this discussion should go where - I saw it first in the ldap@umich list. But anyway, I suggest to revert that change.

Hm... Where were you when we were originally discussing these changes?

http://www.openldap.org/lists/openldap-devel/200611/msg00013.html http://www.openldap.org/lists/openldap-devel/200611/msg00022.html

HEAD has been working this way for over a year, and it's clearly more correct in its behavior now than it was before.

If anything, the LDIF RFC could be revised instead. This format has been supported since umich ldap (before the LDIF RFC was written).

That doesn't mean it has any relevance today; there's plenty of stuff UMich did that was long since deprecated.

Note that the format which OpenLDAP-2.4 ldapmodify reads is still not LDIF, since "changetype:" defaults to modify instead of add. That's incompatible with LDIF. OTOH default operation "replace:" for changetype "modify" was compatible with LDIF, since LDIF does not support a missing "add/delete/replace:" for changetype modify.

Some history:

• umich ldap-3.3 (1996): There were two LDIF defaults: Whether a missing "changetype:" would default to "add" or "modify", and whether a missing attribute operation type would default to "add" or "replace". These were controlled by different flags: -a (or invoking as ldapadd) for the first, -r (replace) for the second.

• RFC 2849 - LDIF (2000): The defaults "changetype:modify" and "replace:" were dropped, presumably because a file format could not support command line options.

• OpenLDAP 2.1 (2002): Removed the -r option and instead made it the default when changetype was modify (and thus for ldapmodify). -r was only used with ldapmodify and was usually what one wanted there. (Note that "replace:" is equivalent to "add:" if the attribute does not already exist in the entry.)

It may be OK to revert this single aspect of the change. If you do so, just make sure that those other corner cases mentioned in the -devel thread are still handled correctly.