[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Optional Matching Rule Assertion Syntax

I think such a change might cause some interoperability
problems.  I note that both the OpenLDAP server and C SDK
treat matching rule's SYNTAX field as required.

The alternative, defining a "variable assertion syntax",
to me sounds like a reasonable approach to support the
desired functionality.

Kurt


At 06:13 PM 4/23/01, Steven Legg wrote:

>I've noticed that the 4th edition of X.501 corrects a long standing defect
>in the MatchingRuleDescription ASN.1 type. The MatchingRuleDescription
>type mirrors the MATCHING-RULE information object class so that matching
>rule definitions can be carried in protocol (information objects cannot
>be encoded). The 2nd edition definition of the MATCHING-RULE information
>object class allowed the assertion syntax (the SYNTAX field) to be omitted,
>so that matching rules with a variable assertion syntax could be supported.
>Unfortunately, the 2nd edition definition for MatchingRuleDescription had
>the assertion syntax (the "information" field) as a mandatory component.
>The 4th edition now makes the information field OPTIONAL, the way it
>should have been in the first place.
>
>The LDAP string encoding for the Matching Rule Description syntax adheres
>to the flawed X.501 MatchingRuleDescription in making the SYNTAX field
>a mandatory term. I'd like to see this corrected in the successor to
>RFC 2252 to make the SYNTAX field an optional term.
>
>The Adacel implementation has a number of private matching rules where
>the assertion syntax is variable. In my component matching rules draft
>I need to define additional rules that also have a variable assertion
>syntax. At the moment I have no standard defined way to encode their
>definitions as a value of the Matching Rule Description syntax.
>The alternative is for me to define an LDAP syntax which is taken to
>mean "a variable assertion syntax". Making the SYNTAX field optional
>is a cleaner, more consistent, solution.
>
>Comments ?
>
>Regards,
>Steven