[Date Prev][Date Next]
RE: strange uniqueMemberMatch
Volpers, Helmut wrote:
> > -----Original Message-----
> > From: Steven Legg [mailto:email@example.com]
> > 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
> > > 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.
The rule in X.520 says "absent from the attribute value". It makes
no statement about the presence or otherwise of the uid component
in the assertion value, so the attribute value cn=foo is matched by
both of the assertion values cn=foo#'0101'B and cn=foo. Conversely,
the assertion value cn=foo#'0101'B matches both of the attribute values
cn=foo and cn=foo#'0101'B.
> cn=foo#'0101'B matches only cn=foo#'0101'B.
> The rule returns TRUE if and only if the dn components of the
> value and the presented value match according to the
> 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.
> > 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