RE: Extensible Match Filters

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

Kurt,

I think the real problem Brent was alluding to is the fact that the ABNF
for <extensible> in RFC 2254 only allows the thing after the `=' to be
an AttributeValue, whereas it should be an AssertionValue. This means
that RFC 2254 does not cater for substring matching rules in an extensible
match. It's something for ldapbis to fix. Whether the asterisks should be
escaped depends on how one repairs RFC2254.

Regards,
Steven

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Thursday, 8 February 2001 12:54
> To: Brent Holland
> Cc: ietf-ldapext@netscape.com
> Subject: Re: Extensible Match Filters
> 
> 
> At 02:21 PM 2/5/01 -0800, Brent Holland wrote:
> >Is is possible for a LDAPV3 extensible match filter to 
> contain an assertion value with Substring Assertion syntax in 
> the form:
> >
> >    ldapsearch (attr:dn:1.2.3.4.5.6.7:=*foo*bar*)
> >
> >The RFC's seem to be in conflict on this type of value 
> production in the extensible filter:  reference section 4.5.1 
> of RFC 2251, section 4 of RFC 2254, and section 8.3 of RFC 2252.
> 
> The above filter is illegal.  If value contains '*', it must
> be escaped.  For example, to test for Kurt*Zeilenga in the
> common name:
>     (cn:dn:1.3.6.1.4.1.1466.115.121.1.58:=foo\2Abar)
> 
> Note that if you wanted to search the any substring "foo*bar"
> you'd have to do:
>     (cn:dn:1.3.6.1.4.1.1466.115.121.1.58:=\2Afoo\5C2Abar\2A)
> 
> Note the "*" in the substring must be escaped per
> RFC 2252, 8.2 / 4.3 when producing substring value "*foo\2Abar*"
> and then this escaped per RFC2254, 4.
> 
> Kurt
> 
>