Re: Quoting Spaces in DN, again

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:02 AM 4/11/2003, Tony Earnshaw wrote:
>fre, 11.04.2003 kl. 17.19 skrev Kurt D. Zeilenga:
>
>> >The bug haunts me again. How do You explain the following search result?
>> >AFAIK the DN should simply not match...
>
>> No, they simply should match.
>
>> The directory strings " EMO" and "EMO" are equal per the
>> equality matching rule of the CN attribute.
>
>Openldap 2.1.17:
>
>Hmm ... grepping and stringsing around and cheating with GQ, I get
>rfc2256 shouted at me the whole time. Which I then obviously read
>($distro/doc/rfc).
>
>Nowhere, anywhere, can I find any equality match for 'cn' (actually
>built in to slapd via core.schema.)

RFC 2256:
    ( 2.5.4.3 NAME 'cn' SUP name )
    ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

So, CN's equality matching rule is caseIgnoreMatch.

>Checked the ldapsearch again, and 'cn=\20frigg' and 'cn=frigg' give the
>same (positive, accurate) results, 'cn=\ frigg' gives "ldapsearch:
>ldap_search_ext: Bad search filter (87)"

Because that's an invalid string representation of a filter.
See RFC 2254.  Marian and I were not talking about filter assertions
but about DN assertions.  See RFC 2253 for the string representation
of DNs and RDNs.

>So what is the equality matching rule for cn and where do I find it?

See above.

>SUP
>is name and has equality matching rule distinguishedNameMatch.

No. See above.