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

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 18 Dec 2003 15:39:55 -0700

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
>>>
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: Steven Legg <[email-masked]>
Date: Fri, 19 Dec 2003 10:28:05 +1100

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:
>  >>> Hallvard B Furuseth <[email-masked]> 12/11/03 5:21:58 AM >>>
> says so, though the individual matching rules in [Syntaxes] all require
> such placement.
> 
> -- 
> Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Dec 2003 15:34:25 -0800

>I've never heard of this being a constraint in the protocol.

I believe a constraint should be explicitly stated here.  (I'd
argue that definition itself has always implied a constraint.)
Achieving interoperability with multiple encoding options
are possible is problematic.

BTW, OpenLDAP server implements such a constraint.  I don't
recall anyone ever violating it.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Dec 2003 15:36:46 -0800

>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: Steven Legg <[email-masked]>
Date: Fri, 19 Dec 2003 14:16:09 +1100

Kurt,

> upon the substrings.  Otherwise *a*b* would be equivalent to *b*a*

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, 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.

Regards,
Steven

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 19 Dec 2003 09:22:04 +0100

> SubstringAssertion type (flakey, since it's a different type).

In particular since SubstringAssertion, being restricted to UTF-8, can't
be used for an octetStringSubstringsMatch rule.  It's each individual
matching rule which is tied to SubstringAssertion, not matching rules in
general.

-- 
Hallvard