Subject: RE: Extensible Match Filters

From: "Steven Legg" <[email-masked]>
Date: Thu, 8 Feb 2001 15:07:24 +1100

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:[email-masked]]
> Sent: Thursday, 8 February 2001 12:54
> To: Brent Holland
> Cc: [email-masked]
> 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
> 
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 07 Feb 2001 20:54:27 -0800

[ldapext trimmed]

At 03:07 PM 2/8/01 +1100, Steven Legg wrote:
>an AttributeValue, whereas it should be an AssertionValue.

Actually, the root of the problem is that the RFC 2254 copy of the
ASN.1 is incorrect!

RFC 2254:
        AttributeValueAssertion ::= SEQUENCE {
                attributeDesc   AttributeDescription,
                attributeValue  AttributeValue
        }

should be as in RFC 2251, 4.1.7:
        AttributeValueAssertion ::= SEQUENCE {
                attributeDesc   AttributeDescription,
                assertionValue  AssertionValue }

then:
   The AttributeValue and AssertionValue OCTET STRING have the form
   defined in [2].

need not refer to AttributeValue.

And, the ABNF should be:
       value      = AttributeValue from Section 4.1.6 of [1]

should be:
       value      = AssertionValue from Section 4.1.7 of [1]

That, I think, should fix this problem.

        Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 8 Feb 2001 16:39:27 +1100

Kurt,

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
> Sent: Thursday, 8 February 2001 15:54
> To: [email-masked]
> Cc: 'Brent Holland'; [email-masked]
> Subject: RE: Extensible Match Filters
> 
> 
> [ldapext trimmed]
> 

That depends on what you think goes in the SubstringFilter. According
to RFC 2251 the initial, any and final components are LDAPString. The
corresponding fields in X.511 are equivalent to AttributeValue, though
it would make more sense if they were AssertionValue instead.

If the intent is to be compatible with X.500 filters, the LDAPStrings
in the SubstringFilter should be regarded as AttributeValues. In this
case <value> in section 4 of RFC 2254 should remain as is and the
<extensible> and <simple> productions should be changed to:

    simple     = attr filtertype assertion-value

    extensible = attr [":dn"] [":" matchingrule] ":=" assertion-value
                 / [":dn"] ":" matchingrule ":=" assertion-value

    assertion-value = AssertionValue from Section 4.1.7 of [1]

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 07 Feb 2001 22:21:48 -0800

At 04:39 PM 2/8/01 +1100, Steven Legg wrote:
>That depends on what you think goes in the SubstringFilter.

I agree that SubstringFilter use of LDAPString is bad.
This restricts the substrings to UTF-8.  I note that
Substring Assertion syntax (RFC 2252, 8.3) is also restricted
to UTF-8.

I prefer to change SubstringFilter to use AssertionValues
as this allows the asserted value syntax to differ from
the attribute value syntax (as allowed by all other filter
choices).

I also suggest an Octet Substring Assertion syntax be
introduced to allow use of non-UTF-8 substring matching
rules with extensible matching.

Kurt