RE: strange uniqueMemberMatch

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

Kurt,

Kurt D. Zeilenga wrote:
> At 08:36 PM 1/5/2003, Steven Legg wrote:
> >The uniqueMemberMatch rule is an equality matching rule that is not
> >commutative, which causes problems in deciding whether 
> attribute values
> >are equal or not when adding or deleting values. I've raised 
> this with
> >the X.500 working group and I'm waiting to see how they resolve it.
> 
> We likely should nudge them on this.  The current
> definition is, I think, problematic because uniqueMember
> is not single-valued.
> 
> To resolve this, I think the ITU should change the
> uniqueMemberMatch semantics to:
>    The rule returns TRUE if and only if the dn components
>    of the attribute value and the presented value match
>    according to the distinguishedNameMatch rule and, if the
>    uid component is present in both values, the uid of the
>    attribute value matches the uid from the presented value
>    according to the bitStringMatch rule.
> 
> That is, 
>   Assertion Value       Attribute Value Result
>   cn=foo#'0'B           cn=foo#'0'B     True
>   cn=foo#'1'B           cn=foo#'0'B     False (uid mismatch)
>   cn=bar#'0'B           cn=foo#'0'B     False (dn mismatch)
>   cn=foo                cn=foo#'0'B     True
>   cn=bar                cn=foo#'0'B     False (dn mismatch)
>   cn=foo#'0'B           cn=foo          True
>   cn=foo                cn=foo          True
>   cn=bar                cn=foo          False (dn mismatch)

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.

If the rule is changed to return TRUE if the uid component is
absent in both the attribute value and assertion value, or present
and the same in both the attribute value and assertion value then
both cn=foo and cn=foo#'0'B can simultaneously appear in the
uniqueMember attribute.

The old semantics of uniqueMemberMatch (or else your suggestion) are
suitable to be recommended for approximate matching of the uniqueMember
attribute, so as to retain the flexibility of the current matching
rule in some form. 

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

Regards,
Steven