RE: strange uniqueMemberMatch

["Steven Legg" <steven.legg@adacel.com.au>]

John,

John McMeeking wrote:
> I always thought that the purpose of the id in uniquemember was to
> distinguish between different instances (incarnations?) of a 
> given entry.

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.

> 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).

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

> -  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
> 
>