RE: substring matching rules

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

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
	               ({SupportedAttributes}{@substrings.type}),
	    any	[1]  ATTRIBUTE.&Type
	               ({SupportedAttributes}{@substrings.type}),
	    final	[2]  ATTRIBUTE.&Type
	               ({SupportedAttributes}{@substrings.type})}},
	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:Kurt@OpenLDAP.org]
 > Sent: Tuesday, February 08, 2000 8:57 PM
 > To: ietf-ldapext@netscape.com
 > 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).
 > 
 >