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.