Subject: Re: protocol: placement of initial/final substrings

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 18 Dec 2003 18:06:09 -0700

That assumes a conversion directly from LDAP search filter string format
to BER. Interfaces may exist which allow construction of filters in a
non-string fashion.
 
Novell's eDirectory allows the initial, any, and final components to
come in any order, as did the old UMich code (OpenLDAP later enforced
ordering).
 
Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 12/18/03 4:36:46 PM >>>
At 03:28 PM 12/18/2003, Steven Legg wrote:
>SubstringFilter in [Protocol] is a different ASN.1 type and values of
>this ASN.1 type are always encoded in BER in the protocol. The BER
encoding
>distinguishes the initial, any and final components with different
context
>specific tags, so the order doesn't matter, and no order is imposed. 

I'd argue that there is an ordering has been implicitly imposed
upon the substrings. Otherwise *a*b* would be equivalent to *b*a*
when encoded as BER.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Dec 2003 17:32:56 -0800

At 05:06 PM 12/18/2003, Jim Sermersheim wrote:
>That assumes a conversion directly from LDAP search filter string format to BER. Interfaces may exist which allow construction of filters in a non-string fashion.
> 
>Novell's eDirectory allows the initial, any, and final components to come in any order, as did the old UMich code (OpenLDAP later enforced ordering).

The any are certainly ordered, why wouldn't the initial and final
be as well?

I mean, if you take the lack of an explicit statement to mean
that the order of elements in the SEQUENCE has no semantically
value, then { any "A", any "B" } and { any "B", any "A" } are
equivalent.

Kurt

>>this ASN.1 type are always encoded in BER in the protocol. The BER encoding
>>distinguishes the initial, any and final components with different context