Subject: substring matching rules

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 08 Feb 2000 11:33:35 -0800

RFC 2252, 8.3 says:

   The Substring Assertion syntax is used only as the syntax of
   assertion values in the extensible match.  It is not used as the
   syntax of attributes, or in the substring filter.
   
   ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
   
   [...]
 
   Servers SHOULD be capable of performing the following matching rules,
   which are used in substring filters. 
   
   ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
   
I find this a bit confusing.  The SYNTAX should not be used as
part of substring filters but then is used to specify the syntax
used with substring filters.  Shouldn't the syntax of
caseIgnoreSubstringsMatch, for use with substring filters, have
a syntax of DirectoryString like other caseIngore*Match filters
and that a separate matching rule be defined specifically for
use extended filters?  Is it safe to presume that the syntax of
asserted substring components are of the same syntax as the
attribute value being tested?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 08 Feb 2000 17:56:32 -0800

>    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

Interesting enough, the inetOrgPerson draft says:

13.3.3.  Additional matching rules from X.520

    ( 2.5.13.5 NAME 'caseExactMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
    ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

I don't have a copy of X.520 to confirm correctness.  But
appear so.  When used in a substrings filter, the asserted
substrings are each of directoryString syntax, not each a
substringsAssertion syntax.

The caseIgnoreSubstringsMatch implies that in a substrings
filter, each of the asserted substrings are each of
substringsAssertion syntax.  This is incorrect.  Each should
be a directoryString.

I believe two matching rules, one for substrings filters
and one for extended matching using substrings assertions,
are needed for every match algorithm.   That is:

  ( <OID>.1 NAME 'mySubstringsMatch'
	DESC 'for use with substring filters'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
  ( <OID>.2 NAME 'mySubstringsExtendedMatch'
	DESC 'for use with extended match filters'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

(where <OID> is replaced with some valid OID).

---

From: Mark Wahl <[email-masked]>
Date: Wed, 09 Feb 2000 07:26:51 -0600

Thanks for pointing out this discrepancy in inetorgperson section 13.3.3. 
I'll check with X.501/X.520 and suggest a change to Mark Smith.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: [email-masked] (Mark C Smith)
Date: Wed, 09 Feb 2000 10:04:04 -0500

> I'll check with X.501/X.520 and suggest a change to Mark Smith.

Yes, this looks like a bug in the inetOrgPerson document... to match
X.520, the definition of caseExactSubstringsMatch should be:

I replaced the DirectoryString syntax OID with the OID for
SubstringAssertion.  Correct?

According to X.520, the values that make up a Substring Assertion are
each of syntax DirectoryString:

  6.1.3 Case Ignore Substrings Match

  The Case Ignore Substrings Match rule determines whether a presented
  value is a substring of an attribute value of type DirectoryString,
  without regard to the case (upper or lower) of the strings. 

  caseIgnoreSubstringsMatch MATCHING-RULE ::= {
     SYNTAX SubstringAssertion
     ID id-mr-caseIgnoreSubstringsMatch }

  SubstringAssertion ::= SEQUENCE OF CHOICE {
     initial [0] DirectoryString {ub-match},
     any [1] DirectoryString {ub-match},
     final [2] DirectoryString {ub-match} }
          -- at most one initial and one final component

Kurt, I think the syntaxes associated with matching rules refer to the
syntax of a presented value, e.g., a value that is in a search filter. 
That's how I think about it anyway....

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 09 Feb 2000 09:07:59 -0800

So, if I want to define a bitString substring matching rule
where each asserted component is a bitString, I should define
a bitStringSubstrings (assertion) syntax and than use this as
the syntax of asserted values of bitStringSubstringsMatch?

Okay, so why?

( 2.5.13.10 NAME 'numericStringSubstringsMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

This says that each asserted substring component is of
directoryString syntax.  I would think each asserted substring
component should be of numericString syntax.

---

From: [email-masked] (Mark C Smith)
Date: Wed, 09 Feb 2000 14:41:01 -0500

I don't have access to all of the right standard documents here, but I
suspect that the NumericString syntax is compatible with
DirectoryString.  Not true for bitString or octetString... in fact,
X.521 includes this definition:

  octetStringSubstringsMatch MATCHING-RULE ::= {
    SYNTAX OctetSubstringAssertion
    ID id-mr-octetStringSubstringsMatch }

  OctetSubstringAssertion ::= SEQUENCE OF CHOICE {
    initial [0] OCTET STRING,
    any [1] OCTET STRING,
    final [2] OCTET STRING }
   -- at most one initial and one final component

which is very similar in concept to your bitStringSubstringsMatch
example.

It would be nice to add some text about all of this to RFC2252-bis when
it is created.