[Date Prev][Date Next]
Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
Hallvard B Furuseth wrote:
> firstname.lastname@example.org writes:
>> email@example.com 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?
HEAD has been working this way for over a year, and it's clearly more correct
in its behavior now than it was before.
> 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.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/