RE: strange uniqueMemberMatch

[John McMeeking <jmcmeek@us.ibm.com>]

Where are these archived?  I was going to look up Kurt's and Steven full
notes, but the archives I found at
http://www.openldap.org/lists/ietf-ldapbis/ was last updated Jan 3rd.  Or
the archive only updatede periodically?

I always thought that the purpose of the id in uniquemember was to
distinguish between different instances (incarnations?) of a given entry.
If cn=foo with id #'0'B is defined as a uniquemember, and cn=foo is
subsequently deleted and recreated, the new cn=foo will have a different
id.  Given that only one instance of cn=foo can exist at a time, I don't
think it makes sense to have to uniqueMember values in one entry where the
only difference is the id (either its value, or its presence/absence).

Unfortunately, that results in operation dependent matching behavior:
-  When adding values to an entry, uniqueMember values match if the dn
portion of the values match.
-  When deleting a value, hmm..., I guess I'd want the entire value to
match (both have matching ids or neither has an id)
-  For search/compare, follow Kurt's suggestion (what I remember of it)

For example, the following combinations of values would be illegal on an
add (i.e. duplicate values)

   cn=foo#'0'B
   cn=foo#'1'B

   cn=foo#'0'B
   cn=foo

But the first pair of values would not be considered equal in a search or
compare operation.


John McMeeking

>Steven Legg writes:
>>Kurt D. Zeilenga wrote:
>>> To resolve this, I think the ITU should change the
>>> uniqueMemberMatch semantics to:
>>> (...)
>> That's a reasonable way to make the matching rule commutative
>> however it does have the consequence that the uniqueMember
>> attribute cannot simultaneously hold the values cn=foo and
>> cn=foo#'0'B.
>
>That's better than what we have today:
>
>- If cn=foo already exists in an entry, cn=foo#'0'B cannot be
>  added because it tests out to be equal.  However, if cn=foo#'0'B
>  already exists, cn=foo _can_ be added.  Or maybe the server does
>  it the other way around, the standard allows that too.
>
>- Similarly, an add request which adds both values at once will
>  succeed or fail depending on which value is added first.
>
>>> Also, I think X.501 should be state that only single-valued
>>> attribute types can have non-commutative equality rules.
>>
>> That, or require all equality matching rules to be commutative.
>
>Commutative or take different types (the -firstComponentMatch rules).
>
>--
>Hallvard