[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (gathering consensus) RE: Extensible Match Filters

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

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