RE: Matching Rules for Constructed Syntaxes

["Heimberg, Jim" <Jim.Heimberg@GD-CS.COM>]

Please change my address to jimhei@cablespeed.com.  Thanks.

-----Original Message-----
From: Steven Legg [mailto:steven.legg@adacel.com.au]
Sent: Tuesday, August 29, 2000 12:06 AM
To: ietf-ldapext@netscape.com; ietf-pkix@imc.org;
osidirectory@az05.bull.com
Subject: RE: Matching Rules for Constructed Syntaxes



Following some private email discussions with Tom Gindin I've decided
on some changes to the way asn1Match, componentMatch and
componentFilterMatch compare strings.

The asn1Match rule isn't exactly a shorthand way of writing an "and"
component filter because it doesn't compare character strings like
any of the existing string matching rules. It compares two strings
letter for letter, so letter case and all spaces are significant,
but it also returns false if two compared DirectoryStrings use different
alternatives in the DirectoryString CHOICE (which will only be
visible in X.500). I think asn1Match will be more useful if it
behaves just like caseIgnoreMatch when it is matching string type
components. The assumed behaviour could be some other string matching
rule, like caseExactMatch, or a purposely defined new string
matching rule. In the absence of any request for an alternative I'll
stick with caseIgnoreMatch. 

This change would make asn1Match somewhat different from its current
implementation in the Adacel directory so I propose instead to define
a new matching rule, which I'll call allComponentsMatch (unless someone
has a better idea), with a new OID.

The DirectoryString type is actually a CHOICE type (i.e. a constructed
syntax) but I was deliberately treating it like a primitive string type
in the examples of componentMatch and componentFilterMatch. Since it is
fairly common practice to replace a specific ASN.1 string type that
turns out to be too restrictive (e.g. PrintableString) with a CHOICE
between the previous string type and a more general string type
(e.g. UTF8String) I propose generalizing the special treatment for
DirectoryString to any CHOICE of string types. Conceptually a string
"component" has an ASN.1 type which is one of the primitive string types
(e.g. PrintableString, IA5String) or a CHOICE of those string types
(e.g. DirectoryString, PKCS9String). Nested CHOICEs would be permitted
also.

Regardless of the string type, I only intend that the string encoding
of ComponentAssertion will use UTF8. The CHOICE construct would not
normally be evident in the string encoding, though it would still be
relevant to the BER encoding. To aid in the conversion between string
encoding and BER encoding I'll provide some simple rules for deciding
which alternative in a CHOICE of strings to assume, and a syntax for
overriding the default rules to force a particular alternative.

Regards,
Steven