Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules
RFC 3687
Document | Type |
RFC - Proposed Standard
(February 2004; No errata)
Was draft-legg-ldapext-component-matching (individual in app area)
|
|
---|---|---|---|
Last updated | 2018-07-18 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3687 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
IESG note | Depending on Subentry Specification for LDAP. | ||
Send notices to | <s.legg@trl.telstra.com.au> |
Network Working Group S. Legg Request for Comments: 3687 Adacel Technologies Category: Standards Track February 2004 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The syntaxes of attributes in a Lightweight Directory Access Protocol (LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes. Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. Legg Standards Track [Page 1] RFC 3687 LDAP and X.500 Component Matching Rules February 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ComponentAssertion . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Component Reference. . . . . . . . . . . . . . . . . . . 6 3.1.1. Component Type Substitutions . . . . . . . . . . 7 3.1.2. Referencing SET, SEQUENCE and CHOICE Components. 8 3.1.3. Referencing SET OF and SEQUENCE OF Components. . 9 3.1.4. Referencing Components of Parameterized Types. . 10 3.1.5. Component Referencing Example. . . . . . . . . . 10 3.1.6. Referencing Components of Open Types . . . . . . 12 3.1.6.1. Open Type Referencing Example . . . . . 12 3.1.7. Referencing Contained Types. . . . . . . . . . . 14 3.1.7.1. Contained Type Referencing Example. . . 14 3.2. Matching of Components . . . . . . . . . . . . . . . . . 15 3.2.1. Applicability of Existing Matching Rules . . . . 17 3.2.1.1. String Matching . . . . . . . . . . . . 17 3.2.1.2. Telephone Number Matching . . . . . . . 17 3.2.1.3. Distinguished Name Matching . . . . . . 18 3.2.2. Additional Useful Matching Rules . . . . . . . . 18 3.2.2.1. The rdnMatch Matching Rule. . . . . . . 18 3.2.2.2. The presentMatch Matching Rule. . . . . 19 3.2.3. Summary of Useful Matching Rules . . . . . . . . 20 4. ComponentFilter. . . . . . . . . . . . . . . . . . . . . . . . 21 5. The componentFilterMatch Matching Rule . . . . . . . . . . . . 22 6. Equality Matching of Complex Components. . . . . . . . . . . . 24 6.1. The OpenAssertionType Syntax . . . . . . . . . . . . . . 24 6.2. The allComponentsMatch Matching Rule . . . . . . . . . . 25 6.3. Deriving Component Equality Matching Rules . . . . . . . 27 6.4. The directoryComponentsMatch Matching Rule . . . . . . . 28 7. Component Matching Examples. . . . . . . . . . . . . . . . . . 30 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 37 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 37 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 11.1. Normative References. . . . . . . . . . . . . . . . . . 38 11.2. Informative References. . . . . . . . . . . . . . . . . 40 12. Intellectual Property Statement. . . . . . . . . . . . . . . . 40 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 41 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 42 Legg Standards Track [Page 2] RFC 3687 LDAP and X.500 Component Matching Rules February 2004 1. Introduction The structure or data type of data held in an attribute of a Lightweight Directory Access Protocol (LDAP) [7] or X.500 [19] directory is described by the attribute's syntax. Attribute syntaxes range from simple data types, such as text string, integer, or boolean, to complex data types, for example, the syntaxes of the directory schema operational attributes. In X.500, the attribute syntaxes are explicitly described by AbstractShow full document text