Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary

[h.b.furuseth@usit.uio.no]

Howard Chu writes:
> The outcome of the original discussion, which Kurt again reminded me
> of today, was that ldapmodify should quit its guessing games and just
> accept valid LDIF input.

All I see in the -devel discussion is about bugs in the parser.  I see
nothing about removing the default "add:"/"replace:" derived from
"changetype:", though perhaps it's in the off-list discussion it refers
to.

> The description of the exceptions in the manpage seemed imply they
> were there to accommodate slurpd users, who needed a mechanism for
> applying failed updates to a target server. Now that all slurpd/replog
> support has been dropped, there really is no more justification for
> these exceptions.

That's not my impression, nor my recollection of the -r option.
The manpage lists some differences from ldif format - replog, and
defaulting changetype, add/replace.  But they do not seem related.  Not
in the old code either; removing replog code can be done cleanly and
does not interfere with those defaults.

BTW I was wrong about when -r was removed.  Seems to have been in the
middle of the 2.0 branch; I only checked the beginning.  ldapmodify rev
1.97, May 2 2001 "Clean up some logic, based upon Novell patches".  I
see a small patch from Novell shortly before that, ITS#1075, about a bug
in the -r option.  The "patches" referred to means more I've missed, I
guess.

>> As far as I can tell Logschema doesn't support full LDIF modify though.
>> reqMod is unordered, so one cannot make two modifications to the same
>> attribute.  E.g. "delete: foo" followed by "replace: foo".
>
> I suppose reqMod should be made ordered. My point about logschema is that
> reqMod's syntax doesn't require separators/terminators or as many redundant
> attribute references.
>
> attr:- foo
> attr:+ bar
>
> is a far more efficient representation than
>
> delete: attr
> attr: foo
> -
> add: attr
> attr: bar
> -

Which is why I want the old 'replace:' default back...  With a doc
warning that one must use the verbose LDIF format if one wants to not
worry about attribute names like "increment" or "changetype".

> The logschema format is also easily grep-able without resorting to grep
> windowing and other such hassles.

And that was roughly the old ldapmodify format.  See manpage umich
ldap-3.3/doc/man/man1/ldapmodify.1.  I wonder why we removed it.

There are a few weird LDAP change requests that do not map to that
format, e.g.
  add: cn
  cn: foo
  -
  add: cn
  cn: bar
  -
but that could have been fixed simply by allowing a '-' line as in the
current format.

>> Maybe it's time to take this to the ldapext list and hear what others
>> do.
>
> This is really getting off topic, unless you're suggesting that we
> spec this for a new version of LDIF.

Not really, more the opposite - if we just relax some restrictions on
the old format ldapmodify accepted before, that's fine.

But otherwise, if we end up inventing a new way to parse ldifs rather
than just accepting more of what the code accepted before, I think it'd
be best to see what others do first.  And if so we might as well go
further.  I don't suggest that as part of resolving this ITS, certainly.

-- 
Regards,
Hallvard