Hello, there are 6 matching rules for IA5 strings: - caseExactIA5Match - caseIgnoreIA5Match - caseExactIA5SubstringsMatch - caseIgnoreIA5SubstringsMatch - caseExactIA5OrderingMatch - caseIgnoreIA5OrderingMatch
Only three of them are defined in RFC4517: - caseExactIA5Match (1.3.6.1.4.1.1466.109.114.1) - caseIgnoreIA5Match (1.3.6.1.4.1.1466.109.114.2) - caseIgnoreIA5SubstringsMatch (1.3.6.1.4.1.1466.109.114.3)
What are the OIDs for the other three matching rules? - in OpenLDAP - is there a standard?
Regards, Jochen Keutel.
Keutel, Jochen writes:
there are 6 matching rules for IA5 strings:
- caseExactIA5Match
- caseIgnoreIA5Match
- caseExactIA5SubstringsMatch
- caseIgnoreIA5SubstringsMatch
- caseExactIA5OrderingMatch
- caseIgnoreIA5OrderingMatch
Only three of them are defined in RFC4517:
- caseExactIA5Match (1.3.6.1.4.1.1466.109.114.1)
- caseIgnoreIA5Match (1.3.6.1.4.1.1466.109.114.2)
- caseIgnoreIA5SubstringsMatch (1.3.6.1.4.1.1466.109.114.3)
What are the OIDs for the other three matching rules?
I don't find the ordering rules in OpenLDAP. Google shows some results for others. (Or just for specification, I don't know.)
For the other four:
ldapsearch -x -h ldap -b "cn=Subschema" -s base matchingRules | perl -p00e 's/\r?\n //g' | grep "IA5.*Match'" matchingRules: ( 1.3.6.1.4.1.4203.1.2.1 NAME 'caseExactIA5SubstringsMatch' ... ) matchingRules: ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' ... ) matchingRules: ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' ... ) matchingRules: ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' ... )
Hello, OpenLDAP 2.0 admin guide lists all 6 matching rules: http://www.openldap.org/doc/admin20/schema.html .
The OID for caseExactIA5SubstringsMatch - 1.3.6.1.4.1.4203.1.2.1 - is from the OpenLDAP OID branch.
I was asking this question because the sudo scheme is using caseExactIA5SubstringsMatch (attributes sudoUser and sudoHost). Also the NIS schema (RFC 2307) uses caseExactIA5SubstringsMatch: attributes memberUid, memberNisNetgroup and nisMapEntry.
So I was thinking that this matching rule has been standardized somewhere.
Regards, Jochen.
Am 01.09.2010 16:15, schrieb Hallvard B Furuseth:
Keutel, Jochen writes:
there are 6 matching rules for IA5 strings:
- caseExactIA5Match
- caseIgnoreIA5Match
- caseExactIA5SubstringsMatch
- caseIgnoreIA5SubstringsMatch
- caseExactIA5OrderingMatch
- caseIgnoreIA5OrderingMatch
Only three of them are defined in RFC4517:
- caseExactIA5Match (1.3.6.1.4.1.1466.109.114.1)
- caseIgnoreIA5Match (1.3.6.1.4.1.1466.109.114.2)
- caseIgnoreIA5SubstringsMatch (1.3.6.1.4.1.1466.109.114.3)
What are the OIDs for the other three matching rules?
I don't find the ordering rules in OpenLDAP. Google shows some results for others. (Or just for specification, I don't know.)
For the other four:
ldapsearch -x -h ldap -b "cn=Subschema" -s base matchingRules | perl -p00e 's/\r?\n //g' | grep "IA5.*Match'" matchingRules: ( 1.3.6.1.4.1.4203.1.2.1 NAME 'caseExactIA5SubstringsMatch' ... ) matchingRules: ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' ... ) matchingRules: ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' ... ) matchingRules: ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' ... )
On Sep 2, 2010, at 12:38 AM, Keutel, Jochen wrote:
Hello, OpenLDAP 2.0 admin guide lists all 6 matching rules: http://www.openldap.org/doc/admin20/schema.html .
Seems like a bug in the admin guide to me.
So I was thinking that this matching rule has been standardized somewhere.
It hasn't been formally standardized, nor even formally specified. That is, the rule is not formally registered. See http://www.iana.org/assignments/ldap-parameters. slapd(8) supports the caseExactIA5SubstringsMatch rule for historical reasons (because certain Experimental schema relied on it).
Use of IA5 in X.500/LDAP directory services should be avoided. In general, one should use DirectoryString. Any schema which is to be standardized should be appropriately internationalized in accordance with 'Best Current Practices', such as those governing standardization within the IETF.
-- Kurt
Kurt Zeilenga wrote:
Use of IA5 in X.500/LDAP directory services should be avoided. In general, one should use DirectoryString.
I somewhat disagree. I think one should use the string type which matches the particular requirement - not more.
Any schema which is to be standardized should be appropriately internationalized in accordance with 'Best Current Practices', such as those governing standardization within the IETF.
Appropriately internationalized can also mean that a Unicode encoding is used when storing the values in LDAP which fits into IA5String (e.g. DNS names encoded as IDNA or punycode).
That does not mean that every schema using IA5String is well-designed though...
Ciao, Michael.
On Sep 2, 2010, at 11:16 AM, Michael Ströder wrote:
Kurt Zeilenga wrote:
Use of IA5 in X.500/LDAP directory services should be avoided. In general, one should use DirectoryString.
I somewhat disagree. I think one should use the string type which matches the particular requirement - not more.
First, for descriptive text, I note that the IETF did state in BCP 118: LDAP is designed to support the full Unicode [Unicode] repertory of characters. Extensions SHOULD avoid unnecessarily restricting applications to subsets of Unicode (e.g., Basic Multilingual Plane, ISO 8859-1, ASCII, Printable String).
But here we're actually not talking about descriptive text but text which mets a particular (application's) requirement, such as an application identifier.
In this content, I note is generally no string type that would match a particular (application's) requirement for a string. For instance, in the application uses discussed here, are control characters allowed? is NUL (0x00) allowed? Likely not. But they are allowed by the string types (both DirectoryString and IA5String). So one generally ends up having deal with characters which are allowed by the string type but not by the (application's) requirement no matter what.
And it should also be noted that the choice of type is often tied to suitability and availability matching rules. As noted in this thread, the full range of matching found with DirectoryString is not generally available for IA5String. (Of course, many applications will have matching requirements which don't align well with the available matching rules.)
But note that I am speaking in generalities, offering a general recommendation. They may be a particular case where a good argument could be for use of IA5 string in a new attribute.
-- Kurt
openldap-technical@openldap.org
-
Hallvard B Furuseth -
Keutel, Jochen -
Kurt Zeilenga -
Michael Ströder