Anatoliy,

The next big task, as I mentioned on mumble yesterday, for us to do on the OpenLDAP backend is to correctly test and implement the DN+String and DN+Binary matching rules.

Once we have positive tests for these rules, then we can ask the OpenLDAP team to implement them, but we want to make sure we ask once, for the right thing (I may have already muddied the waters here, so I want to try again once, with the right info).

The things we need to find out are:

If I search on a DN+String attribute, does it match against the DN, or the DN+String. Likewise for the DN+Binary.

If I attempt to add a duplicate DN+String value to an attribute, does it conflict (only unique values allowed in LDAP) based on the DN, or the DN +String. Likewise for DN+Binary.

Once we understand this (and have tests to prove it), we need to implement proper matching rules based on these, upgrading our comparison functions to proper comparisons (not just canonicalise and memcmp()).

Finally, we need to write the results of that research into a mail to Howard Chu and OpenLDAP tecnical, and see if they can help us by implementing this in their server, or if we should somehow deal with this client side. A particular difficulty is that we must have these values implement DN rules, such backlinks, changing on target rename and deleting when the target deletes etc, and a functional dereference control (or a replacement with extended DNs).

There may be additional funny rules like the fact that you will see duplicates in backlinks that have different source String parts of the DN+String values, but for the same DN.

I've CC'ed Howard, Pierangelo and openldap-technical to give them a heads-up about the fact that we are hoping to pick the ball up on this again, now some other matters have settled down.

Andrew Bartlett