Re: (gathering consensus) RE: Extensible Match Filters

[Mark Smith <mcs@netscape.com>]

Brent Holland wrote:
> 
> There is also the 2254 ASN.1 typo and the 2254 ABNF changes proposed
> by Kurt Zeilenga related to extensible match to be considered:
> ...

I already made some changes to the LDAPv3 filter document (2254
update).  The new document should appear as
draft-ietf-ldapbis-filter-00.txt very soon, but here are the changes I
made related to this thread:


   "LDAP Search Filter Definition" section: made corrections to the
   LDAPv3 search filter ABNF so it matches RFC 2251.  In particular, the
   "at least one must be present" comment and the "substrings" label
   were added to the SubstringFilter initial/any/final sequence and the
   second element of the AttributeValueAssertion was changed from
   "attributeValue AttributeValue" to "assertionValue AssertionValue."

   "String Search Filter Definition" section: replaced the "value" rule
   with a new "assertionvalue" rule within the "simple" and "extensible"
   rules.  Added angle brackets around free-form prose in the "attr",
   "matchingrule", and "value" rules.  Introduced the "valueencoding"
   and associated "normal" and "escaped" rules to reduce the dependence
   on descriptive text.

I also added this loose end:

   There has been some discussion on the LDAPBIS working group
   discussion list about how to modify the LDAPv3 protocol specification
   to support use of substring filters within an extensible match
   filter, which led to further discussion about whether the definition
   of the SubstringFilter should be changed from LDAPString to
   AssertionValue.  Once that issue is resolved, this filter
   specification will likely need to be revised to accommodate the
   group's decision.

If Jim's proposal for the protocol document is accepted, then I will
replace "value" in the String Search Filter ABNF with "assertionvalue"
(in the draft I just submitted, "value" is still used for substring
filter elements).

-Mark



> At 20:54 -0800 2/7/01, Kurt D. Zeilenga wrote:
> >[ldapext trimmed]
> >
> >At 03:07 PM 2/8/01 +1100, Steven Legg wrote:
> >>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.
> >
> >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
> 
> Brent Holland
> 
> At 0:20 -0700 2/21/01, Jim Sermersheim wrote:
> 
> >The proposal for 2251 here is to change the ASN.1 from:
> >
> >SubstringFilter ::= SEQUENCE {
> >      type            AttributeDescription,
> >      -- at least one must be present
> >      substrings      SEQUENCE OF CHOICE {
> >              initial [0] LDAPString,
> >              any     [1] LDAPString,
> >              final   [2] LDAPString } }
> >
> >to:
> >
> >SubstringFilter ::= SEQUENCE {
> >      type            AttributeDescription,
> >      -- at least one must be present
> >      substrings      SEQUENCE OF CHOICE {
> >              initial [0] AssertionValue,
> >              any     [1] AssertionValue,
> >              final   [2] AssertionValue } }
> >
> >We should be cautious about changing the ASN.1. This change doesn't
> >affect the BER encoding as LDAPString and AssertionValue are both
> >OCTET STRING types. It does however, add the ability to send octets
> >that were previously not allowed (was UTF8).
> >
> >There is a possibility that a server or client implementation exists
> >that strictly enforces the protocol--to the point of not allowing
> >non-UTF8 characters wherever LDAPString is specified in protocol.
> >
> >This message is intended to poll for consensus on this issue. If you
> >have an opinion regarding this change, please voice it.
> >
> >Thanks.
> >Jim
> >
> >
> >>>>  "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 2/7/01 11:21:48 PM >>>
> >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