Mark Wahl wrote:
>
> 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.
Yes, this looks like a bug in the inetOrgPerson document... to match
X.520, the definition of caseExactSubstringsMatch should be:
( 2.5.13.7 NAME 'caseExactSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
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?