Subject: RE: substring matching rules

From: "Salter, Thomas A" <[email-masked]>
Date: Wed, 9 Feb 2000 10:48:18 -0500

Here's the X.511 definition of Filter.  The need for two matching rules
arises from the definition of substrings as three different value components
each having the syntax of the substrings matching rule.  The extensibleMatch
component has only a single value component which, for a substring match,
must be the same SEQUENCE defined in the strings component of the substrings
filter item.
 
Filter	::=	CHOICE {
	item	[0]	FilterItem,
	and	[1]	SET OF Filter,
	or	[2]	SET OF Filter,
	not	[3]	Filter }
FilterItem	::=	CHOICE {
	equality	[0]	AttributeValueAssertion,
	substrings	[1]	SEQUENCE {
	  type	ATTRIBUTE.&id({SupportedAttributes}),
	  strings	SEQUENCE OF CHOICE {
	    initial	[0]  ATTRIBUTE.&Type
	               ([email-masked]}),
	    any	[1]  ATTRIBUTE.&Type
	               ([email-masked]}),
	    final	[2]  ATTRIBUTE.&Type
	               ([email-masked]})}},
	greaterOrEqual	[2]	AttributeValueAssertion,
	lessOrEqual	[3]	AttributeValueAssertion,
	present	[4]	AttributeType,
	approximateMatch 	[5]	AttributeValueAssertion,
	extensibleMatch	[6]	MatchingRuleAssertion }
MatchingRuleAssertion ::= SEQUENCE {
	matchingRule	[1]	SET SIZE (1..MAX) OF MATCHING-RULE.&id,
	type	[2]	AttributeType  OPTIONAL,
	matchValue	[3]	MATCHING-RULE.&AssertionType ( CONSTRAINED
BY {
	-  matchValue must be a value of  type specified by the
&AssertionType field of 
	-- one of the MATCHING-RULE information objects identified by
matchingRule -- } ),
	dnAttributes	[4]	BOOLEAN DEFAULT FALSE }

 > -----Original Message-----
 > From: Kurt D. Zeilenga [mailto:[email-masked]]
 > Sent: Tuesday, February 08, 2000 8:57 PM
 > To: [email-masked]
 > Subject: Re: substring matching rules
 > 
 > 
 > At 11:33 AM 2/8/00 -0800, Kurt D. Zeilenga wrote:
 > >RFC 2252, 8.3 says:
 > >   ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
 > >    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: "Jim Sermersheim" <[email-masked]>
Date: Wed, 09 Feb 2000 15:26:38 -0700

We still need two separate substrings matching rules (Ech). Either that, or the MatchingRuleDescription needs to allow for two syntaxes, one being the syntax used for the matchValue of an extensibleMatch, and the other used for the substrings value of a normal (not extensible) filter.

Jim

>>> Mark C Smith <[email-masked]> 2/9/00 12:42:46 PM >>>
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.

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

"Kurt D. Zeilenga" wrote:
> 
> 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'
> This says that each asserted substring component is of
> directoryString syntax.  I would think each asserted substring
> component should be of numericString syntax.