Subject: protocol: placement of initial/final substrings

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 11 Dec 2003 13:21:58 +0100

Must the <initial> and <final> components be the first and last
substrings in a SubstringFilter?  I can find no general statement which
says so, though the individual matching rules in [Syntaxes] all require
such placement.

-- 
Hallvard

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 19 Dec 2003 12:54:03 +1100

And yet it is a SEQUENCE and so some order is implied?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Steven Legg
Sent: Friday, 19 December 2003 10:28
To: Jim Sermersheim; [email-masked]
Cc: [email-masked]
Subject: Re: protocol: placement of initial/final substrings

The matching rules in [Syntaxes] are associated with the SubstringAssertion
ASN.1 type. The fact that the <initial> substring must come first and the
<final> substring must come last is inherent in the ABNF for the LDAP-specific
encoding of the SubstringAssertion ASN.1 type. The ABNF does not tag which
substring is <initial> and which is <final>, so the order of the substrings
has to be taken as significant.

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.

Regards,
Steven

Jim Sermersheim wrote:
> I've never heard of this being a constraint in the protocol.
>  
> Jim
> 
>  >>> Hallvard B Furuseth <[email-masked]> 12/11/03 5:21:58 AM >>>

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 18 Dec 2003 22:20:23 -0700

You're right, I should have said they allow the inital and final to come
in any order.

>>> "Kurt D. Zeilenga" <[email-masked]> 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" < [email-masked] > 12/18/03 4:36:46 PM >>>
>At 03:28 PM 12/18/2003, Steven Legg wrote:

>
>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: "Jim Sermersheim" <[email-masked]>
Date: Thu, 18 Dec 2003 22:24:41 -0700

>>> Steven Legg <[email-masked]> 12/18/03 8:16:09 PM >>>
>
>Yes, the ordering of the "any"s matters. I just had a look what X.511
says
>about the substrings in a FilterItem. It defers to X.520 and the
>SubstringAssertion type (flakey, since it's a different type).
>X.520 says:
>
>"There shall be at most one *initial*, and at most one *final* in
*strings*.
>If *initial* is present, it shall be the first element of *strings*.
If
>*final* is present, it shall be the last element of *strings*."
>
>Exactly what is meant by *strings* isn't actually defined, 
 
'strings' is the name of the SEQUENCE OF CHOICE defined in the X.511
sequence definition, so it's probably refering to that.
 
>but the probable
>intent of all this is that the substrings in filter items are meant to
be
>ordered the same way. A statement to that effect in the protocols
draft
>would be appropriate.

Ok, I'll update to reflect this.
 
Jim