You're right, I should have said they allow the inital and final to come in any order. >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 12/18/03 6:32:56 PM >>> 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 > >Jim > >>>> "Kurt D. Zeilenga" < Kurt@OpenLDAP.org > 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 |