Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules
RFC 3687

Document Type RFC - Proposed Standard (February 2004; No errata)
Last updated 2013-03-02
Stream ISE
Formats plain text pdf html
Stream ISE state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3687 (Proposed Standard)
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
Show full document text