draft-ietf-ldapbis-syntaxes-08.txt   draft-ietf-ldapbis-syntaxes-09.txt 
INTERNET-DRAFT S. Legg, Editor INTERNET-DRAFT S. Legg, Editor
draft-ietf-ldapbis-syntaxes-08.txt Adacel Technologies draft-ietf-ldapbis-syntaxes-09.txt eB2Bcom
Intended Category: Standards Track K. Dally Intended Category: Standards Track K. Dally
Obsoletes: RFC 2252, RFC 2256 The MITRE Corp. Obsoletes: RFC 2252, RFC 2256 The MITRE Corp.
21 May 2004 Updates: RFC 3698 7 October 2004
Lightweight Directory Access Protocol (LDAP): Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules Syntaxes and Matching Rules
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-draft, we certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which we are aware have been disclosed,
or will be disclosed, and any of which we become aware will be
disclosed, in accordance with RFC 3668.
By submitting this Internet-draft, we accept the provisions of
Section 3 of RFC 3667.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
skipping to change at page 1, line 41 skipping to change at page 1, line 46
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is intended to be, after appropriate review and This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document. revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this document is unlimited. Technical discussion of Distribution of this document is unlimited. Technical discussion of
this document should take place on the IETF LDAP Revision Working this document should take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor send editorial comments directly to the editor
<steven.legg@adacel.com.au>. <steven.legg@eb2bcom.com>.
This Internet-Draft expires on 21 November 2004. This Internet-Draft expires on 7 April 2005.
Abstract Abstract
Each attribute stored in a Lightweight Directory Access Protocol Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory, and whose values may be transfered in the LDAP (LDAP) directory, and whose values may be transfered in the LDAP
protocol, has a defined syntax which constrains the structure and protocol, has a defined syntax which constrains the structure and
format of its values. The comparison semantics for values of a format of its values. The comparison semantics for values of a
syntax are not part of the syntax definition but are instead provided syntax are not part of the syntax definition but are instead provided
through separately defined matching rules. Matching rules specify an through separately defined matching rules. Matching rules specify an
argument, an assertion value, which also has a defined syntax. This argument, an assertion value, which also has a defined syntax. This
document defines a base set of syntaxes and matching rules for use in document defines a base set of syntaxes and matching rules for use in
defining attributes for LDAP directories. defining attributes for LDAP directories.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. General Considerations . . . . . . . . . . . . . . . . . 6 3.1. General Considerations . . . . . . . . . . . . . . . . . 6
3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 6 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 7
3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7 3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7
3.3.1. Attribute Type Description . . . . . . . . . . . 7 3.3.1. Attribute Type Description . . . . . . . . . . . 7
3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 7 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 8
3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8 3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8
3.3.4. Country String . . . . . . . . . . . . . . . . . 8 3.3.4. Country String . . . . . . . . . . . . . . . . . 8
3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9
3.3.6. Directory String . . . . . . . . . . . . . . . . 9 3.3.6. Directory String . . . . . . . . . . . . . . . . 9
3.3.7. DIT Content Rule Description . . . . . . . . . . 10 3.3.7. DIT Content Rule Description . . . . . . . . . . 10
3.3.8. DIT Structure Rule Description . . . . . . . . . 11 3.3.8. DIT Structure Rule Description . . . . . . . . . 11
3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12
3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13
3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13
3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14
3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15
3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 15 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 15
3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 15 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 16
3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16
3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 16 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 16
3.3.19. Matching Rule Description. . . . . . . . . . . . 17 3.3.19. Matching Rule Description. . . . . . . . . . . . 17
3.3.20. Matching Rule Use Description. . . . . . . . . . 17 3.3.20. Matching Rule Use Description. . . . . . . . . . 17
3.3.21. Name and Optional UID. . . . . . . . . . . . . . 17 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18
3.3.22. Name Form Description. . . . . . . . . . . . . . 18 3.3.22. Name Form Description. . . . . . . . . . . . . . 18
3.3.23. Numeric String . . . . . . . . . . . . . . . . . 18 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19
3.3.24. Object Class Description . . . . . . . . . . . . 19 3.3.24. Object Class Description . . . . . . . . . . . . 19
3.3.25. Octet String . . . . . . . . . . . . . . . . . . 19 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 20
3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20
3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 20 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 20
3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21
3.3.29. Printable String . . . . . . . . . . . . . . . . 22 3.3.29. Printable String . . . . . . . . . . . . . . . . 22
3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22
3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 23 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24
3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 24 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 24
3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25
4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 25 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1. General Considerations . . . . . . . . . . . . . . . . . 26 4.1. General Considerations . . . . . . . . . . . . . . . . . 26
4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 27 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 27
4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 27 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 28
4.2.2. caseExactIA5Match. . . . . . . . . . . . . . . . 28 4.2.2. booleanMatch . . . . . . . . . . . . . . . . . . 28
4.2.3. caseIgnoreIA5Match . . . . . . . . . . . . . . . 28 4.2.3. caseExactIA5Match. . . . . . . . . . . . . . . . 28
4.2.4. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 29 4.2.4. caseExactMatch . . . . . . . . . . . . . . . . . 29
4.2.5. caseIgnoreListMatch. . . . . . . . . . . . . . . 29 4.2.5. caseExactOrderingMatch . . . . . . . . . . . . . 29
4.2.6. caseIgnoreListSubstringsMatch. . . . . . . . . . 30 4.2.6. caseExactSubstringsMatch . . . . . . . . . . . . 30
4.2.7. caseIgnoreMatch. . . . . . . . . . . . . . . . . 30 4.2.7. caseIgnoreIA5Match . . . . . . . . . . . . . . . 31
4.2.8. caseIgnoreOrderingMatch. . . . . . . . . . . . . 31 4.2.8. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 31
4.2.9. caseIgnoreSubstringsMatch. . . . . . . . . . . . 31 4.2.9. caseIgnoreListMatch. . . . . . . . . . . . . . . 32
4.2.10. distinguishedNameMatch . . . . . . . . . . . . . 32 4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 32
4.2.11. generalizedTimeMatch . . . . . . . . . . . . . . 33 4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33
4.2.12. generalizedTimeOrderingMatch . . . . . . . . . . 33 4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 33
4.2.13. integerFirstComponentMatch . . . . . . . . . . . 33 4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34
4.2.14. integerMatch . . . . . . . . . . . . . . . . . . 34 4.2.14. directoryStringFirstComponentMatch . . . . . . . 34
4.2.15. numericStringMatch . . . . . . . . . . . . . . . 34 4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 35
4.2.16. numericStringSubstringsMatch . . . . . . . . . . 35 4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36
4.2.17. objectIdentifierFirstComponentMatch. . . . . . . 35 4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 36
4.2.18. objectIdentifierMatch. . . . . . . . . . . . . . 36 4.2.18. integerFirstComponentMatch . . . . . . . . . . . 36
4.2.19. octetStringMatch . . . . . . . . . . . . . . . . 37 4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 37
4.2.20. telephoneNumberMatch . . . . . . . . . . . . . . 37 4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 37
4.2.21. telephoneNumberSubstringsMatch . . . . . . . . . 37 4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38
4.2.22. uniqueMemberMatch. . . . . . . . . . . . . . . . 38 4.2.22. numericStringMatch . . . . . . . . . . . . . . . 38
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 38 4.2.23. numericStringOrderingMatch . . . . . . . . . . . 38
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 4.2.24. numericStringSubstringsMatch . . . . . . . . . . 39
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 39 4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40
Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 41 4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 40
Appendix B. Changes from RFC 2252 & RFC 2256 . . . . . . . . . . . 42 4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41
Normative References . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 41
Informative References . . . . . . . . . . . . . . . . . . . . . . 46 4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 42
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 47 4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 43
4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 43
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 44
Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 46
Appendix B. Changes from RFC 2252 & RFC 2256 . . . . . . . . . . . 47
Normative References . . . . . . . . . . . . . . . . . . . . . . . 49
Informative References . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
Each attribute stored in a Lightweight Directory Access Protocol Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory [ROADMAP], and whose values may be transfered in the (LDAP) directory [ROADMAP], and whose values may be transfered in the
LDAP protocol [PROT], has a defined syntax (i.e., data type) which LDAP protocol [PROT], has a defined syntax (i.e., data type) which
constrains the structure and format of its values. The comparison constrains the structure and format of its values. The comparison
semantics for values of a syntax are not part of the syntax semantics for values of a syntax are not part of the syntax
definition but are instead provided through separately defined definition but are instead provided through separately defined
matching rules. Matching rules specify an argument, an assertion matching rules. Matching rules specify an argument, an assertion
skipping to change at page 5, line 12 skipping to change at page 5, line 21
Section 4 provides definitions for the base set of matching rules for Section 4 provides definitions for the base set of matching rules for
LDAP. LDAP.
This document is a integral part of the LDAP technical specification This document is a integral part of the LDAP technical specification
[ROADMAP] which obsoletes the previously defined LDAP technical [ROADMAP] which obsoletes the previously defined LDAP technical
specification [RFC3377] in its entirety. specification [RFC3377] in its entirety.
Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS]. Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
The remainder of RFC 2252 is obsoleted by this document. Sections 6 The remainder of RFC 2252 is obsoleted by this document. Sections 6
and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The
remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. All but
Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document.
A number of schema elements which were included in the previous A number of schema elements which were included in the previous
revision of the LDAP technical specification are not included in this revision of the LDAP technical specification are not included in this
revision of LDAP. Public Key Infrastructure schema elements are now revision of LDAP. Public Key Infrastructure schema elements are now
specified in [LDAP-PKI]. Unless reintroduced in future technical specified in [LDAP-PKI]. Unless reintroduced in future technical
specifications, the remainder are to be considered Historic. specifications, the remainder are to be considered Historic.
The changes from RFC 2252 and RFC 2256 are described in Appendix B of The changes from RFC 2252 and RFC 2256 are described in Appendix B of
this document. this document.
skipping to change at page 11, line 33 skipping to change at page 11, line 44
( 1.3.6.1.4.1.1466.115.121.1.17 ( 1.3.6.1.4.1.1466.115.121.1.17
DESC 'DIT Structure Rule Description' ) DESC 'DIT Structure Rule Description' )
This syntax corresponds to the DITStructureRuleDescription ASN.1 type This syntax corresponds to the DITStructureRuleDescription ASN.1 type
from [X.501]. from [X.501].
3.3.9. DN 3.3.9. DN
A value of the DN syntax is the (purported) distinguished name (DN) A value of the DN syntax is the (purported) distinguished name (DN)
of an entry [MODELS]. The LDAP-specific encoding of a value of this of an entry [MODELS]. The LDAP-specific encoding of a value of this
syntax is defined by the <distinguishedName> rule in [LDAPDN]. syntax is defined by the <distinguishedName> rule from the string
representation of distinguished names [LDAPDN].
Examples (from [LDAPDN]): Examples (from [LDAPDN]):
UID=jsmith,DC=example,DC=net UID=jsmith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net OU=Sales+CN=J. Smith,DC=example,DC=net
CN=John Smith\, III,DC=example,DC=net CN=John Smith\, III,DC=example,DC=net
CN=Before\0dAfter,DC=example,DC=net CN=Before\0dAfter,DC=example,DC=net
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
CN=Lu\C4\8Di\C4\87 CN=Lu\C4\8Di\C4\87
The LDAP definition for the DN syntax is: The LDAP definition for the DN syntax is:
skipping to change at page 26, line 10 skipping to change at page 26, line 26
values. values.
Matching rules that are required for directory operation, or that are Matching rules that are required for directory operation, or that are
in common use, are specified in this section. in common use, are specified in this section.
4.1. General Considerations 4.1. General Considerations
A matching rule is applied to attribute values through an A matching rule is applied to attribute values through an
AttributeValueAssertion or MatchingRuleAssertion [PROT]. The AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
conditions under which an AttributeValueAssertion or conditions under which an AttributeValueAssertion or
MatchingRuleAssertion evaluates to Undefined are specified in [PROT]. MatchingRuleAssertion evaluates to Undefined are specified elsewhere
If an assertion is not Undefined then the result of the assertion is [PROT]. If an assertion is not Undefined then the result of the
the result of applying the selected matching rule. A matching rule assertion is the result of applying the selected matching rule. A
evaluates to TRUE, and in some cases Undefined, as specified in the matching rule evaluates to TRUE, and in some cases Undefined, as
description of the matching rule, otherwise it evaluates to FALSE. specified in the description of the matching rule, otherwise it
evaluates to FALSE.
Each assertion contains an assertion value. The definition of each Each assertion contains an assertion value. The definition of each
matching rule specifies the syntax for the assertion value. The matching rule specifies the syntax for the assertion value. The
syntax of the assertion value is typically, but not necessarily, the syntax of the assertion value is typically, but not necessarily, the
same as the syntax of the attribute values to which the matching rule same as the syntax of the attribute values to which the matching rule
may be applied. Note that the AssertionValue in a SubstringFilter may be applied. Note that the AssertionValue in a SubstringFilter
[PROT] MUST conform to the assertion syntax of the equality matching [PROT] MUST conform to the assertion syntax of the equality matching
rule for the attribute type rather than the assertion syntax of the rule for the attribute type rather than the assertion syntax of the
substrings matching rule for the attribute type. The entire substrings matching rule for the attribute type. The entire
SubstringFilter is converted into an assertion value of the SubstringFilter is converted into an assertion value of the
skipping to change at page 26, line 51 skipping to change at page 27, line 19
The description of each matching rule indicates whether the rule is The description of each matching rule indicates whether the rule is
suitable for use as the equality matching rule (EQUALITY), ordering suitable for use as the equality matching rule (EQUALITY), ordering
matching rule (ORDERING) or substrings matching rule (SUBSTR) in an matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
attribute type definition [MODELS]. attribute type definition [MODELS].
Each matching rule is uniquely identified with an object identifier. Each matching rule is uniquely identified with an object identifier.
The definition of a matching rule should not be subsequently changed. The definition of a matching rule should not be subsequently changed.
If a change is desirable then a new matching rule with a different If a change is desirable then a new matching rule with a different
object identifier should be defined instead. object identifier should be defined instead.
Servers SHOULD implement all the matching rules in Section 4.2. Servers MAY implement the wordMatch and keywordMatch matching rules,
but SHOULD implement the other matching rules in Section 4.2.
Servers MAY implement additional matching rules. Servers MAY implement additional matching rules.
Servers which implement the extensibleMatch filter SHOULD allow the Servers which implement the extensibleMatch filter SHOULD allow the
matching rules listed in Section 4.2 to be used in the matching rules listed in Section 4.2 to be used in the
extensibleMatch filter and SHOULD allow matching rules to be used extensibleMatch filter and SHOULD allow matching rules to be used
with all attribute types known to the server, where the assertion with all attribute types known to the server, where the assertion
syntax of the matching rule is the same as the value syntax of the syntax of the matching rule is the same as the value syntax of the
attribute. attribute.
Servers MUST publish in the matchingRules attribute, the definitions Servers MUST publish in the matchingRules attribute, the definitions
skipping to change at page 27, line 26 skipping to change at page 27, line 44
attribute. attribute.
If the server supports the extensibleMatch filter, then the server If the server supports the extensibleMatch filter, then the server
MAY use the matchingRuleUse attribute to indicate the applicability MAY use the matchingRuleUse attribute to indicate the applicability
(in an extensibleMatch filter) of selected matching rules to (in an extensibleMatch filter) of selected matching rules to
nominated attribute types. nominated attribute types.
4.2. Matching Rule Definitions 4.2. Matching Rule Definitions
When evaluating the numericStringMatch, numericStringSubstringsMatch, When evaluating the numericStringMatch, numericStringSubstringsMatch,
caseExactMatch, caseExactOrderingMatch, caseExactSubstringsMatch,
caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch, caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch,
caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch, caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch,
caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch,
telephoneNumberMatch and telephoneNumberSubstringsMatch matching directoryStringFirstComponentMatch, telephoneNumberMatch and
rules the assertion value and attribute value are prepared according telephoneNumberSubstringsMatch matching rules the assertion value and
to the string preparation algorithms [PREP] for LDAP before being attribute value are prepared according to the string preparation
compared. The Transcode, Normalize, Prohibit and Check bidi steps algorithms [PREP] for LDAP before being compared. The Transcode,
are the same for each of the matching rules. However, the Map and Normalize, Prohibit and Check bidi steps are the same for each of the
Insignificant Character Removal steps depends on the specific rule, matching rules. However, the Map and Insignificant Character Removal
as detailed in the description of these matching rules in the steps depends on the specific rule, as detailed in the description of
sections that follow. these matching rules in the sections that follow.
4.2.1. bitStringMatch 4.2.1. bitStringMatch
The bitStringMatch rule compares an assertion value of the Bit String The bitStringMatch rule compares an assertion value of the Bit String
syntax to an attribute value of a syntax (e.g., the Bit String syntax to an attribute value of a syntax (e.g., the Bit String
syntax) whose corresponding ASN.1 type is BIT STRING. syntax) whose corresponding ASN.1 type is BIT STRING.
If the corresponding ASN.1 type of the attribute syntax does not have If the corresponding ASN.1 type of the attribute syntax does not have
a named bit list (which is the case for the Bit String syntax) then a named bit list (which is the case for the Bit String syntax) then
the rule evaluates to TRUE if and only if the attribute value has the the rule evaluates to TRUE if and only if the attribute value has the
skipping to change at page 28, line 12 skipping to change at page 28, line 32
bitStringMatch operates as above except that trailing zero bits in bitStringMatch operates as above except that trailing zero bits in
the attribute and assertion values are treated as absent. the attribute and assertion values are treated as absent.
The LDAP definition for the bitStringMatch rule is: The LDAP definition for the bitStringMatch rule is:
( 2.5.13.16 NAME 'bitStringMatch' ( 2.5.13.16 NAME 'bitStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
The bitStringMatch rule is an equality matching rule. The bitStringMatch rule is an equality matching rule.
4.2.2. caseExactIA5Match 4.2.2. booleanMatch
The booleanMatch rule compares an assertion value of the Boolean
syntax to an attribute value of a syntax (e.g., the Boolean syntax)
whose corresponding ASN.1 type is BOOLEAN.
The rule evaluates to TRUE if and only if the attribute value and the
assertion value are both TRUE or both FALSE.
The LDAP definition for the booleanMatch rule is:
( 2.5.13.13 NAME 'booleanMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
The booleanMatch rule is an equality matching rule.
4.2.3. caseExactIA5Match
The caseExactIA5Match rule compares an assertion value of the IA5 The caseExactIA5Match rule compares an assertion value of the IA5
String syntax to an attribute value of a syntax (e.g the IA5 String String syntax to an attribute value of a syntax (e.g the IA5 String
syntax) whose corresponding ASN.1 type is IA5String. syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
skipping to change at page 28, line 35 skipping to change at page 29, line 23
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Removal is applied in the Insignificant Character
Removal step. Removal step.
The LDAP definition for the caseExactIA5Match rule is: The LDAP definition for the caseExactIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The caseExactIA5Match rule is an equality matching rule. The caseExactIA5Match rule is an equality matching rule.
4.2.3. caseIgnoreIA5Match 4.2.4. caseExactMatch
The caseExactMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory
String, Printable String, Country String or Telephone Number syntax)
whose corresponding ASN.1 type is DirectoryString or one of the
alternative string types of DirectoryString, e.g., PrintableString
(the other alternatives do not correspond to any syntax defined in
this document).
The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character
string have the same number of characters and corresponding
characters have the same code point.
In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
Insignificant Space Removal is applied in the Insignificant Character
Removal step.
The LDAP definition for the caseExactMatch rule is:
( 2.5.13.5 NAME 'caseExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseExactMatch rule is an equality matching rule.
4.2.5. caseExactOrderingMatch
The caseExactOrderingMatch rule compares an assertion value of the
Directory String syntax to an attribute value of a syntax (e.g., the
Directory String, Printable String, Country String or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
The rule evaluates to TRUE if, and only if, in the code point
collation order, the prepared attribute value character string
appears earlier than the prepared assertion value character string,
i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
Insignificant Space Removal is applied in the Insignificant Character
Removal step.
The LDAP definition for the caseExactOrderingMatch rule is:
( 2.5.13.6 NAME 'caseExactOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseExactOrderingMatch rule is an ordering matching rule.
4.2.6. caseExactSubstringsMatch
The caseExactSubstringsMatch rule compares an assertion value of the
Substring Assertion syntax to an attribute value of a syntax (e.g.,
the Directory String, Printable String, Country String or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
The rule evaluates to TRUE if and only if the prepared substrings of
the assertion value match disjoint portions of the prepared attribute
value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the
beginning of the prepared attribute value character string, and a
<final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if
corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for
comparison, characters are not case folded in the Map preparation
step, and only Insignificant Space Removal is applied in the
Insignificant Character Removal step.
The LDAP definition for the caseExactSubstringsMatch rule is:
( 2.5.13.7 NAME 'caseExactSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseExactSubstringsMatch rule is a substrings matching rule.
4.2.7. caseIgnoreIA5Match
The caseIgnoreIA5Match rule compares an assertion value of the IA5 The caseIgnoreIA5Match rule compares an assertion value of the IA5
String syntax to an attribute value of a syntax (e.g the IA5 String String syntax to an attribute value of a syntax (e.g the IA5 String
syntax) whose corresponding ASN.1 type is IA5String. syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
skipping to change at page 29, line 10 skipping to change at page 31, line 33
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Removal is applied in the Insignificant Character
Removal step. Removal step.
The LDAP definition for the caseIgnoreIA5Match rule is: The LDAP definition for the caseIgnoreIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The caseIgnoreIA5Match rule is an equality matching rule. The caseIgnoreIA5Match rule is an equality matching rule.
4.2.4. caseIgnoreIA5SubstringsMatch 4.2.8. caseIgnoreIA5SubstringsMatch
The caseIgnoreIA5SubstringsMatch rule compares an assertion value of The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax (e.g the Substring Assertion syntax to an attribute value of a syntax (e.g
the IA5 String syntax) whose corresponding ASN.1 type is IA5String. the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if the prepared substrings of The rule evaluates to TRUE if and only if the prepared substrings of
the assertion value match disjoint portions of the prepared attribute the assertion value match disjoint portions of the prepared attribute
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
beginning of the prepared attribute value character string, and a beginning of the prepared attribute value character string, and a
skipping to change at page 29, line 36 skipping to change at page 32, line 10
In preparing the attribute value and assertion value substrings for In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step, comparison, characters are case folded in the Map preparation step,
and only Insignificant Space Removal is applied in the Insignificant and only Insignificant Space Removal is applied in the Insignificant
Character Removal step. Character Removal step.
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
4.2.5. caseIgnoreListMatch 4.2.9. caseIgnoreListMatch
The caseIgnoreListMatch rule compares an assertion value that is a The caseIgnoreListMatch rule compares an assertion value that is a
sequence of strings to an attribute value of a syntax (e.g., the sequence of strings to an attribute value of a syntax (e.g., the
Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
OF the DirectoryString ASN.1 type. OF the DirectoryString ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value and the The rule evaluates to TRUE if and only if the attribute value and the
assertion value have the same number of strings and corresponding assertion value have the same number of strings and corresponding
strings (by position) match according to the caseIgnoreMatch matching strings (by position) match according to the caseIgnoreMatch matching
rule. rule.
skipping to change at page 30, line 17 skipping to change at page 32, line 40
limiting the matching rule to only apply to attributes with the limiting the matching rule to only apply to attributes with the
Postal Address syntax. Postal Address syntax.
The LDAP definition for the caseIgnoreListMatch rule is: The LDAP definition for the caseIgnoreListMatch rule is:
( 2.5.13.11 NAME 'caseIgnoreListMatch' ( 2.5.13.11 NAME 'caseIgnoreListMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
The caseIgnoreListMatch rule is an equality matching rule. The caseIgnoreListMatch rule is an equality matching rule.
4.2.6. caseIgnoreListSubstringsMatch 4.2.10. caseIgnoreListSubstringsMatch
The caseIgnoreListSubstringsMatch rule compares an assertion value of The caseIgnoreListSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax the Substring Assertion syntax to an attribute value of a syntax
(e.g., the Postal Address syntax) whose corresponding ASN.1 type is a (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
SEQUENCE OF the DirectoryString ASN.1 type. SEQUENCE OF the DirectoryString ASN.1 type.
The rule evaluates to TRUE if and only if the assertion value The rule evaluates to TRUE if and only if the assertion value
matches, per the caseIgnoreSubstringsMatch rule, the character string matches, per the caseIgnoreSubstringsMatch rule, the character string
formed by concatenating the strings of the attribute value, except formed by concatenating the strings of the attribute value, except
that none of the <initial>, <any>, or <final> substrings of the that none of the <initial>, <any>, or <final> substrings of the
skipping to change at page 30, line 43 skipping to change at page 33, line 17
Address syntax, the concatenated string omits the <DOLLAR> line Address syntax, the concatenated string omits the <DOLLAR> line
separator and the escaping of "\" and "$" characters. separator and the escaping of "\" and "$" characters.
The LDAP definition for the caseIgnoreListSubstringsMatch rule is: The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreListSubstringsMatch rule is a substrings matching rule. The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
4.2.7. caseIgnoreMatch 4.2.11. caseIgnoreMatch
The caseIgnoreMatch rule compares an assertion value of the Directory The caseIgnoreMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory String syntax to an attribute value of a syntax (e.g., the Directory
String, Printable String, Country String or Telephone Number syntax) String, Printable String, Country String or Telephone Number syntax)
whose corresponding ASN.1 type is DirectoryString or one of the whose corresponding ASN.1 type is DirectoryString or one of its
alternative string types of DirectoryString, e.g., PrintableString alternative string types.
(the other alternatives do not correspond to any syntax defined in
this document).
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only characters are case folded in the Map preparation step, and only
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Removal is applied in the Insignificant Character
Removal step. Removal step.
The LDAP definition for the caseIgnoreMatch rule is: The LDAP definition for the caseIgnoreMatch rule is:
( 2.5.13.2 NAME 'caseIgnoreMatch' ( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreMatch rule is an equality matching rule. The caseIgnoreMatch rule is an equality matching rule.
4.2.8. caseIgnoreOrderingMatch 4.2.12. caseIgnoreOrderingMatch
The caseIgnoreOrderingMatch rule compares an assertion value of the The caseIgnoreOrderingMatch rule compares an assertion value of the
Directory String syntax to an attribute value of a syntax (e.g., the Directory String syntax to an attribute value of a syntax (e.g., the
Directory String, Printable String, Country String or Telephone Directory String, Printable String, Country String or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types. one of its alternative string types.
The rule evaluates to TRUE if, and only if, in the code point The rule evaluates to TRUE if, and only if, in the code point
collation order, the prepared attribute value character string collation order, the prepared attribute value character string
appears earlier than the prepared assertion value character string, appears earlier than the prepared assertion value character string,
skipping to change at page 31, line 47 skipping to change at page 34, line 19
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Removal is applied in the Insignificant Character
Removal step. Removal step.
The LDAP definition for the caseIgnoreOrderingMatch rule is: The LDAP definition for the caseIgnoreOrderingMatch rule is:
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreOrderingMatch rule is an ordering matching rule. The caseIgnoreOrderingMatch rule is an ordering matching rule.
4.2.9. caseIgnoreSubstringsMatch 4.2.13. caseIgnoreSubstringsMatch
The caseIgnoreSubstringsMatch rule compares an assertion value of the The caseIgnoreSubstringsMatch rule compares an assertion value of the
Substring Assertion syntax to an attribute value of a syntax (e.g., Substring Assertion syntax to an attribute value of a syntax (e.g.,
the Directory String, Printable String, Country String or Telephone the Directory String, Printable String, Country String or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types. one of its alternative string types.
The rule evaluates to TRUE if and only if the prepared substrings of The rule evaluates to TRUE if and only if the prepared substrings of
the assertion value match disjoint portions of the prepared attribute the assertion value match disjoint portions of the prepared attribute
value character string in the order of the substrings in the value character string in the order of the substrings in the
skipping to change at page 32, line 28 skipping to change at page 34, line 49
and only Insignificant Space Removal is applied in the Insignificant and only Insignificant Space Removal is applied in the Insignificant
Character Removal step. Character Removal step.
The LDAP definition for the caseIgnoreSubstringsMatch rule is: The LDAP definition for the caseIgnoreSubstringsMatch rule is:
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreSubstringsMatch rule is a substrings matching rule. The caseIgnoreSubstringsMatch rule is a substrings matching rule.
4.2.10. distinguishedNameMatch 4.2.14. directoryStringFirstComponentMatch
The directoryStringFirstComponentMatch rule compares an assertion
value of the Directory String syntax to an attribute value of a
syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
first component of the DirectoryString ASN.1 type.
Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality
matching rule.
The rule evaluates to TRUE if and only if the assertion value matches
the first component of the attribute value using the rules of
caseIgnoreMatch.
The LDAP definition for the directoryStringFirstComponentMatch
matching rule is:
( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The directoryStringFirstComponentMatch rule is an equality matching
rule. When using directoryStringFirstComponentMatch to compare two
attribute values (of an applicable syntax), an assertion value must
first be derived from one of the attribute values. An assertion
value can be derived from an attribute value by taking the first
component of that attribute value.
4.2.15. distinguishedNameMatch
The distinguishedNameMatch rule compares an assertion value of the DN The distinguishedNameMatch rule compares an assertion value of the DN
syntax to an attribute value of a syntax (e.g., the DN syntax) whose syntax to an attribute value of a syntax (e.g., the DN syntax) whose
corresponding ASN.1 type is DistinguishedName. corresponding ASN.1 type is DistinguishedName.
The rule evaluates to TRUE if and only if the attribute value and the The rule evaluates to TRUE if and only if the attribute value and the
assertion value have the same number of relative distinguished names assertion value have the same number of relative distinguished names
and corresponding relative distinguished names (by position) are the and corresponding relative distinguished names (by position) are the
same. A relative distinguished name (RDN) of the assertion value is same. A relative distinguished name (RDN) of the assertion value is
the same as an RDN of the attribute value if and only if they have the same as an RDN of the attribute value if and only if they have
skipping to change at page 33, line 10 skipping to change at page 36, line 10
comparisons return TRUE then the distinguishedNameMatch rule comparisons return TRUE then the distinguishedNameMatch rule
evaluates to Undefined. evaluates to Undefined.
The LDAP definition for the distinguishedNameMatch rule is: The LDAP definition for the distinguishedNameMatch rule is:
( 2.5.13.1 NAME 'distinguishedNameMatch' ( 2.5.13.1 NAME 'distinguishedNameMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
The distinguishedNameMatch rule is an equality matching rule. The distinguishedNameMatch rule is an equality matching rule.
4.2.11. generalizedTimeMatch 4.2.16. generalizedTimeMatch
The generalizedTimeMatch rule compares an assertion value of the The generalizedTimeMatch rule compares an assertion value of the
Generalized Time syntax to an attribute value of a syntax (e.g the Generalized Time syntax to an attribute value of a syntax (e.g the
Generalized Time syntax) whose corresponding ASN.1 type is Generalized Time syntax) whose corresponding ASN.1 type is
GeneralizedTime. GeneralizedTime.
The rule evaluates to TRUE if and only if the attribute value The rule evaluates to TRUE if and only if the attribute value
represents the same universal coordinated time as the assertion represents the same universal coordinated time as the assertion
value. If a time is specified with the minutes or seconds absent value. If a time is specified with the minutes or seconds absent
then the number of minutes or seconds (respectively) is assumed to be then the number of minutes or seconds (respectively) is assumed to be
zero. zero.
The LDAP definition for the generalizedTimeMatch rule is: The LDAP definition for the generalizedTimeMatch rule is:
( 2.5.13.27 NAME 'generalizedTimeMatch' ( 2.5.13.27 NAME 'generalizedTimeMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
The generalizedTimeMatch rule is an equality matching rule. The generalizedTimeMatch rule is an equality matching rule.
4.2.12. generalizedTimeOrderingMatch 4.2.17. generalizedTimeOrderingMatch
The generalizedTimeOrderingMatch rule compares the time ordering of The generalizedTimeOrderingMatch rule compares the time ordering of
an assertion value of the Generalized Time syntax to an attribute an assertion value of the Generalized Time syntax to an attribute
value of a syntax (e.g the Generalized Time syntax) whose value of a syntax (e.g the Generalized Time syntax) whose
corresponding ASN.1 type is GeneralizedTime. corresponding ASN.1 type is GeneralizedTime.
The rule evaluates to TRUE if and only if the attribute value The rule evaluates to TRUE if and only if the attribute value
represents a universal coordinated time which is earlier than the represents a universal coordinated time which is earlier than the
universal coordinated time represented by the assertion value. universal coordinated time represented by the assertion value.
The LDAP definition for the generalizedTimeOrderingMatch rule is: The LDAP definition for the generalizedTimeOrderingMatch rule is:
( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
The generalizedTimeOrderingMatch rule is an ordering matching rule. The generalizedTimeOrderingMatch rule is an ordering matching rule.
4.2.13. integerFirstComponentMatch 4.2.18. integerFirstComponentMatch
The integerFirstComponentMatch rule compares an assertion value of The integerFirstComponentMatch rule compares an assertion value of
the Integer syntax to an attribute value of a syntax (e.g the DIT the Integer syntax to an attribute value of a syntax (e.g the DIT
Structure Rule Description syntax) whose corresponding ASN.1 type is Structure Rule Description syntax) whose corresponding ASN.1 type is
a SEQUENCE with a mandatory first component of the INTEGER ASN.1 a SEQUENCE with a mandatory first component of the INTEGER ASN.1
type. type.
Note that the assertion syntax of this matching rule differs from the Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality attribute syntax of attributes for which this is the equality
matching rule. matching rule.
skipping to change at page 34, line 27 skipping to change at page 37, line 27
( 2.5.13.29 NAME 'integerFirstComponentMatch' ( 2.5.13.29 NAME 'integerFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
The integerFirstComponentMatch rule is an equality matching rule. The integerFirstComponentMatch rule is an equality matching rule.
When using integerFirstComponentMatch to compare two attribute values When using integerFirstComponentMatch to compare two attribute values
(of an applicable syntax), an assertion value must first be derived (of an applicable syntax), an assertion value must first be derived
from one of the attribute values. An assertion value can be derived from one of the attribute values. An assertion value can be derived
from an attribute value by taking the first component of that from an attribute value by taking the first component of that
attribute value. attribute value.
4.2.14. integerMatch 4.2.19. integerMatch
The integerMatch rule compares an assertion value of the Integer The integerMatch rule compares an assertion value of the Integer
syntax to an attribute value of a syntax (e.g the Integer syntax) syntax to an attribute value of a syntax (e.g the Integer syntax)
whose corresponding ASN.1 type is INTEGER. whose corresponding ASN.1 type is INTEGER.
The rule evaluates to TRUE if and only if the attribute value and the The rule evaluates to TRUE if and only if the attribute value and the
assertion value are the same integer value. assertion value are the same integer value.
The LDAP definition for the integerMatch matching rule is: The LDAP definition for the integerMatch matching rule is:
( 2.5.13.14 NAME 'integerMatch' ( 2.5.13.14 NAME 'integerMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
The integerMatch rule is an equality matching rule. The integerMatch rule is an equality matching rule.
4.2.15. numericStringMatch 4.2.20. integerOrderingMatch
The integerOrderingMatch rule compares an assertion value of the
Integer syntax to an attribute value of a syntax (e.g the Integer
syntax) whose corresponding ASN.1 type is INTEGER.
The rule evaluates to TRUE if and only if the integer value of the
attribute value is less than the integer value the assertion value.
The LDAP definition for the integerOrderingMatch matching rule is:
( 2.5.13.15 NAME 'integerOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
The integerOrderingMatch rule is an ordering matching rule.
4.2.21. keywordMatch
The keywordMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory
String syntax) whose corresponding ASN.1 type is DirectoryString.
The rule evaluates to TRUE if and only if the assertion value
character string matches any keyword in the attribute value. The
identification of keywords in the attribute value and the exactness
of the match are both implementation specific.
The LDAP definition for the keywordMatch rule is:
( 2.5.13.33 NAME 'keywordMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
4.2.22. numericStringMatch
The numericStringMatch rule compares an assertion value of the The numericStringMatch rule compares an assertion value of the
Numeric String syntax to an attribute value of a syntax (e.g the Numeric String syntax to an attribute value of a syntax (e.g the
Numeric String syntax) whose corresponding ASN.1 type is Numeric String syntax) whose corresponding ASN.1 type is
NumericString. NumericString.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
skipping to change at page 35, line 19 skipping to change at page 38, line 52
numericString Insignificant Character Removal is applied in the numericString Insignificant Character Removal is applied in the
Insignificant Character Removal step. Insignificant Character Removal step.
The LDAP definition for the numericStringMatch matching rule is: The LDAP definition for the numericStringMatch matching rule is:
( 2.5.13.8 NAME 'numericStringMatch' ( 2.5.13.8 NAME 'numericStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
The numericStringMatch rule is an equality matching rule. The numericStringMatch rule is an equality matching rule.
4.2.16. numericStringSubstringsMatch 4.2.23. numericStringOrderingMatch
The numericStringOrderingMatch rule compares an assertion value of
the Numeric String syntax to an attribute value of a syntax (e.g the
Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
The rule evaluates to TRUE if, and only if, in the code point
collation order, the prepared attribute value character string
appears earlier than the prepared assertion value character string.
In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Removal is applied in the
Insignificant Character Removal step.
The rule is identical to the caseIgnoreOrderingMatch rule except that
all space characters are skipped during comparison (case is
irrelevant as characters are numeric).
The LDAP definition for the numericStringOrderingMatch matching rule
is:
( 2.5.13.9 NAME 'numericStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
The numericStringOrderingMatch rule is an ordering matching rule.
4.2.24. numericStringSubstringsMatch
The numericStringSubstringsMatch rule compares an assertion value of The numericStringSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax (e.g the Substring Assertion syntax to an attribute value of a syntax (e.g
the Numeric String syntax) whose corresponding ASN.1 type is the Numeric String syntax) whose corresponding ASN.1 type is
NumericString. NumericString.
The rule evaluates to TRUE if and only if the prepared substrings of The rule evaluates to TRUE if and only if the prepared substrings of
the assertion value match disjoint portions of the prepared attribute the assertion value match disjoint portions of the prepared attribute
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
skipping to change at page 35, line 49 skipping to change at page 40, line 13
Insignificant Character Removal step. Insignificant Character Removal step.
The LDAP definition for the numericStringSubstringsMatch matching The LDAP definition for the numericStringSubstringsMatch matching
rule is: rule is:
( 2.5.13.10 NAME 'numericStringSubstringsMatch' ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The numericStringSubstringsMatch rule is a substrings matching rule. The numericStringSubstringsMatch rule is a substrings matching rule.
4.2.17. objectIdentifierFirstComponentMatch 4.2.25. objectIdentifierFirstComponentMatch
The objectIdentifierFirstComponentMatch rule compares an assertion The objectIdentifierFirstComponentMatch rule compares an assertion
value of the OID syntax to an attribute value of a syntax (e.g the value of the OID syntax to an attribute value of a syntax (e.g the
Attribute Type Description, DIT Content Rule Description, LDAP Syntax Attribute Type Description, DIT Content Rule Description, LDAP Syntax
Description, Matching Rule Description, Matching Rule Use Description, Matching Rule Description, Matching Rule Use
Description, Name Form Description or Object Class Description Description, Name Form Description or Object Class Description
syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
first component of the OBJECT IDENTIFIER ASN.1 type. first component of the OBJECT IDENTIFIER ASN.1 type.
Note that the assertion syntax of this matching rule differs from the Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality attribute syntax of attributes for which this is the equality
matching rule. matching rule.
The rule evaluates to TRUE if and only if the assertion value matches The rule evaluates to TRUE if and only if the assertion value matches
the first component of the attribute value using the rules of the first component of the attribute value using the rules of
objectIdentifierMatch. objectIdentifierMatch.
The LDAP definition for the objectIdentifierFirstComponentMatch The LDAP definition for the objectIdentifierFirstComponentMatch
matching rule is: matching rule is:
( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch' ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The objectIdentifierFirstComponentMatch rule is an equality matching The objectIdentifierFirstComponentMatch rule is an equality matching
rule. When using objectIdentifierFirstComponentMatch to compare two rule. When using objectIdentifierFirstComponentMatch to compare two
attribute values (of an applicable syntax), an assertion value must attribute values (of an applicable syntax), an assertion value must
first be derived from one of the attribute values. An assertion first be derived from one of the attribute values. An assertion
value can be derived from an attribute value by taking the first value can be derived from an attribute value by taking the first
component of that attribute value. component of that attribute value.
4.2.18. objectIdentifierMatch 4.2.26. objectIdentifierMatch
The objectIdentifierMatch rule compares an assertion value of the OID The objectIdentifierMatch rule compares an assertion value of the OID
syntax to an attribute value of a syntax (e.g the OID syntax) whose syntax to an attribute value of a syntax (e.g the OID syntax) whose
corresponding ASN.1 type is OBJECT IDENTIFIER. corresponding ASN.1 type is OBJECT IDENTIFIER.
The rule evaluates to TRUE if and only if the assertion value and the The rule evaluates to TRUE if and only if the assertion value and the
attribute value represent the same object identifier, that is, the attribute value represent the same object identifier, that is, the
same sequence of integers, whether represented explicitly in the same sequence of integers, whether represented explicitly in the
<numericoid> form of <oid> or implicitly in the <descr> form (see <numericoid> form of <oid> or implicitly in the <descr> form (see
[MODELS]). [MODELS]).
skipping to change at page 37, line 4 skipping to change at page 41, line 15
[MODELS]). [MODELS]).
If an LDAP client supplies an assertion value in the <descr> form, If an LDAP client supplies an assertion value in the <descr> form,
and the chosen descriptor is not recognized by the server, then the and the chosen descriptor is not recognized by the server, then the
objectIdentifierMatch rule evaluates to Undefined. objectIdentifierMatch rule evaluates to Undefined.
The LDAP definition for the objectIdentifierMatch matching rule is: The LDAP definition for the objectIdentifierMatch matching rule is:
( 2.5.13.0 NAME 'objectIdentifierMatch' ( 2.5.13.0 NAME 'objectIdentifierMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The objectIdentifierMatch rule is an equality matching rule. The objectIdentifierMatch rule is an equality matching rule.
4.2.19. octetStringMatch 4.2.27. octetStringMatch
The octetStringMatch rule compares an assertion value of the Octet The octetStringMatch rule compares an assertion value of the Octet
String syntax to an attribute value of a syntax (e.g the Octet String String syntax to an attribute value of a syntax (e.g the Octet String
or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING
ASN.1 type. ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value and the The rule evaluates to TRUE if and only if the attribute value and the
assertion value are the same length and corresponding octets (by assertion value are the same length and corresponding octets (by
position) are the same. position) are the same.
The LDAP definition for the octetStringMatch matching rule is: The LDAP definition for the octetStringMatch matching rule is:
( 2.5.13.17 NAME 'octetStringMatch' ( 2.5.13.17 NAME 'octetStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
The octetStringMatch rule is an equality matching rule. The octetStringMatch rule is an equality matching rule.
4.2.20. telephoneNumberMatch 4.2.28. octetStringOrderingMatch
The octetStringOrderingMatch rule compares an assertion value of the
Octet String syntax to an attribute value of a syntax (e.g the Octet
String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
STRING ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value appears
earlier in the collation order than the assertion value. The rule
compares octet strings from the first octet to the last octet, and
from the most significant bit to the least significant bit within the
octet. The first occurrence of a different bit determines the
ordering of the strings. A zero bit precedes a one bit. If the
strings contain different numbers of octets but the longer string is
identical to the shorter string up to the length of the shorter
string then the shorter string precedes the longer string.
The LDAP definition for the octetStringOrderingMatch matching rule
is:
( 2.5.13.18 NAME 'octetStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
The octetStringOrderingMatch rule is an ordering matching rule.
4.2.29. telephoneNumberMatch
The telephoneNumberMatch rule compares an assertion value of the The telephoneNumberMatch rule compares an assertion value of the
Telephone Number syntax to an attribute value of a syntax (e.g the Telephone Number syntax to an attribute value of a syntax (e.g the
Telephone Number syntax) whose corresponding ASN.1 type is a Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number. PrintableString representing a telephone number.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
skipping to change at page 37, line 48 skipping to change at page 42, line 37
telephoneNumber Insignificant Character Removal is applied in the telephoneNumber Insignificant Character Removal is applied in the
Insignificant Character Removal step. Insignificant Character Removal step.
The LDAP definition for the telephoneNumberMatch matching rule is: The LDAP definition for the telephoneNumberMatch matching rule is:
( 2.5.13.20 NAME 'telephoneNumberMatch' ( 2.5.13.20 NAME 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
The telephoneNumberMatch rule is an equality matching rule. The telephoneNumberMatch rule is an equality matching rule.
4.2.21. telephoneNumberSubstringsMatch 4.2.30. telephoneNumberSubstringsMatch
The telephoneNumberSubstringsMatch rule compares an assertion value The telephoneNumberSubstringsMatch rule compares an assertion value
of the Substring Assertion syntax to an attribute value of a syntax of the Substring Assertion syntax to an attribute value of a syntax
(e.g the Telephone Number syntax) whose corresponding ASN.1 type is a (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number. PrintableString representing a telephone number.
The rule evaluates to TRUE if and only if the prepared substrings of The rule evaluates to TRUE if and only if the prepared substrings of
the assertion value match disjoint portions of the prepared attribute the assertion value match disjoint portions of the prepared attribute
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
skipping to change at page 38, line 31 skipping to change at page 43, line 19
The LDAP definition for the telephoneNumberSubstringsMatch matching The LDAP definition for the telephoneNumberSubstringsMatch matching
rule is: rule is:
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The telephoneNumberSubstringsMatch rule is a substrings matching The telephoneNumberSubstringsMatch rule is a substrings matching
rule. rule.
4.2.22. uniqueMemberMatch 4.2.31. uniqueMemberMatch
The uniqueMemberMatch rule compares an assertion value of the Name The uniqueMemberMatch rule compares an assertion value of the Name
And Optional UID syntax to an attribute value of a syntax (e.g the And Optional UID syntax to an attribute value of a syntax (e.g the
Name And Optional UID syntax) whose corresponding ASN.1 type is Name And Optional UID syntax) whose corresponding ASN.1 type is
NameAndOptionalUID. NameAndOptionalUID.
The rule evaluates to TRUE if and only if the <distinguishedName> The rule evaluates to TRUE if and only if the <distinguishedName>
components of the assertion value and attribute value match according components of the assertion value and attribute value match according
to the distinguishedNameMatch rule and the <BitString> component is to the distinguishedNameMatch rule and the <BitString> component is
absent from the attribute value or matches the <BitString> component absent from the attribute value or matches the <BitString> component
of the assertion value according to the bitStringMatch rule. of the assertion value according to the bitStringMatch rule.
The LDAP definition for the uniqueMemberMatch matching rule is: The LDAP definition for the uniqueMemberMatch matching rule is:
( 2.5.13.23 NAME 'uniqueMemberMatch' ( 2.5.13.23 NAME 'uniqueMemberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
The uniqueMemberMatch rule is an equality matching rule. The uniqueMemberMatch rule is an equality matching rule.
4.2.32. wordMatch
The wordMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory
String syntax) whose corresponding ASN.1 type is DirectoryString.
The rule evaluates to TRUE if and only if the assertion value word
matches, according to the semantics of caseIgnoreMatch, any word in
the attribute value. The precise definition of a word is
implementation specific.
The LDAP definition for the wordMatch rule is:
( 2.5.13.32 NAME 'wordMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
5. Security Considerations 5. Security Considerations
In general, the LDAP-specific encodings for syntaxes defined in this In general, the LDAP-specific encodings for syntaxes defined in this
document do not define canonical encodings. That is, a document do not define canonical encodings. That is, a
transformation from an LDAP-specific encoding into some other transformation from an LDAP-specific encoding into some other
encoding (e.g., BER) and back into the LDAP-specific encoding will encoding (e.g., BER) and back into the LDAP-specific encoding will
not necessarily reproduce exactly the original octets of the not necessarily reproduce exactly the original octets of the
LDAP-specific encoding. Therefore an LDAP-specific encoding should LDAP-specific encoding. Therefore an LDAP-specific encoding should
not be used where a canonical encoding is required. not be used where a canonical encoding is required.
Furthermore, the LDAP-specific encodings do not necessarily enable an Furthermore, the LDAP-specific encodings do not necessarily enable an
alternative encoding of values of the Directory String and DN alternative encoding of values of the Directory String and DN
skipping to change at page 39, line 29 skipping to change at page 44, line 33
digital signatures. Instead, DER or a DER-reversible encoding should digital signatures. Instead, DER or a DER-reversible encoding should
be used. be used.
When interpreting security-sensitive fields, and in particular fields When interpreting security-sensitive fields, and in particular fields
used to grant or deny access, implementations MUST ensure that any used to grant or deny access, implementations MUST ensure that any
matching rule comparisons are done on the underlying abstract value, matching rule comparisons are done on the underlying abstract value,
regardless of the particular encoding used. regardless of the particular encoding used.
6. Acknowledgements 6. Acknowledgements
This document is an revision of RFC 2252 by M. Wahl, A. Coulbeck, T. This document is primarily a revision of RFC 2252 by M. Wahl, A.
Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF
Group. ASID Working Group.
This document is based upon input of the IETF LDAPBIS working group. This document is based upon input of the IETF LDAPBIS working group.
The authors wish to thank J. Sermersheim and K. Zeilenga for their The authors wish to thank J. Sermersheim and K. Zeilenga for their
significant contribution to this revision. significant contribution to this revision.
7. IANA Considerations 7. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to update The Internet Assigned Numbers Authority (IANA) is requested to update
the LDAP descriptors registry [BCP64] as indicated by the following the LDAP descriptors registry [BCP64] as indicated by the following
templates: templates:
Subject: Request for LDAP Descriptor Registration Update Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment Descriptor (short name): see comment
Object Identifier: see comment Object Identifier: see comment
Person & email address to contact for further information: Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au> Steven Legg <steven.legg@eb2bcom.com>
Usage: see comment Usage: see comment
Specification: RFC XXXX Specification: RFC XXXX
Author/Change Controller: IESG Author/Change Controller: IESG
Comments: Comments:
The following descriptors (short names) should be updated to refer The following descriptors (short names) should be updated to refer
to RFC XXXX. to RFC XXXX.
NAME Type OID NAME Type OID
------------------------------------------------------------------ ------------------------------------------------------------------
bitStringMatch M 2.5.13.16 bitStringMatch M 2.5.13.16
booleanMatch M 2.5.13.13
caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
caseExactMatch M 2.5.13.5
caseExactOrderingMatch M 2.5.13.6
caseExactSubstringsMatch M 2.5.13.7
caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
caseIgnoreListMatch M 2.5.13.11 caseIgnoreListMatch M 2.5.13.11
caseIgnoreListSubstringsMatch M 2.5.13.12
caseIgnoreMatch M 2.5.13.2 caseIgnoreMatch M 2.5.13.2
caseIgnoreOrderingMatch M 2.5.13.3 caseIgnoreOrderingMatch M 2.5.13.3
caseIgnoreSubstringsMatch M 2.5.13.4 caseIgnoreSubstringsMatch M 2.5.13.4
directoryStringFirstComponentMatch M 2.5.13.31
distinguishedNameMatch M 2.5.13.1 distinguishedNameMatch M 2.5.13.1
generalizedTimeMatch M 2.5.13.27 generalizedTimeMatch M 2.5.13.27
generalizedTimeOrderingMatch M 2.5.13.28 generalizedTimeOrderingMatch M 2.5.13.28
integerFirstComponentMatch M 2.5.13.29 integerFirstComponentMatch M 2.5.13.29
integerMatch M 2.5.13.14 integerMatch M 2.5.13.14
integerOrderingMatch M 2.5.13.15
keywordMatch M 2.5.13.33
numericStringMatch M 2.5.13.8 numericStringMatch M 2.5.13.8
numericStringOrderingMatch M 2.5.13.9
numericStringSubstringsMatch M 2.5.13.10 numericStringSubstringsMatch M 2.5.13.10
objectIdentifierFirstComponentMatch M 2.5.13.31 objectIdentifierFirstComponentMatch M 2.5.13.30
octetStringMatch M 2.5.13.17 octetStringMatch M 2.5.13.17
octetStringOrderingMatch M 2.5.13.18
telephoneNumberMatch M 2.5.13.20 telephoneNumberMatch M 2.5.13.20
telephoneNumberSubstringsMatch M 2.5.13.21 telephoneNumberSubstringsMatch M 2.5.13.21
uniqueMemberMatch M 2.5.13.23 uniqueMemberMatch M 2.5.13.23
wordMatch M 2.5.13.32
The descriptor for the object identifier 2.5.13.0 was incorrectly The descriptor for the object identifier 2.5.13.0 was incorrectly
registered as objectIdentifiersMatch (extraneous `s') in BCP 64. registered as objectIdentifiersMatch (extraneous `s') in BCP 64.
It should be changed to the following with a reference to RFC It should be changed to the following with a reference to
XXXX. RFC XXXX.
NAME Type OID NAME Type OID
------------------------------------------------------------------ ------------------------------------------------------------------
objectIdentifierMatch M 2.5.13.0 objectIdentifierMatch M 2.5.13.0
Subject: Request for LDAP Descriptor Registration Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreIA5SubstringsMatch Descriptor (short name): caseIgnoreIA5SubstringsMatch
Object Identifier: 1.3.6.1.4.1.1466.109.114.3 Object Identifier: 1.3.6.1.4.1.1466.109.114.3
Person & email address to contact for further information: Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au> Steven Legg <steven.legg@eb2bcom.com>
Usage: other (M)
Specification: RFC XXXX
Author/Change Controller: IESG
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreListSubstringsMatch
Object Identifier: 2.5.13.12
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Usage: other (M) Usage: other (M)
Specification: RFC XXXX Specification: RFC XXXX
Author/Change Controller: IESG Author/Change Controller: IESG
Appendix A. Summary of Syntax Object Identifiers Appendix A. Summary of Syntax Object Identifiers
The following list summarizes the object identifiers assigned to the The following list summarizes the object identifiers assigned to the
syntaxes defined in this document. syntaxes defined in this document.
Syntax OBJECT IDENTIFIER Syntax OBJECT IDENTIFIER
skipping to change at page 44, line 17 skipping to change at page 49, line 22
25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
caseIgnoreSubstringsMatch matching rules have been added to the caseIgnoreSubstringsMatch matching rules have been added to the
list of matching rules for which the provisions for handling list of matching rules for which the provisions for handling
leading, trailing and multiple adjoining whitespace characters leading, trailing and multiple adjoining whitespace characters
apply (now through string preparation). This is consistent with apply (now through string preparation). This is consistent with
the definitions of these matching rules in X.500. The the definitions of these matching rules in X.500. The
caseIgnoreIA5SubstringsMatch rule has also been added to the caseIgnoreIA5SubstringsMatch rule has also been added to the
list. list.
26. The specification of the octetStringMatch matching rule from RFC 26. The specification of the octetStringMatch matching rule from
2256 has been added to this document. RFC 2256 has been added to this document.
27. The presentationAddressMatch matching rule has been removed as it 27. The presentationAddressMatch matching rule has been removed as it
depends on an assertion syntax (Presentation Address) that is not depends on an assertion syntax (Presentation Address) that is not
at draft standard maturity. at draft standard maturity.
28. The protocolInformationMatch matching rule has been removed as it 28. The protocolInformationMatch matching rule has been removed as it
depends on an undefined assertion syntax (Protocol Information). depends on an undefined assertion syntax (Protocol Information).
29. The definitive reference for ASN.1 has been changed from X.208 to 29. The definitive reference for ASN.1 has been changed from X.208 to
X.680 since X.680 is the version of ASN.1 referred to by X.500. X.680 since X.680 is the version of ASN.1 referred to by X.500.
30. The specification of the caseIgnoreListSubstringsMatch matching 30. The specification of the caseIgnoreListSubstringsMatch matching
rule from RFC 2798 & X.520 has been added to this document. rule from RFC 2798 & X.520 has been added to this document.
31. String preparation algorithms have been applied to the character 31. String preparation algorithms have been applied to the character
string matching rules. string matching rules.
32. The specifications of the booleanMatch, caseExactMatch,
caseExactOrderingMatch, caseExactSubstringsMatch,
directoryStringFirstComponentMatch, integerOrderingMatch,
keywordMatch, numericStringOrderingMatch,
octetStringOrderingMatch and wordMatch matching rules from
RFC 3698 & X.520 have been added to this document.
Normative References Normative References
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003. 10646", RFC 3629, November 2003.
skipping to change at page 46, line 26 skipping to change at page 51, line 38
"Lightweight Directory Access Protocol (v3): Attribute "Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997. Syntax Definitions", RFC 2252, December 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997. with LDAPv3", RFC 2256, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377, Protocol (v3): Technical Specification", RFC 3377,
September 2002. September 2002.
[RFC3698] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Additional Matching Rules", RFC 3698, February
2004.
[SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft- [SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft-
ietf-ldapbis-user-schema-xx.txt, a work in progress, June ietf-ldapbis-user-schema-xx.txt, a work in progress, June
2003. 2003.
[LDAP-PKI] Chadwick, D. W. and S. Legg, "LDAP Schema and Syntaxes for [LDAP-PKI] Chadwick, D. W. and S. Legg, "LDAP Schema and Syntaxes for
PKIs", draft-ietf-pkix-ldap-pki-schema-xx.txt, a work in PKIs", draft-ietf-pkix-ldap-pki-schema-xx.txt, a work in
progress, July 2002. progress, July 2002.
[X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - Information Technology - Open Systems Interconnection -
skipping to change at page 46, line 37 skipping to change at page 52, line 4
ietf-ldapbis-user-schema-xx.txt, a work in progress, June ietf-ldapbis-user-schema-xx.txt, a work in progress, June
2003. 2003.
[LDAP-PKI] Chadwick, D. W. and S. Legg, "LDAP Schema and Syntaxes for [LDAP-PKI] Chadwick, D. W. and S. Legg, "LDAP Schema and Syntaxes for
PKIs", draft-ietf-pkix-ldap-pki-schema-xx.txt, a work in PKIs", draft-ietf-pkix-ldap-pki-schema-xx.txt, a work in
progress, July 2002. progress, July 2002.
[X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - Information Technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services The Directory: Overview of concepts, models and services
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER) (DER)
Authors' Addresses Authors' Addresses
Steven Legg Steven Legg
Adacel Technologies Ltd. eB2Bcom
250 Bay Street Suite3, Woodhouse Corporate Centre
Brighton, Victoria 3186 935 Station Street
Box Hill North, Victoria 3129
AUSTRALIA AUSTRALIA
Phone: +61 3 8530 7710 Phone: +61 3 9896 7830
Fax: +61 3 8530 7888 Fax: +61 3 9896 7801
Email: steven.legg@adacel.com.au EMail: steven.legg@eb2bcom.com
Kathy Dally Kathy Dally
The MITRE Corp. The MITRE Corp.
7515 Colshire Dr., ms-W650 7515 Colshire Dr., ms-W650
McLean VA 22102 McLean VA 22102
USA USA
Phone: +1 703 883 6058 Phone: +1 703 883 6058
Fax: +1 703 883 7142 Fax: +1 703 883 7142
Email: kdally@mitre.org Email: kdally@mitre.org
skipping to change at line 2223 skipping to change at page 53, line 23
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
This Internet-Draft expires on 7 April 2005.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/