Subject: RE: strange uniqueMemberMatch

From: John McMeeking <[email-masked]>
Date: Fri, 10 Jan 2003 07:38:15 -0600

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

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 13 Jan 2003 10:29:52 +1100

John,

> distinguish between different instances (incarnations?) of a 

I would say different instances of the same DN rather than entry.
Whether the DN represents the same entity or not is an open question.

> id.
> Given that only one instance of cn=foo can exist at a 
> time, I don't

Only one entry with the name cn=foo can exist at a time but that doesn't
mean there aren't applications that need to be aware of the different
instances of use of the name cn=foo over time. Such applications may
want to store these names in the uniqueMember attribute, or another
attribute with the same syntax and equality matching rule.

Also, although X.500 expects DNs to uniquely identify entries,
in the real world it ain't necessarily so. The unique identifier can
be used to disambiguate concurrent uses of the same DN in different
servers, and in such cases it is reasonable to have multiple
occurrences of the same DN in the uniqueMember attribute.

> Unfortunately, that results in operation dependent matching behavior:

I would rather not have matching rules whose semantics vary depending
on the context in which they are used. It's messy to describe and
causes problems when LDAP extensions create new contexts of usage.

Regards,
Steven