(gathering consensus) RE: Extensible Match Filters

["Jim Sermersheim" <jimse@novell.com>]

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