RE: Models: Matching Rule Uses

["Steven Legg" <steven.legg@adacel.com.au>]

Kurt,

Kurt D. Zeilenga wrote:
> At 04:18 PM 2/13/2003, David Chadwick wrote:
> >> >So caseIgnoreIA5Match can be used with attributes whose 
> corresponding
> >> >ASN.1 type is IA5String, but not e.g. bit string syntax.  
> I'm hoping
> >> >that this also means that a caseIgnoreIA5Match matching 
> rule use can
> >> >only list attributes whose corresponding ASN.1 type is IA5String.
> >> 
> >> No, the assertion syntax and attribute value syntax can be quite
> >> different.
> >
> >Currently this is not so.
> 
> X.501(93) does not restrict how "different" the syntaxes might
> be.  It only requires that there be "rules for deriving a value of
> the assertion syntax from a value of the attribute syntax, if 
> required."
> 
> And while X.501 says these rules are to be defined as part of 
> the matching
> rule specification, I believe (as is the common practice) 
> that new syntax
> specifications may define new value derivation rules such 
> that existing
> matching rules may be re-used with the new syntax.

While there has been some tweaking of the X.500 string matching rules
over time (because of changes to the Directory String syntax), I believe
that the common practice in the X.500 universe is to define new matching
rules for new syntaxes that don't fall within the set of specified
applicable syntaxes of existing matching rules. Note that for some
matching rules the set of applicable syntaxes is open-ended
(e.g. objectIdentifierFirstComponentMatch applies to any existing syntax
and any future syntax that is a SEQUENCE with an OBJECT IDENTIFER as its
first component). Abuses of the X.500 model are all too common in the
LDAP universe.

Regards,
Steven

> 
> There are a wide variety of uses of the "core" matching rules 
> with attribute
> value syntaxes not considered by the "core" specification.
> 
> Kurt 
> 
>