RE: strange uniqueMemberMatch

["Volpers, Helmut" <helmut.volpers@siemens.com>]

Hello,

> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@adacel.com.au]
> Sent: Montag, 6. Januar 2003 05:36
> To: 'Hallvard B Furuseth'
> Cc: ietf-ldapbis@OpenLDAP.org
> Subject: RE: strange uniqueMemberMatch
> 
> 
> 
> Hallvard,
> 
> Hallvard B Furuseth wrote:
> > [Syntaxes] 5.2.21 (uniqueMemberMatch) says:
> > 
> >    The rule evaluates to TRUE if and only if the <distinguishedName>
> >    components of the assertion value and attribute value 
> > match according
> >    to the distinguishedNameMatch rule and the <BitString> 
> component is
> >    absent from the attribute value or matches the <BitString> 
> > component
> >    of the assertion value according to the bitStringMatch rule.
> > 
> > Thus, assertion value cn=foo#'0101'B matches attribute value cn=foo.
> > Is that intentional?

No , I think it doesn't match. cn=foo only match cn=foo without the unique
ID because

"and the uid component is absent" in the rule below.

cn=foo#'0101'B matches only cn=foo#'0101'B.

X520-6.2.11

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 the uid component is absent from the attribute value or matches
the corresponding component from the presented value according to the
bitStringMatch rule.

Helmut

> 
> Yes, because ...
> > X.520 paragraph 6.2.11 says the same thing.
> 
> 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.
> 
> Regards,
> Steven
>