]> git.sur5r.net Git - openldap/commitdiff
New LDAP RFCs
authorKurt Zeilenga <kurt@openldap.org>
Thu, 11 Mar 2004 21:10:05 +0000 (21:10 +0000)
committerKurt Zeilenga <kurt@openldap.org>
Thu, 11 Mar 2004 21:10:05 +0000 (21:10 +0000)
doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt [deleted file]
doc/drafts/draft-legg-ldapext-component-matching-xx.txt [deleted file]
doc/rfc/INDEX
doc/rfc/rfc3687.txt [new file with mode: 0644]
doc/rfc/rfc3698.txt [new file with mode: 0644]
doc/rfc/rfc3712.txt [new file with mode: 0644]
doc/rfc/rfc3727.txt [new file with mode: 0644]

diff --git a/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt b/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
deleted file mode 100644 (file)
index 230cbc3..0000000
+++ /dev/null
@@ -1,1566 +0,0 @@
-INTERNET-DRAFT                                          K. Dally, Editor
-Intended Category:  Standard Track                       The MITRE Corp.
-Expires:  December 2003                                        June 2003
-Updates:  RFC 2247, RFC 2798
-Obsoletes:  RFC 2256
-
-
-                   LDAP:  Schema for User Applications                  
-                  <draft-ietf-ldapbis-user-schema-06>
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC 2026.
-
-   This document is intended to be, after appropriate review and
-   revision, submitted to the RFC Editor as a Standard Track document.
-   Distribution of this memo is unlimited.  Technical discussion of 
-   this document will take place on the IETF LDAP Revision Working 
-   Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>.  Please 
-   send editorial comments directly to the author <kdally@mitre.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as 
-   Internet-Drafts.  Internet-Drafts are draft documents valid for a 
-   maximum of six months and may be updated, replaced, or obsoleted by 
-   other documents at any time.  It is inappropriate to use 
-   Internet-Drafts as reference material or to cite them other than as 
-   "work in progress."
-
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt.  
-
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html.
-
-
-Copyright Notice
-
-   Copyright 2003, The Internet Society.  All Rights Reserved.
-
-
-Abstract
-
-   This document is a integral part of the Lightweight Directory Access 
-   Protocol (LDAP) technical specification [ROADMAP].  It provides a 
-   technical specification of attribute types and object classes 
-   intended for use by LDAP directory clients for many directory 
-   services, such as, White Pages.  These objects are widely used as a 
-   basis for the schema in many LDAP directories.  This document does 
-   not cover attributes used for the administration of directory 
-   servers, nor does it include directory objects defined for specific 
-   uses in other documents.  
-
-
-Dally                    Expires December 2003                  [Page 1]
-INTERNET-DRAFT      draft-ietf-ldapbis-user-schema-06          June 2003
-
-
-                            Table of Contents                           
-
-Status of this Memo                                                    1
-
-Copyright Notice                                                       1
-
-Abstract                                                               1
-
-Table of Contents                                                      2
-
-1.  Introduction                                                       4
-    1.1  Situation                                                     4
-    1.2  Conventions                                                   4
-    1.3  General Issues                                                4
-    1.4  Source                                                        5
-
-2.  Attribute Types                                                    5
-    2.1  businessCategory                                              5
-    2.2  c                                                             5
-    2.3  cn                                                            6
-    2.4  dc                                                            6
-    2.5  description                                                   6
-    2.6  destinationIndicator                                          7
-    2.7  distinguishedName                                             7
-    2.8  dnQualifier                                                   7
-    2.9  enhancedSearchGuide                                           8
-    2.10 facsimileTelephoneNumber                                      8
-    2.11 generationQualifier                                           8
-    2.12 givenName                                                     8
-    2.13 houseIdentifier                                               9
-    2.14 initials                                                      9
-    2.15 internationalISDNNumber                                       9
-    2.16 l                                                             9
-    2.17 member                                                       10
-    2.18 name                                                         10
-    2.19 o                                                            10
-    2.20 ou                                                           10
-    2.21 owner                                                        11
-    2.22 physicalDeliveryOfficeName                                   11
-    2.23 postalAddress                                                11
-    2.24 postalCode                                                   11
-    2.25 postOfficeBox                                                12
-    2.26 preferredDeliveryMethod                                      12
-    2.27 registeredAddress                                            12
-    2.28 roleOccupant                                                 13
-    2.29 searchGuide                                                  13
-    2.30 seeAlso                                                      13
-    2.31 serialNumber                                                 13
-    2.32 sn                                                           14
-    2.33 st                                                           14
-    2.34 street                                                       14
-    2.35 telephoneNumber                                              14
-
-
-Dally                    Expires December 2003                  [Page 2]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-    2.36 teletexTerminalIdentifier                                    14
-    2.37 telexNumber                                                  15
-    2.38 title                                                        15
-    2.39 uid                                                          15
-    2.40 uniqueMember                                                 15
-    2.41 userPassword                                                 16
-    2.42 x121Address                                                  16
-    2.43 x500UniqueIdentifier                                         16
-
-3.  Object Classes                                                    17
-    3.1  applicationProcess                                           17
-    3.2  country                                                      17
-    3.3  device                                                       17
-    3.4  groupOfNames                                                 18
-    3.5  groupOfUniqueNames                                           18
-    3.6  locality                                                     18
-    3.7  organization                                                 19
-    3.8  organizationalPerson                                         19
-    3.9 organizationalRole                                            19
-    3.10 organizationalUnit                                           20
-    3.11 person                                                       20
-    3.12 residentialPerson                                            20
-
-4.  IANA Considerations                                               21
-
-5.  Security Considerations                                           22
-
-6.  Acknowledgements                                                  23
-
-7.  References                                                        23
-    7.1  Normative                                                    23
-    7.2  Informative                                                  24
-
-8.  Author's Address                                                  25
-
-9.  Full Copyright Statement                                          25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dally                    Expires December 2003                  [Page 3]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2002
-
-
-1.  Introduction
-
-   This document provides an overview of attribute types and object 
-   classes intended for use by Lightweight Directory Access Protocol 
-   directory clients for many directory services, such as, White Pages.
-   Originally specified in the X.500 [X.500] documents, these objects 
-   are widely used as a basis for the schema in many LDAP 
-   directories.  This document does not cover attributes used for the 
-   administration of directory servers, nor does it include directory 
-   objects defined for specific uses in other documents.
-
-1.1  Situation
-
-   This document is a integral part of the LDAP technical specification 
-   [ROADMAP] which obsoletes the previously defined LDAP technical 
-   specification [RFC3377] in its entirety.  In terms of RFC 2256, 
-   Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes].  Sections 
-   5.1, 5.2, 7.1 and 7.2 of RFC 2256 are obsoleted by [Models].  The 
-   remainder of RFC 2256 is obsoleted by this document.  Section 3.4 of 
-   this document supercedes the technical specification for the 'dc' 
-   attribute type found in RFC 2247.[editor's note:  Substitute 
-   replacement RFC at time of publication.]   The remainder of RFC 2247 
-   remains in force.
-
-   This document updates RFC 2798 by replacing the informative 
-   description of the 'uid' attribute type, with the definitive 
-   description provided in Section 2.39 of this document.
-
-   A number of schema elements which were included in the previous 
-   revision of the LDAP Technical Specification are not included in this
-   revision of LDAP.  PKI-related schema elements are now specified in 
-   [LDAP-PKI].  Unless reintroduced in future technical specifications, 
-   the remainder are to be considered Historic.
-
-1.2  Conventions
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-1.3  General Issues
-
-   This document references Syntaxes given in Section 3 of [Syntaxes] 
-   and Matching Rules specified in Section 4 of [Syntaxes].
-
-   The definitions of Attribute Types and Object Classes are written 
-   using the ABNF form of AttributeTypeDescription and 
-   ObjectClassDescription given in [Models].  Lines have been folded 
-   for readability.
-
-
-
-
-
-Dally                    Expires December 2003                  [Page 4]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-1.4  Source
-
-   The schema definitions in this document are based on those found in 
-   the X.500-series [X.520] and [X.521], RFC 2798 [RFC2798] and 
-   RFC 2247 [RFC2247], specifically:
-   
-   Sections             Source
-   ============         ==================
-   2.1 - 2.3            X.520 [X.520]
-   2.4                  RFC 2247 [RFC2247]
-   2.5 - 2.38           X.520 [X.520]
-   2.39                 RFC 2798 [2798]
-   2.40 - 2.43          X.520 [X.520]
-   3.1  - 3.12          X.521 [X.521]
-
-   However, the descriptions in this document SHALL be considered 
-   definitive for use in LDAP.
-
-
-2.  Attribute Types
-
-   The Attribute Types contained in this section hold user information.
-
-   There is no requirement that servers implement the following 
-   attribute types: 
-
-      searchGuide
-      teletexTerminalIdentifier
-
-   In fact, their use is greatly discouraged.
-
-   An LDAP server implementation SHOULD recognize the rest of the 
-   attribute types described in this section.
-
-2.1  businessCategory
-
-   The businessCategory attribute type describes the kinds of business 
-   performed by an organization (e.g., "banking", "transportation").  
-   Each kind is one value of this multi-valued attribute.
-
-   ( 2.5.4.15 NAME 'businessCategory' 
-      EQUALITY caseIgnoreMatch
-      SUBSTR caseIgnoreSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String 
-   syntax [Syntaxes].
-
-2.2  c
-
-   The c (countryName) attribute type contains a two-letter ISO 3166 
-   [ISO3166] country code (e.g., "DE").  (Source:  X.520)
-
-
-Dally                    Expires December 2003                  [Page 5]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-   ( 2.5.4.6 NAME 'c' 
-      SUP name 
-      SINGLE-VALUE )
-
-2.3  cn
-
-   The cn (commonName) attribute type contains names of an object 
-   (e.g., "Martin K Smith", "Marty Smith", "printer12").  Each name is 
-   one value of this multi-valued attribute.  If the object corresponds 
-   to a person, it is typically the person's full name.  
-   (Source:  X.520)
-
-   ( 2.5.4.3 NAME 'cn' 
-      SUP name )
-
-2.4  dc
-
-   The dc (short for domainComponent) attribute type is a string 
-   holding one component, a <label> [RFC1034}, of a DNS domain name 
-   (e.g., "example" or "com", but not "example.com").  The encoding of 
-   IA5String for use in LDAP is simply the characters of the string 
-   itself.  The equality matching rule is case insensitive, as is 
-   today's DNS.
-
-   ( 0.9.2342.19200300.100.1.25 NAME 'dc' 
-      EQUALITY caseIgnoreIA5Match
-      SUBSTR caseIgnoreIA5SubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
-      SINGLE-VALUE )
-
-   1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String 
-   syntax [Syntaxes].
-
-   It is noted that the directory will not ensure that values of this 
-   attribute conform to the label production [RFC1034].  It is the 
-   application responsibility to ensure domains it stores in this 
-   attribute are appropriately represented.
-
-   It is also noted that applications supporting Internationalized 
-   Domain Names SHALL use the ToASCII method [RFC3490] to produce 
-   <label> components of the <domain> production.
-
-2.5  description
-
-   The description attribute type contains human-readable descriptive 
-   phrases about the object (e.g., "a color printer", "Maintenance is 
-   done every Monday, at 1pm.").  Each description is one value of this 
-   multi-valued attribute.  
-
-   ( 2.5.4.13 NAME 'description' 
-      EQUALITY caseIgnoreMatch
-
-
-
-Dally                    Expires December 2003                  [Page 6]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-      SUBSTR caseIgnoreSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String 
-   syntax [Syntaxes].
-
-2.6  destinationIndicator
-
-   The destinationIndicator attribute type contains country and city 
-   strings, associated with the object (the addressee), needed to 
-   provide the Public Telegram Service.  Each string is one value of 
-   this multi-valued attribute.  The strings are composed in accordance 
-   with CCITT Recommendations F.1 [F.1] and F.31 [F.31].
-
-   ( 2.5.4.27 NAME 'destinationIndicator' 
-      EQUALITY caseIgnoreMatch
-      SUBSTR caseIgnoreSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String 
-   syntax [Syntaxes].
-
-2.7  distinguishedName
-
-   The distinguishedName attribute type is the attribute supertype from 
-   which attribute types with DN syntax inherit, instead of containing 
-   values which name the object itself.  The attribute type is 
-   multi-valued.
-
-   It is unlikely that values of this type itself will occur in an 
-   entry.  LDAP server implementations which do not support attribute 
-   subtyping need not recognize this attribute in requests.  Client 
-   implementations MUST NOT assume that LDAP servers are capable of 
-   performing attribute subtyping.
-
-   ( 2.5.4.49 NAME 'distinguishedName' 
-      EQUALITY distinguishedNameMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
-   1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [Syntaxes].
-
-2.8  dnQualifier
-
-   The dnQualifier attribute type contains disambiguating information 
-   strings to add to the relative distinguished name of an entry.  The 
-   information is intended for use when merging data from multiple 
-   sources in order to prevent conflicts between entries which would 
-   otherwise have the same name.  Each string is one value of this 
-   multi-valued attribute.  It is recommended that a value of the 
-   dnQualifier attribute be the same for all entries from a 
-   particular source.
-
-
-
-Dally                    Expires December 2003                  [Page 7]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-   ( 2.5.4.46 NAME 'dnQualifier' 
-      EQUALITY caseIgnoreMatch
-      ORDERING caseIgnoreOrderingMatch 
-      SUBSTR caseIgnoreSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String 
-   syntax [Syntaxes].
-
-2.9  enhancedSearchGuide
-
-   The enhancedSearchGuide attribute type contains sets of information 
-   for use by directory clients in constructing search filters.  Each 
-   set is one value of this multi-valued attribute.
-
-   ( 2.5.4.47 NAME 'enhancedSearchGuide'
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide 
-   syntax [Syntaxes].
-
-2.10  facsimileTelephoneNumber
-
-   The facsimileTelephoneNumber attribute type contains telephone 
-   numbers (and, optionally, the parameters) for facsimile terrminals.  
-   Each telephone number is one value of this multi-valued attribute.
-
-   ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone 
-   Number syntax [Syntaxes].
-
-2.11  generationQualifier
-
-   The generationQualifier attribute type contains name strings that 
-   are the part of a person's name which typically is the suffix, as in 
-   "IIIrd" or "3rd".  Each string is one value of this multi-valued 
-   attribute.
-
-   ( 2.5.4.44 NAME 'generationQualifier' 
-      SUP name )
-
-2.12  givenName
-
-   The givenName attribute type contains name strings that are the part 
-   of a person's name which is not their surname.  Each string is one 
-   value of this multi-valued attribute.
-
-   ( 2.5.4.42 NAME 'givenName' 
-      SUP name )
-
-
-
-Dally                    Expires December 2003                  [Page 8]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-2.13  houseIdentifier
-
-   The houseIdentifier attribute type contains identifiers for a 
-   building within a location.  Each identifier is one value of this 
-   multi-valued attribute.
-
-   ( 2.5.4.51 NAME 'houseIdentifier' 
-      EQUALITY caseIgnoreMatch 
-      SUBSTR caseIgnoreSubstringsMatch 
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String 
-   syntax [Syntaxes].
-
-2.14  initials
-
-   The initials attribute type contains strings of initials of some or 
-   all of an individual's names, except the surname(s) 
-   (e.g., "K. A.", "K").  Each string is one value of this multi-valued 
-   attribute.
-
-   ( 2.5.4.43 NAME 'initials' 
-      SUP name )
-
-2.15  internationalISDNNumber
-
-   The internationalISDNNumber attribute type contains ISDN addresses, 
-   as defined in ITU Recommendation E.164 [E.164].  Each address is one 
-   value of this multi-valued attribute.
-
-   ( 2.5.4.25 NAME 'internationalISDNNumber' 
-      EQUALITY numericStringMatch 
-      SUBSTR numericStringSubstringsMatch 
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String 
-   syntax [Syntaxes].
-
-2.16  l
-
-   The l (localityName) attribute type contains names of a locality or 
-   place, such as a city, county or other geographic region (e.g., 
-   "Geneva").  Each name is one value of this multi-valued attribute.  
-   (Source:  X.520)
-
-   ( 2.5.4.7 NAME 'l' 
-      SUP name )
-
-
-
-
-
-
-
-Dally                    Expires December 2003                  [Page 9]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-2.17  member
-
-   The member attribute type contains the Distinguished Names of 
-   objects that are on a list or in a group.  Each name is one value of 
-   this multi-valued attribute.
-
-   ( 2.5.4.31 NAME 'member' 
-      SUP distinguishedName )
-
-2.18  name
-
-   The name attribute type is the attribute supertype from which 
-   attributes with the name syntax inherit.  Such attributes are 
-   typically used for naming.  The attribute type is multi-valued.
-
-   It is unlikely that values of this type itself will occur in an 
-   entry.  LDAP server implementations which do not support attribute 
-   subtyping need not recognize this attribute in requests.  Client 
-   implementations MUST NOT assume that LDAP servers are capable of 
-   performing attribute subtyping.
-
-   ( 2.5.4.41 NAME 'name' 
-      EQUALITY caseIgnoreMatch
-      SUBSTR caseIgnoreSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String 
-   syntax [Syntaxes].
-
-2.19  o
-
-   The o (organizationName) attribute type contains the names of an 
-   organization (e.g., "IETF", "Internet Engineering Task Force").  
-   Each name is one value of this multi-valued attribute.  
-   (Source:  X.520)
-
-   ( 2.5.4.10 NAME 'o' 
-      SUP name )
-
-2.20  ou
-
-   The ou (organizationalUnitName) attribute type contains the names of 
-   an organizational unit (e.g., "Application Area", "LDAPbis WG").  
-   Each name is one value of this multi-valued attribute.  
-   (Source:  X.520)
-
-   ( 2.5.4.11 NAME 'ou' 
-      SUP name )
-
-
-
-
-
-
-Dally                   Expires December 2003                  [Page 10]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-2.21  owner
-
-   The owner attribute type contains the Distinguished Names of objects 
-   that have an ownership responsibility for the object that is owned.  
-   (e.g., The list object, "cn=All Employees, ou=Mailing List, 
-   o=Widget, Inc.", is owned by the role object, "cn=ou=Human Resources 
-   Director, ou=employee, o=Widget, Inc.")  Each name is one value of 
-   this multi-valued attribute.
-
-   ( 2.5.4.32 NAME 'owner' 
-      SUP distinguishedName )
-
-2.22  physicalDeliveryOfficeName
-
-   The physicalDeliveryOfficeName attribute type contains names that a 
-   Postal Service uses to identify a post office (e.g., "Bremerhaven, 
-   Main", "Bremerhaven, Bonnstrasse").
-
-   ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' 
-      EQUALITY caseIgnoreMatch
-      SUBSTR caseIgnoreSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String 
-   syntax [Syntaxes].
-
-2.23  postalAddress
-
-   The postalAddress attribute type contains addresses used by a Postal 
-   Service to perform services for the object (e.g., "15 Main St., 
-   Ottawa, Canada").  Each address is one value of this multi-valued 
-   attribute.
-
-   ( 2.5.4.16 NAME 'postalAddress' 
-      EQUALITY caseIgnoreListMatch
-      SUBSTR caseIgnoreListSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address 
-   syntax [Syntaxes].
-
-2.24  postalCode
-
-   The postalCode attribute type contains codes used by a Postal 
-   Service to identify a postal service zones, such as the southern 
-   quadrant of a city (e.g., "22180").  Each code is one value of this 
-   multi-valued attribute.
-
-   ( 2.5.4.17 NAME 'postalCode' 
-      EQUALITY caseIgnoreMatch
-      SUBSTR caseIgnoreSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
-
-
-Dally                   Expires December 2003                  [Page 11]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String 
-   syntax [Syntaxes].
-
-2.25  postOfficeBox
-
-   The postOfficeBox attribute type contains numbers that a Postal 
-   Service uses when a customer arranges to receive mail at a box on 
-   premises of the Postal Service (e.g., "Box 45").  Each number is one 
-   value of this multi-valued attribute.
-
-
-   ( 2.5.4.18 NAME 'postOfficeBox' 
-      EQUALITY caseIgnoreMatch
-      SUBSTR caseIgnoreSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String 
-   syntax [Syntaxes].
-
-2.26  preferredDeliveryMethod
-
-   The preferredDeliveryMethod attribute type contains an indication of 
-   the preferred method of getting a message to the object.  For example,
-   if mhs-delivery is preferred over telephone-delivery, which is 
-   preferred over all other methods, the value of the value would 
-   be {1, 9}.
-
-   ( 2.5.4.28 NAME 'preferredDeliveryMethod'
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 
-      SINGLE-VALUE )
-
-   1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method
-   syntax [Syntaxes].
-
-2.27  registeredAddress
-
-   The registeredAddress attribute type contains postal addresses 
-   suitable for reception of telegrams or expedited documents, where it 
-   is necessary to have the recipient accept delivery (e.g., 
-   "Receptionist, Widget Inc., 15 Main St., Ottawa, Canada").  Each 
-   address is one value of this multi-valued attribute.
-
-   ( 2.5.4.26 NAME 'registeredAddress' 
-      SUP postalAddress
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address 
-   syntax [Syntaxes].
-
-
-
-
-
-
-Dally                   Expires December 2003                  [Page 12]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-2.28  roleOccupant
-
-   The roleOccupant attribute type contains the Distinguished Names of 
-   objects(normally people) that fulfill the responsibilities of a role 
-   object.  For example, the role object, "cn=Human Resources Director, 
-   ou=Position, o=Widget, Inc.", is fulfilled by two people whose 
-   object names are "cn=Mary Smith, ou=employee, o=Widget, Inc." and 
-   "cn=James Brown, ou=employee, o=Widget, Inc."  Each name is one 
-   value of this multi-valued attribute.
-
-   ( 2.5.4.33 NAME 'roleOccupant' 
-      SUP distinguishedName )
-
-2.29  searchGuide
-
-   The searchGuide attribute type contains sets of information for use 
-   by clients in constructing search filters.  It is superseded by 
-   enhancedSearchGuide, described above in section 2.9.
-
-   ( 2.5.4.14 NAME 'searchGuide'
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )  
-
-   1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [Syntaxes].
-
-2.30  seeAlso
-
-   The seeAlso attribute type contains Distinguished Names of objects 
-   that are related to the subject object.  For example, the person 
-   object, "cn=James Brown, ou=employee, o=Widget Inc." is related to 
-   the role objects, "cn=Football Team Captain, ou=sponsored 
-   activities, o=Widget Inc." and "cn=Chess Team, ou=sponsored 
-   activities, o=Widget Inc.".  Each name is one value of this 
-   multi-valued attribute.
-
-   ( 2.5.4.34 NAME 'seeAlso' 
-      SUP distinguishedName )
-
-2.31  serialNumber
-
-   The serialNumber attribute type contains the serial numbers of 
-   devices (e.g., "WI-3005".  Each number is one value of this 
-   multi-valued attribute.
-
-   ( 2.5.4.5 NAME 'serialNumber' 
-      EQUALITY caseIgnoreMatch
-      SUBSTR caseIgnoreSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String 
-   syntax [Syntaxes].
-
-
-
-
-Dally                   Expires December 2003                  [Page 13]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-2.32  sn
-
-   The sn (surname)attribute type contains name strings for the family 
-   names of a person (e.g., "Smith").  Each string is one value of this 
-   multi-valued attribute.  (Source:  X.520)
-
-   ( 2.5.4.4 NAME 'sn' 
-      SUP name )
-
-2.33  st
-
-   The st (stateOrProvinceName) attribute type contains the full names 
-   of states or provinces, (e.g. "California").  Each name is one value 
-   of this multi-valued attribute.
-
-   ( 2.5.4.8 NAME 'st' 
-      SUP name )
-
-2.34  street
-
-   The street (streetAddress) attribute type contains physical 
-   addresses of the object to which the entry corresponds, such as an 
-   address for package delivery.  Each address is one value of this 
-   multi-valued attribute.
-
-   ( 2.5.4.9 NAME 'street' 
-      EQUALITY caseIgnoreMatch
-      SUBSTR caseIgnoreSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String 
-   syntax [Syntaxes].
-
-2.35  telephoneNumber
-
-   The telephoneNumber attribute type contains telephone numbers 
-   complying with ITU Recommendation E.123 [E.123] 
-   (e.g., 1 234 567 8901)  Each number is one value of this 
-   multi-valued attribute.
-
-   ( 2.5.4.20 NAME 'telephoneNumber' 
-      EQUALITY telephoneNumberMatch
-      SUBSTR telephoneNumberSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number 
-   syntax [Syntaxes].
-
-2.36  teletexTerminalIdentifier
-
-   The withdrawal of Rec. F.200 has resulted in the withdrawal of this 
-   attribute. 
-
-
-Dally                   Expires December 2003                  [Page 14]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-   ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) 
-
-2.37  telexNumber
-
-   The telexNumber attribute type contains sets of strings which are a 
-   telex number, country code, and answerback code of a telex 
-   terminal.  Each set is one value of this multi-valued attribute.
-
-   ( 2.5.4.21 NAME 'telexNumber'
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number 
-   syntax [Syntaxes].
-
-2.38  title
-
-   This attribute contains the title, such as "Vice President", of a 
-   person in their organizational context.
-
-   ( 2.5.4.12 NAME 'title' 
-      SUP name )
-
-2.39  uid
-
-   The uid attribute type contains computer system login names 
-   associated with the object.  (Source: RFC 1274, 
-   RFC 2798).  Each name is one value of this multi-valued attribute.
-
-   ( 0.9.2342.19200300.100.1.1
-      NAME 'uid'
-      EQUALITY caseIgnoreMatch
-      SUBSTR caseIgnoreSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
-   syntax [Syntaxes].
-
-2.40  uniqueMember
-
-   The uniqueMember attribute type contains the Distinguished Names of 
-   an object that is on a list or in a group, where the Relative 
-   Distinguished Names of the object include a value that distinguishs 
-   between objects when a distinguished name has been reused.  For 
-   example, if "ou=1st Battalion, o=Defense, c=US" is a battalion that 
-   was disbanded, establishing a new battalion with the "same" name 
-   would have a uid value added, resulting in 
-   "ou=1st Battalion#'010101', o=Defense, c=US".  
-
-   ( 2.5.4.50 NAME 'uniqueMember' 
-      EQUALITY uniqueMemberMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) 
-
-
-Dally                   Expires December 2003                  [Page 15]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-   1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID 
-   syntax [Syntaxes].
-
-2.41  userPassword
-
-   The userPassword attribute type contains character strings that are 
-   known only to the user and the system to which the user has access.  
-   Each string is one value of this multi-valued attribute.
-
-   The application SHOULD prepare textual strings used as passwords by 
-   transcoding them to Unicode, applying SASLprep [SASLprep], and 
-   encoding as UTF-8.
-
-   ( 2.5.4.35 NAME 'userPassword' 
-      EQUALITY octetStringMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String 
-   syntax [Syntaxes].
-
-   Passwords are stored using an Octet String syntax and are not 
-   encrypted.  Transfer of cleartext passwords is strongly discouraged 
-   where the underlying transport service cannot guarantee 
-   confidentiality and may result in disclosure of the password to 
-   unauthorized parties.
-
-   An example of a need for multiple values in the userPassword 
-   attribute is an environment where every month the user was expected 
-   to use a different password generated by some automated system.  
-   During transitional periods, like say the last and first day of the 
-   periods, it may be necessary to allow two passwords for the two 
-   consecutive periods to be valid in the system.
-
-2.42  x121Address
-
-   The x121Address attribute type contains data network addresses 
-   (e.g., 36111222333444555) as defined by ITU Recommendation X.121 
-   [X.121].  Each address is one value of this multi-valued attribute.
-
-   ( 2.5.4.24 NAME 'x121Address' 
-      EQUALITY numericStringMatch
-      SUBSTR numericStringSubstringsMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String 
-   syntax [Syntaxes].
-
-2.43  x500UniqueIdentifier
-
-   The x500UniqueIdentifier attribute type contains binary strings that 
-   are used to distinguish between objects when a distinguished name 
-   has been reused.  Each string is one value of this multi-valued 
-
-
-Dally                   Expires December 2003                  [Page 16]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-   attribute.  In X.520 [X.520], this attribute type is called 
-   uniqueIdentifier.  This is a different attribute type from both the 
-   "uid" and "uniqueIdentifier" attribute types.
-
-   ( 2.5.4.45 NAME 'x500UniqueIdentifier' 
-      EQUALITY bitStringMatch
-      SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 
-
-   1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String 
-   syntax [Syntaxes].
-
-
-3.  Object Classes
-
-   LDAP servers SHOULD recognize all the Object Classes listed here as 
-   values of the objectClass attribute (see [Models]).
-
-3.1  applicationProcess
-
-   The applicationProcess object class definition is the basis of an 
-   entry which represents an application executing in a computer system.
-
-   ( 2.5.6.11 NAME 'applicationProcess' 
-      SUP top 
-      STRUCTURAL 
-      MUST cn
-      MAY ( seeAlso $ 
-            ou $ 
-            l $ 
-            description ) ) 
-
-3.2  country
-
-   The country object class definition is the basis of an entry which 
-   represents a country.
-
-   ( 2.5.6.2 NAME 'country' 
-      SUP top 
-      STRUCTURAL 
-      MUST c
-      MAY ( searchGuide $ 
-            description ) )
-
-3.3  device
-
-   The device object class is the basis of an entry which represents an 
-   appliance or computer or network element.
-
-   ( 2.5.6.14 NAME 'device' 
-      SUP top 
-      STRUCTURAL 
-      MUST cn
-
-
-Dally                   Expires December 2003                  [Page 17]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-      MAY ( serialNumber $ 
-            seeAlso $ 
-            owner $ 
-            ou $ 
-            o $ 
-            l $ 
-            description ) )
-
-3.4  groupOfNames
-
-   The groupOfNames object class is the basis of an entry which 
-   represents a set of named objects including information related to 
-   the purpose or maintenance of the set.
-
-   ( 2.5.6.9 NAME 'groupOfNames' 
-      SUP top 
-      STRUCTURAL 
-      MUST ( member $ 
-            cn )
-      MAY ( businessCategory $ 
-            seeAlso $ 
-            owner $ 
-            ou $ 
-            o $ 
-            description ) )
-
-3.5  groupOfUniqueNames
-
-   The groupOfUniqueNames object class is the same as the groupOfNames 
-   object class except that the object names are not repeated or 
-   reassigned within a set scope.
-
-   ( 2.5.6.17 NAME 'groupOfUniqueNames' 
-      SUP top 
-      STRUCTURAL
-      MUST ( uniqueMember $ 
-            cn )
-      MAY ( businessCategory $ 
-            seeAlso $ 
-            owner $ 
-            ou $ 
-            o $ 
-            description ) ) 
-
-3.6  locality
-
-   The locality object class is the basis of an entry which represents 
-   a place in the physical world.
-
-   ( 2.5.6.3 NAME 'locality' 
-      SUP top 
-      STRUCTURAL
-
-
-Dally                   Expires December 2003                  [Page 18]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-      MAY ( street $ 
-            seeAlso $ 
-            searchGuide $ 
-            st $ 
-            l $ 
-            description ) )
-
-3.7  organization
-
-   The organization object class is the basis of an entry which 
-   represents a structured group of people.
-
-   ( 2.5.6.4 NAME 'organization' 
-      SUP top 
-      STRUCTURAL 
-      MUST o
-      MAY ( userPassword $ searchGuide $ seeAlso $ 
-            businessCategory $ x121Address $ registeredAddress $ 
-            destinationIndicator $ preferredDeliveryMethod $ 
-            telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ 
-            internationaliSDNNumber $ facsimileTelephoneNumber $ 
-            street $ postOfficeBox $ postalCode $ 
-            postalAddress $ physicalDeliveryOfficeName $ st $ 
-            l $ description ) )
-
-3.8  organizationalPerson
-
-   The organizationalPerson object class is the basis of an entry which 
-   represents a person in relation to an organization.  
-
-   ( 2.5.6.7 NAME 'organizationalPerson' 
-      SUP person 
-      STRUCTURAL
-      MAY ( title $ x121Address $ registeredAddress $ 
-            destinationIndicator $ preferredDeliveryMethod $ 
-            telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ 
-            internationaliSDNNumber $ facsimileTelephoneNumber $ 
-            street $ postOfficeBox $ postalCode $ postalAddress $ 
-            physicalDeliveryOfficeName $ ou $ st $ l ) )
-
-3.9  organizationalRole
-
-   The organizationalRole object class is the basis of an entry which 
-   represents a job or function or position in an organization.
-
-   ( 2.5.6.8 NAME 'organizationalRole' 
-      SUP top 
-      STRUCTURAL 
-      MUST cn
-      MAY ( x121Address $ registeredAddress $ destinationIndicator $ 
-            preferredDeliveryMethod $ telexNumber $ 
-            teletexTerminalIdentifier $ telephoneNumber $ 
-
-
-Dally                   Expires December 2003                  [Page 19]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-            internationaliSDNNumber $ facsimileTelephoneNumber $ 
-            seeAlso $ roleOccupant $ preferredDeliveryMethod $ 
-            street $ postOfficeBox $ postalCode $ postalAddress $ 
-            physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
-
-3.10  organizationalUnit
-
-   The organizationalUnit object class is the basis of an entry which 
-   represents a piece of an organization.
-
-   ( 2.5.6.5 NAME 'organizationalUnit' 
-      SUP top 
-      STRUCTURAL 
-      MUST ou
-      MAY ( businessCategory $ description $ destinationIndicator $ 
-            facsimileTelephoneNumber $ internationaliSDNNumber $ l $ 
-            physicalDeliveryOfficeName $ postalAddress $ postalCode $ 
-            postOfficeBox $ preferredDeliveryMethod $ 
-            registeredAddress $ searchGuide $ seeAlso $ st $ street $ 
-            telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ 
-            userPassword $ x121Address ) )
-
-3.11  person
-
-   The person object class is the basis of an entry which represents a 
-   human being.
-
-   ( 2.5.6.6 NAME 'person' 
-      SUP top 
-      STRUCTURAL 
-      MUST ( sn $ 
-            cn )
-      MAY ( userPassword $ 
-            telephoneNumber $ 
-            seeAlso $ 
-            description ) ) 
-
-3.12  residentialPerson
-
-   The residentialPerson object class is the basis of an entry which 
-   includes a person's residence in the representation of the person. 
-
-   ( 2.5.6.10 NAME 'residentialPerson' 
-      SUP person 
-      STRUCTURAL 
-      MUST l
-      MAY ( businessCategory $ x121Address $ registeredAddress $ 
-            destinationIndicator $ preferredDeliveryMethod $ 
-            telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ 
-            internationaliSDNNumber $ facsimileTelephoneNumber $ 
-            preferredDeliveryMethod $ street $ postOfficeBox $ 
-
-
-
-Dally                   Expires December 2003                  [Page 20]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-            postalCode $ postalAddress $ physicalDeliveryOfficeName $ 
-            st $ l ) )
-
-
-4.  IANA Considerations
-
-   It is requested that the Internet Assigned Numbers Authority (IANA) 
-   update the LDAP descriptors registry as indicated in the following 
-   template:
-
-      Subject: Request for LDAP Descriptor Registration Update
-      Descriptor (short name): see comment
-      Object Identifier: see comment
-      Person & email address to contact for further information:
-            Kathy Dally <kdally@mitre.org>
-      Usage: (A = attribute type, O = Object Class) see comment
-      Specification: RFC XXXX [editor's note:  The RFC number will be 
-            the one assigned to this document.
-      Author/Change Controller: IESG
-
-   Comments
-   In the LDAP descriptors registry, the following descriptors (short 
-   names) should be updated to refer to RFC XXXX [editor's note:  This 
-   document].
-
-      NAME                         Type OID
-      ------------------------     ---- ----------------------------
-      applicationProcess           O    2.5.6.11
-      businessCategory             A    2.5.4.15
-      c                            A    2.5.4.6
-      cn                           A    2.5.4.3
-      country                      O    2.5.6.2
-      dc                           A    0.9.2342.19200300.100.1.25
-      description                  A    2.5.4.13
-      destinationIndicator         A    2.5.4.27
-      device                       O    2.5.6.14
-      distinguishedName            A    2.5.4.49
-      dnQualifier                  A    2.5.4.46
-      enhancedSearchGuide          A    2.5.4.47
-      facsimileTelephoneNumber     A    2.5.4.23
-      generationQualifier          A    2.5.4.44
-      givenName                    A    2.5.4.42
-      groupOfNames                 O    2.5.6.9
-      groupOfUniqueNames           O    2.5.6.17
-      houseIdentifier              A    2.5.4.51
-      initials                     A    2.5.4.43
-      internationalISDNNumber      A    2.5.4.25
-      l                            A    2.5.4.7
-      locality                     O    2.5.6.3
-      member                       A    2.5.4.31
-      name                         A    2.5.4.41
-      o                            A    2.5.4.10
-
-
-Dally                   Expires December 2003                  [Page 21]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-      organization                 O    2.5.6.4
-      organizationalPerson         O    2.5.6.7
-      organizationalRole           O    2.5.6.8
-      organizationalUnit           O    2.5.6.5
-      ou                           A    2.5.4.11
-      owner                        A    2.5.4.32
-      person                       O    2.5.6.6
-      physicalDeliveryOfficeName   A    2.5.4.19
-      postalAddress                A    2.5.4.16
-      postalCode                   A    2.5.4.17
-      postOfficeBox                A    2.5.4.18
-      preferredDeliveryMethod      A    2.5.4.28
-      registeredAddress            A    2.5.4.26
-      residentialPerson            O    2.5.6.10
-      roleOccupant                 A    2.5.4.33
-      searchGuide                  A    2.5.4.14
-      seeAlso                      A    2.5.4.34
-      serialNumber                 A    2.5.4.5
-      sn                           A    2.5.4.4
-      st                           A    2.5.4.8
-      street                       A    2.5.4.9
-      telephoneNumber              A    2.5.4.20
-      teletexTerminalIdentifier    A    2.5.4.22
-      telexNumber                  A    2.5.4.21
-      title                        A    2.5.4.12
-      uid                          A    0.9.2342.19200300.100.1.1
-      uniqueMember                 A    2.5.4.50
-      userPassword                 A    2.5.4.35
-      x121Address                  A    2.5.4.24
-      x500UniqueIdentifier         A    2.5.4.45
-
-
-5.  Security Considerations
-
-   Attributes of directory entries are used to provide descriptive 
-   information about the real-world objects they represent, which can be
-   people, organizations or devices.  Most countries have privacy laws 
-   regarding the publication of information about people.
-
-   Transfer of cleartext passwords is strongly discouraged where the 
-   underlying transport service cannot guarantee confidentiality and may
-   result in disclosure of the password to unauthorized parties.
-
-   Multiple attribute values for the userPassword needs to be used with 
-   care. Especially reset/deletion of a password by an admin without 
-   knowing the old user password gets tricky or impossible if multiple 
-   values for different applications are present. 
-
-   Certainly, applications which intend to replace the userPassword 
-   value(s) with new value(s) should use modify/replaceValues (or 
-   modify/deleteAttribute+addAttribute).  Additionally, server 
-
-
-
-Dally                   Expires December 2003                  [Page 22]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-   implementations are encouraged to provide administrative controls 
-   which, if enabled, restrict the userPassword attributer to one value.
-
-   Note that when used for authentication purposes [AuthMeth], the user 
-   need only prove knowledge of one of the values, not all of 
-   the values.
-
-
-6.  Acknowledgements
-
-   The definitions, on which this document is based, have been developed
-   by committees for telecommunications and international standards.  
-
-   This document is an update of RFC 2256 by Mark Wahl.  RFC 2256 was a
-   product of the IETF ASID Working Group.
-
-   The dc attribute type definition in this document supercedes the 
-   specification in RFC 2247 by S. Kille, M. Wahl, A. Grimstad, 
-   R. Huber, and S. Sataluri.
-
-   The uid attribute type definition in this document supercedes the 
-   specification of the userid in RFC 1274 by P. Barker and S. Kille 
-   and of the uid in RFC 2798 by M. Smith.
-
-   This document is based upon input of the IETF LDAPBIS working group.
-   The author wishes to thank S. Legg and K. Zeilenga for their 
-   significant contribution to this update.
-
-
-7.  References
-
-7.1  Normative
-
-   [E.123]  Notation for national and international telephone numbers, 
-            ITU-T Recommendation E.123, 1988
-
-   [E.164]  The international public telecommunication numbering plan, 
-            ITU-T Recommendation E.164, 1997
-
-   [ISO3166]  ISO 3166, "Codes for the representation of names of 
-              countries".
-
-   [Models]  K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
-             models-xx (a work in progress) 
-
-   [RFC1034]  P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND 
-              FACILITIES", RFC 1034, November 1987
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate 
-              Requirement Levels", RFC 2119, March 1997
-
-
-
-
-Dally                   Expires December 2003                  [Page 23]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-   [RFC3490]   Faltstrom P., Hoffman P., Costello A. "Internationalizing 
-   Domain Names in Applications (IDNA)", RFC 3490, March 2003
-
-...[ROADMAP]  Zeilenga, K., "LDAP:  Technical Specification Road Map", 
-              draft-ietf-ldapbis-roadmap-xx (a work in progress)
-
-   [Syntaxes]  S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
-               syntaxes-xx (a work in progress)
-
-   [X.121]  International numbering plan for public data networks, 
-            ITU-T Recommendation X.121, 1996
-
-   [X.509]  The Directory:  Authentication Framework, ITU-T 
-            Recommendation X.509, 1993
-
-   [X.520]  The Directory: Selected Attribute Types, ITU-T 
-            Recommendation X.520, 1993
-
-   [X.521]  The Directory: Selected Object Classes.  ITU-T 
-            Recommendation X.521, 1993
-
-7.2  Informative
-
-   [AUTHMETH]  Harrison R., "LDAP: Authentication Methods and 
-               Connection Level Security Mechanisms", draft-ietf-
-               ldapbis-authmeth-xx (a work in progress)
-
-   [F.1]  Operational Provisions For The International Public Telegram 
-   Service Transmission System, CCITT Recommmendation F.1, 1992
-
-   [F.31]  Telegram Retransmission System, CCITT Recommendation 
-           F.31, 1988
-
-   [LDAP-PKI]  Chadwick, D. W., Legg S., "LDAP Schema and Syntaxes for 
-               PKIs", draft-ietf-pkix-ldap-pki-schema-xx (a work in 
-               progress)
-
-   [RFC2247]  Kille, S., Wahl, M., Grimstad, A., Huber, R., and 
-              Sataluri, S., "Using Domains in LDAP/X.500 Distinguished 
-              Names", RFC 2247, January 1998
-
-   [RFC3377]  Hodges, J., Morgan, R., "Lightweight Directory Access 
-              Protocol (v3):  Technical Specification", RFC 3377, 
-              September 2002
-
-   [SASLprep]  Zeilenga K., "SASLprep: Stringprep profile for user 
-               names and passwords", draft-ietf-sasl-saslprep-xx (a 
-               work in progress)
-
-   [X.500]  The Directory, ITU-T Recommendations X.501-X.525, 1993
-
-
-
-
-Dally                   Expires December 2003                  [Page 24]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-8.  Author's Address
-
-   Kathy Dally
-   The MITRE Corp.
-   7515 Colshire Dr., H300
-   McLean VA 22102
-   USA
-   
-   Phone:  +1 703 883 6058
-   Email:  kdally@mitre.org
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dally                   Expires December 2003                  [Page 25]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-                          Appendix A  Changes RFC 2256
-
-   This appendix lists the changes that have been made from RFC 2256 to 
-   this I-D.  
-
-      1.  Replaced the document title.
-
-      2.  Removed the IESG Note.
-
-      3.  Dependencies on RFC 1274 have been eliminated.
-
-      4.  Added a Security Considerations section.
-
-      5.  Deleted the conformance requirement for subschema object 
-          classes in favor of a statement in [Syntaxes].
-
-      6.  Added explanations to many attribute types and to each object 
-          class.  
-
-      7.  Removed Section 4, Syntaxes, and Section 6, Matching Rules, 
-          (moved to [Syntaxes]).
-
-      8.  Removed the certificate-related attribute types:  
-             authorityRevocationList, 
-             cACertificate, 
-             certificateRevocationList, 
-             crossCertificatePair, 
-             deltaRevocationList, 
-             supportedAlgorithms, and 
-             userCertificate.
-
-          Removed the certificate-related Object Classes:  
-             certificationAuthority,
-             certificationAuthority-V2,
-             cRLDistributionPoint,
-             strongAuthenticationUser, and
-             userSecurityInformation
-
-          LDAP PKI is now discussed in [LDAP-PKI].
-
-      9.  Removed the dmdName, knowledgeInformation, 
-          presentationAddress, protocolInformation, and 
-          supportedApplicationContext attribute types and the dmd, 
-          applicationEntity, and dSA object classes. 
-
-      10. Deleted the aliasedObjectName and objectClass attribute 
-          type definitions.   Deleted the alias and top object class 
-          definitions.  They are included in [Models].
-
-      11. Added the 'dc' attribute type from RFC 2247.
-
-
-
-
-Dally                   Expires December 2003                  [Page 26]
-INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-06           June 2003
-
-
-      12. Added an IANA Considerations section.
-
-      13. Numerous edititorial changes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dally                   Expires December 2003                  [Page 27]
diff --git a/doc/drafts/draft-legg-ldapext-component-matching-xx.txt b/doc/drafts/draft-legg-ldapext-component-matching-xx.txt
deleted file mode 100644 (file)
index 0825eb9..0000000
+++ /dev/null
@@ -1,2355 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                                   S. Legg
-draft-legg-ldapext-component-matching-10.txt         Adacel Technologies
-Intended Category: Standard Track                          April 2, 2003
-
-
-                 LDAP & X.500 Component Matching Rules
-
-    Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-   Status of this Memo
-
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress".
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Distribution of this document is unlimited.  Comments should be sent
-   to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
-   or to the author.
-
-   This Internet-Draft expires on 2 October 2003.
-
-
-Abstract
-
-   The syntaxes of attributes in a Lightweight Directory Access Protocol
-   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.  The
-   matching rules defined for the complex syntaxes, if any, 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
-
-
-
-Legg                     Expires 2 October 2003                 [Page 1]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   complex attribute syntax.
-
-
-1. Table of Contents
-
-   1. Table of Contents .............................................  2
-   2. Introduction ..................................................  2
-   3. Conventions ...................................................  4
-   4. ComponentAssertion ............................................  5
-      4.1 Component Reference .......................................  5
-         4.1.1 Component Type Substitutions .........................  7
-         4.1.2 Referencing SET, SEQUENCE and CHOICE Components ......  8
-         4.1.3 Referencing SET OF and SEQUENCE OF Components ........  9
-         4.1.4 Referencing Components of Parameterized Types ........ 10
-         4.1.5 Component Referencing Example ........................ 10
-         4.1.6 Referencing Components of Open Types ................. 11
-            4.1.6.1 Open Type Referencing Example ................... 12
-         4.1.7 Referencing Contained Types .......................... 13
-            4.1.7.1 Contained Type Referencing Example .............. 14
-      4.2 Matching of Components .................................... 15
-         4.2.1 Applicability of Existing Matching Rules ............. 16
-            4.2.1.1 String Matching ................................. 16
-            4.2.1.2 Telephone Number Matching ....................... 17
-            4.2.1.3 Distinguished Name Matching ..................... 17
-         4.2.2 Additional Useful Matching Rules ..................... 17
-            4.2.2.1 The rdnMatch Matching Rule ...................... 17
-            4.2.2.2 The presentMatch Matching Rule .................. 18
-         4.2.3 Summary of Useful Matching Rules ..................... 19
-   5. ComponentFilter ............................................... 21
-   6. The componentFilterMatch Matching Rule ........................ 22
-   7. Equality Matching of Complex Components ....................... 23
-      7.1 The OpenAssertionType Syntax .............................. 24
-      7.2 The allComponentsMatch Matching Rule ...................... 25
-      7.3 Deriving Component Equality Matching Rules ................ 27
-      7.4 The directoryComponentsMatch Matching Rule ................ 28
-   8. Component Matching Examples ................................... 29
-   9. Security Considerations ....................................... 36
-   10. Acknowledgements ............................................. 37
-   11. Normative References ......................................... 37
-   12. Informative References ....................................... 38
-   13. Copyright Notice ............................................. 38
-   14. Author's Address ............................................. 39
-
-
-2. Introduction
-
-   The structure or data type of data held in an attribute of an LDAP
-   [RFC3377] or X.500 [18] directory is described by the attribute's
-
-
-
-Legg                     Expires 2 October 2003                 [Page 2]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   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 ASN.1
-   [11] type definitions.  ASN.1 type notation has a number of simple
-   data types (e.g. PrintableString, INTEGER, BOOLEAN), and combining
-   types (i.e. SET, SEQUENCE, SET OF, SEQUENCE OF, and CHOICE) for
-   constructing arbitrarily complex data types from simpler component
-   types.  In LDAP, the attribute syntaxes are usually described by ABNF
-   [2] though there is an implied association between the LDAP attribute
-   syntaxes and the X.500 ASN.1 types.  To a large extent, the data
-   types of attribute values in either an LDAP or X.500 directory are
-   described by ASN.1 types.  This formal description can be exploited
-   to identify component parts of an attribute value for a variety of
-   purposes.  This document addresses attribute value matching.
-
-   With any complex attribute syntax there is normally a requirement to
-   partially match an attribute value of that syntax by matching only
-   selected components of the value.  Typically, matching rules specific
-   to the attribute syntax are defined to fill this need.  These highly
-   specific matching rules usually only provide the most immediately
-   useful matching capability.  Some complex attribute syntaxes don't
-   even have an equality matching rule let alone any additional matching
-   rules for partial matching.  This document defines a generic way of
-   matching user selected components in an attribute value of any
-   arbitrarily complex attribute syntax, where that syntax is described
-   using ASN.1 type notation.  All of the type notations defined in [11]
-   are supported.
-
-   Section 4 describes the ComponentAssertion, a testable assertion
-   about the value of a component of an attribute value of any complex
-   syntax.
-
-   Section 5 introduces the ComponentFilter assertion, which is an
-   expression of ComponentAssertions.  The ComponentFilter enables more
-   powerful filter matching of components in an attribute value.
-
-   Section 6 defines the componentFilterMatch matching rule, which
-   enables a ComponentFilter to be evaluated against attribute values.
-
-   Section 7 defines matching rules for component-wise equality matching
-   of attribute values of any syntax described by an ASN.1 type
-   definition.
-
-   Examples showing the usage of componentFilterMatch are in Section 8.
-
-   For a new attribute syntax, the Generic String Encoding Rules [7] and
-
-
-
-Legg                     Expires 2 October 2003                 [Page 3]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   the specifications in sections 4 to 7 of this document make it
-   possible to fully and precisely define, the LDAP-specific encoding,
-   the LDAP and X.500 binary encoding (and possibly other encodings in
-   the future, e.g. XML via XER), a suitable equality matching rule, and
-   a comprehensive collection of component matching capabilities, by
-   simply writing down an ASN.1 type definition for the syntax.  These
-   implicit definitions are also automatically extended if the ASN.1
-   type is later extended.  The algorithmic relationship between the
-   ASN.1 type definition, the various encodings and the component
-   matching behaviour makes directory server implementation support for
-   the component matching rules amenable to automatic code generation
-   from ASN.1 type definitions.
-
-   Schema designers have the choice of storing related items of data as
-   a single attribute value of a complex syntax in some entry, or as a
-   subordinate entry where the related data items are stored as separate
-   attribute values of simpler syntaxes.  The inability to search
-   component parts of a complex syntax has been used as an argument for
-   favouring the subordinate entries approach.  The component matching
-   rules provide the analogous matching capability on an attribute value
-   of a complex syntax that a search filter has on a subordinate entry.
-
-   Most LDAP syntaxes have corresponding ASN.1 type definitions, though
-   they are usually not reproduced or referenced alongside the formal
-   definition of the LDAP syntax.  Syntaxes defined with only a
-   character string encoding, i.e. without an explicit or implied
-   corresponding ASN.1 type definition, cannot use the component
-   matching capabilities described in this document unless and until a
-   semantically equivalent ASN.1 type definition is defined for them.
-
-
-3. Conventions
-
-   Throughout this document "type" shall be taken to mean an ASN.1 type
-   unless explicitly qualified as an attribute type, and "value" shall
-   be taken to mean an ASN.1 value unless explicitly qualified as an
-   attribute value.
-
-   Note that "ASN.1 value" does not mean a BER [16] encoded value.  The
-   ASN.1 value is an abstract concept that is independent of any
-   particular encoding.  BER is just one possible encoding of an ASN.1
-   value.  The component matching rules operate at the abstract level
-   without regard for the possible encodings of a value.
-
-   Attribute type and matching rule definitions in this document are
-   provided in both the X.500 [8] and LDAP [4] description formats. Note
-   that the LDAP descriptions have been rendered with additional
-   white-space and line breaks for the sake of readability.
-
-
-
-Legg                     Expires 2 October 2003                 [Page 4]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-
-4. ComponentAssertion
-
-   A ComponentAssertion is an assertion about the presence, or values
-   of, components within an ASN.1 value, i.e. an instance of an ASN.1
-   type.  The ASN.1 value is typically an attribute value, where the
-   ASN.1 type is the syntax of the attribute.  However a
-   ComponentAssertion may also be applied to a component part of an
-   attribute value.  The assertion evaluates to either TRUE, FALSE or
-   undefined for each tested ASN.1 value.
-
-   A ComponentAssertion is described by the following ASN.1 type
-   (assumed to be defined with "EXPLICIT TAGS" in force):
-
-      ComponentAssertion ::= SEQUENCE {
-          component         ComponentReference (SIZE(1..MAX)) OPTIONAL,
-          useDefaultValues  BOOLEAN DEFAULT TRUE,
-          rule              MATCHING-RULE.&id,
-          value             MATCHING-RULE.&AssertionType }
-
-      ComponentReference ::= UTF8String
-
-   MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
-   rule.  MATCHING-RULE.&AssertionType is an open type (formally known
-   as the ANY type).
-
-   The "component" field of a ComponentAssertion identifies which
-   component part of a value of some ASN.1 type is to be tested, the
-   "useDefaultValues" field indicates whether DEFAULT values are to be
-   substituted for absent component values, the "rule" field indicates
-   how the component is to be tested, and the "value" field is an
-   asserted ASN.1 value against which the component is tested.  The
-   ASN.1 type of the asserted value is determined by the chosen rule.
-
-   The fields of a ComponentAssertion are described in detail in the
-   following sections.
-
-
-4.1 Component Reference
-
-   The component field in a ComponentAssertion is a UTF8 character
-   string [6] whose textual content is a component reference,
-   identifying a component part of some ASN.1 type or value.  A
-   component reference conforms to the following ABNF [2], which extends
-
-
-
-Legg                     Expires 2 October 2003                 [Page 5]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   the notation defined in Clause 14 of [11]:
-
-      component-reference = ComponentId *( "." ComponentId )
-      ComponentId         = identifier /
-                            from-beginning /
-                            count /
-                            from-end /       ; extends Clause 14
-                            content /        ; extends Clause 14
-                            select /         ; extends Clause 14
-                            all
-
-      identifier          = lowercase *alphanumeric
-                               *(hyphen 1*alphanumeric)
-      alphanumeric        = uppercase / lowercase / decimal-digit
-      uppercase           = %x41-5A  ; "A" to "Z"
-      lowercase           = %x61-7A  ; "a" to "z"
-      hyphen              = "-"
-
-      from-beginning      = positive-number
-      count               = "0"
-      from-end            = "-" positive-number
-      content             = %x63.6F.6E.74.65.6E.74 ; "content"
-      select              = "(" Value *( "," Value ) ")"
-      all                 = "*"
-
-
-      positive-number     = non-zero-digit *decimal-digit
-
-      decimal-digit       = %x30-39  ; "0" to "9"
-      non-zero-digit      = %x31-39  ; "1" to "9"
-
-   An <identifier> conforms to the definition of an identifier in ASN.1
-   notation (Clause 11.3 of [11]).  It begins with a lowercase letter
-   and is followed by zero or more letters, digits, and hyphens.  A
-   hyphen is not permitted to be the last character and a hyphen is not
-   permitted to be followed by another hyphen.
-
-   The <Value> rule is described in [7].
-
-   A component reference is a sequence of one or more ComponentIds where
-   each successive ComponentId identifies either an inner component at
-   the next level of nesting of an ASN.1 combining type, i.e. SET,
-   SEQUENCE, SET OF, SEQUENCE OF, or CHOICE, or a specific type within
-   an ASN.1 open type.
-
-   A component reference is always considered in the context of a
-   particular complex ASN.1 type.  When applied to the ASN.1 type the
-   component reference identifies a specific component type.  When
-
-
-
-Legg                     Expires 2 October 2003                 [Page 6]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   applied to a value of the ASN.1 type a component reference identifies
-   zero, one or more component values of that component type.  The
-   component values are potentially in a DEFAULT value if
-   useDefaultValues is TRUE.  The specific component type identified by
-   the component reference determines what matching rules are capable of
-   being used to match the component values.
-
-   The component field in a ComponentAssertion may also be absent, in
-   which case the identified component type is the ASN.1 type to which
-   the ComponentAssertion is applied, and the identified component value
-   is the whole ASN.1 value.
-
-   A valid component reference for a particular complex ASN.1 type is
-   constructed by starting with the outermost combining type and
-   repeatedly selecting one of the permissible forms of ComponentId to
-   identify successively deeper nested components.  A component
-   reference MAY identify a component with a complex ASN.1 type, i.e. it
-   is NOT required that the component type identified by a component
-   reference be a simple ASN.1 type.
-
-
-4.1.1 Component Type Substitutions
-
-   ASN.1 type notation has a number of constructs for referencing other
-   defined types, and constructs that are irrelevant for matching
-   purposes.  These constructs are not represented in a component
-   reference in any way and substitutions of the component type are
-   performed to eliminate them from further consideration.  These
-   substitutions automatically occur prior to each ComponentId, whether
-   constructing or interpreting a component reference, but do not occur
-   after the last ComponentId, except as allowed by Section 4.2.
-
-   If the ASN.1 type is an ASN.1 type reference then the component type
-   is taken to be the actual definition on the right hand side of the
-   type assignment for the referenced type.
-
-   If the ASN.1 type is a tagged type then the component type is taken
-   to be the type without the tag.
-
-   If the ASN.1 type is a constrained type (see [11] and [14] for the
-   details of ASN.1 constraint notation) then the component type is
-   taken to be the type without the constraint.
-
-   If the ASN.1 type is an ObjectClassFieldType (Clause 14 of [13]) that
-   denotes a specific ASN.1 type (e.g. MATCHING-RULE.&id denotes the
-   OBJECT IDENTIFIER type) then the component type is taken to be the
-   denoted type.  Section 4.1.6 describes the case where the
-   ObjectClassFieldType denotes an open type.
-
-
-
-Legg                     Expires 2 October 2003                 [Page 7]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   If the ASN.1 type is a selection type other than one used in the list
-   of components for a SET or SEQUENCE type then the component type is
-   taken to be the selected alternative type from the named CHOICE.
-
-   If the ASN.1 type is a TypeFromObject (Clause 15 of [13]) then the
-   component type is taken to be the denoted type.
-
-   If the ASN.1 type is a ValueSetFromObjects (Clause 15 of [13]) then
-   the component type is taken to be the governing type of the denoted
-   values.
-
-
-4.1.2 Referencing SET, SEQUENCE and CHOICE Components
-
-   If the ASN.1 type is a SET or SEQUENCE type then the <identifier>
-   form of ComponentId MAY be used to identify the component type within
-   that SET or SEQUENCE having that identifier.  If <identifier>
-   references an OPTIONAL component type and that component is not
-   present in a particular value then there are no corresponding
-   component values.  If <identifier> references a DEFAULT component
-   type and useDefaultValues is TRUE (the default setting for
-   useDefaultValues) and that component is not present in a particular
-   value then the component value is taken to be the default value.  If
-   <identifier> references a DEFAULT component type and useDefaultValues
-   is FALSE and that component is not present in a particular value then
-   there are no corresponding component values.
-
-   If the ASN.1 type is a CHOICE type then the <identifier> form of
-   ComponentId MAY be used to identify the alternative type within that
-   CHOICE having that identifier.  If <identifier> references an
-   alternative other than the one used in a particular value then there
-   are no corresponding component values.
-
-   The COMPONENTS OF notation in Clause 24 of [11] augments the defined
-   list of components in a SET or SEQUENCE type by including all the
-   components of another defined SET or SEQUENCE type respectively.
-   These included components are referenced directly by identifier as
-   though they were defined in-line in the SET or SEQUENCE type
-   containing the COMPONENTS OF notation.
-
-   The SelectionType (Clause 29 of [11]), when used in the list of
-   components for a SET or SEQUENCE type, includes a single component
-   from a defined CHOICE type.  This included component is referenced
-   directly by identifier as though it was defined in-line in the SET or
-   SEQUENCE type.
-
-   The REAL type is treated as though it is the SEQUENCE type defined in
-   Clause 20.5 of [11].
-
-
-
-Legg                     Expires 2 October 2003                 [Page 8]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   The EMBEDDED PDV type is treated as though it is the SEQUENCE type
-   defined in Clause 32.5 of [11].
-
-   The EXTERNAL type is treated as though it is the SEQUENCE type
-   defined in Clause 8.18.1 of [16].
-
-   The unrestricted CHARACTER STRING type is treated as though it is the
-   SEQUENCE type defined in Clause 39.5 of [11].
-
-   The INSTANCE OF type is treated as though it is the SEQUENCE type
-   defined in Annex C of [13].
-
-   The <identifier> form MUST NOT be used on any other ASN.1 type.
-
-
-4.1.3 Referencing SET OF and SEQUENCE OF Components
-
-   If the ASN.1 type is a SET OF or SEQUENCE OF type then the
-   <from-beginning>, <from-end>, <count> and <all> forms of ComponentId
-   MAY be used.
-
-   The <from-beginning> form of ComponentId MAY be used to identify one
-   instance (i.e. value) of the component type of the SET OF or SEQUENCE
-   OF type (e.g. if Foo ::= SET OF Bar, then Bar is the component type),
-   where the instances are numbered from one upwards.  If
-   <from-beginning> references a higher numbered instance than the last
-   instance in a particular value of the SET OF or SEQUENCE OF type then
-   there is no corresponding component value.
-
-   The <from-end> form of ComponentId MAY be used to identify one
-   instance of the component type of the SET OF or SEQUENCE OF type,
-   where "-1" is the last instance, "-2" is the second last instance,
-   and so on.  If <from-end> references a lower numbered instance than
-   the first instance in a particular value of the SET OF or SEQUENCE OF
-   type then there is no corresponding component value.
-
-   The <count> form of ComponentId identifies a notional count of the
-   number of instances of the component type in a value of the SET OF or
-   SEQUENCE OF type.  This count is not explicitly represented but for
-   matching purposes it has an assumed ASN.1 type of INTEGER (0..MAX).
-   A ComponentId of the <count> form, if used, MUST be the last
-   ComponentId in a component reference.
-
-   The <all> form of ComponentId MAY be used to simultaneously identify
-   all instances of the component type of the SET OF or SEQUENCE OF
-   type.  It is through the <all> form that a component reference can
-   identify more than one component value.  However, if a particular
-   value of the SET OF or SEQUENCE OF type is an empty list there are no
-
-
-
-Legg                     Expires 2 October 2003                 [Page 9]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   corresponding component values.
-
-   Where multiple component values are identified, the remaining
-   ComponentIds in the component reference, if any, can identify zero,
-   one or more subcomponent values for each of the higher level
-   component values.
-
-   The corresponding ASN.1 type for the <from-beginning>, <from-end>,
-   and <all> forms of ComponentId is the component type of the SET OF or
-   SEQUENCE OF type.
-
-   The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be
-   used on ASN.1 types other than SET OF or SEQUENCE OF.
-
-
-4.1.4 Referencing Components of Parameterized Types
-
-   A component reference cannot be formed for a parameterized type
-   unless the type has been used with actual parameters, in which case
-   the type is treated as though the DummyReferences [15] have been
-   substituted with the actual parameters.
-
-
-4.1.5 Component Referencing Example
-
-   Consider the following ASN.1 type definitions.
-
-      ExampleType ::= SEQUENCE {
-          part1       [0] INTEGER,
-          part2       [1] ExampleSet,
-          part3       [2] SET OF OBJECT IDENTIFIER,
-          part4       [3] ExampleChoice }
-
-      ExampleSet ::= SET {
-          option      PrintableString,
-          setting     BOOLEAN }
-
-      ExampleChoice ::= CHOICE {
-          eeny-meeny  BIT STRING,
-          miney-mo    OCTET STRING }
-
-   Following are component references constructed with respect to the
-   type ExampleType.
-
-   The component reference "part1" identifies a component of a value of
-   ExampleType having the ASN.1 tagged type [0] INTEGER.
-
-   The component reference "part2" identifies a component of a value of
-
-
-
-Legg                     Expires 2 October 2003                [Page 10]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   ExampleType having the ASN.1 type of [1] ExampleSet
-
-   The component reference "part2.option" identifies a component of a
-   value of ExampleType having the ASN.1 type of PrintableString.  A
-   ComponentAssertion could also be applied to a value of ASN.1 type
-   ExampleSet, in which case the component reference "option" would
-   identify the same kind of information.
-
-   The component reference "part3" identifies a component of a value of
-   ExampleType having the ASN.1 type of [2] SET OF OBJECT IDENTIFIER.
-
-   The component reference "part3.2" identifies the second instance of
-   the part3 SET OF.  The instance has the ASN.1 type of OBJECT
-   IDENTIFIER.
-
-   The component reference "part3.0" identifies the count of the number
-   of instances in the part3 SET OF.  The count has the corresponding
-   ASN.1 type of INTEGER (0..MAX).
-
-   The component reference "part3.*" identifies all the instances in the
-   part3 SET OF.  Each instance has the ASN.1 type of OBJECT IDENTIFIER.
-
-   The component reference "part4" identifies a component of a value of
-   ExampleType having the ASN.1 type of [3] ExampleChoice.
-
-   The component reference "part4.miney-mo" identifies a component of a
-   value of ExampleType having the ASN.1 type of OCTET STRING.
-
-
-4.1.6 Referencing Components of Open Types
-
-   If a sequence of ComponentIds identifies an ObjectClassFieldType
-   denoting an open type (e.g. ATTRIBUTE.&Type denotes an open type)
-   then the ASN.1 type of the component varies.  An open type is
-   typically constrained by some other component(s) in an outer
-   enclosing type, either formally through the use of a component
-   relation constraint [14], or informally in the accompanying text, so
-   the actual ASN.1 type of a value of the open type will generally be
-   known.  The constraint will also limit the range of permissible
-   types.  The <select> form of ComponentId MAY be used to identify one
-   of these permissible types in an open type.  Subcomponents of that
-   type can then be identified with further ComponentIds.
-
-   The other components constraining the open type are termed the
-   referenced components (using the terminology in [14]).  The <select>
-   form contains a list of one or more values which take the place of
-   the value(s) of the referenced component(s) to uniquely identify one
-   of the permissable types of the open type.
-
-
-
-Legg                     Expires 2 October 2003                [Page 11]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   Where the open type is constrained by a component relation
-   constraint, there is a <Value> in the <select> form for each of the
-   referenced components in the component relation constraint, appearing
-   in the same order.  The ASN.1 type of each of these values is the
-   same as the ASN.1 type of the corresponding referenced component.
-   The type of a referenced component is potentially any ASN.1 type
-   however it is typically an OBJECT IDENTIFIER or INTEGER, which means
-   that the <Value> in the <select> form of ComponentId will nearly
-   always be an <ObjectIdentifierValue> or <IntegerValue> (see [7]).
-   Furthermore, component relation constraints typically have only one
-   referenced component.
-
-   Where the open type is not constrained by a component relation
-   constraint, the specification introducing the syntax containing the
-   open type SHOULD explicitly nominate the referenced components and
-   their order, so that the <select> form can be used.
-
-   If an instance of <select> contains a value other than the value of
-   the referenced component used in a particular value of the outer
-   enclosing type then there are no corresponding component values for
-   the open type.
-
-
-4.1.6.1 Open Type Referencing Example
-
-   The ASN.1 type AttributeTypeAndValue from [8] describes a single
-   attribute value of a nominated attribute type.
-
-      AttributeTypeAndValue ::= SEQUENCE {
-          type    ATTRIBUTE.&id ({SupportedAttributes}),
-          value   ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
-
-   ATTRIBUTE.&id denotes an OBJECT IDENTIFIER and
-   ({SupportedAttributes}) constrains the OBJECT IDENTIFIER to be a
-   supported attribute type.
-
-   ATTRIBUTE.&Type denotes an open type, in this case an attribute
-   value, and ({SupportedAttributes}{@type}) is a component relation
-   constraint that constrains the open type to be of the attribute
-   syntax for the attribute type.  The component relation constraint
-   references only the "type" component, which has the ASN.1 type of
-   OBJECT IDENTIFIER, thus if the <select> form of ComponentId is used
-   to identify attribute values of specific attribute types it will
-   contain a single OBJECT IDENTIFIER value.
-
-   The component reference "value" on AttributeTypeAndValue refers to
-   the open type.
-
-
-
-
-Legg                     Expires 2 October 2003                [Page 12]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   One of the X.500 standard attributes is facsimileTelephoneNumber
-   [10], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is
-   defined to have the following syntax.
-
-      FacsimileTelephoneNumber ::= SEQUENCE {
-          telephoneNumber PrintableString(SIZE(1..ub-telephone-number)),
-          parameters      G3FacsimileNonBasicParameters OPTIONAL }
-
-   The component reference "value.(2.5.4.23)" on AttributeTypeAndValue
-   specifies an attribute value with the FacsimileTelephoneNumber
-   syntax.
-
-   The component reference "value.(2.5.4.23).telephoneNumber" on
-   AttributeTypeAndValue identifies the telephoneNumber component of a
-   facsimileTelephoneNumber attribute value.  The component reference
-   "value.(facsimileTelephoneNumber)" is equivalent to
-   "value.(2.5.4.23)".
-
-   If the AttributeTypeAndValue ASN.1 value contains an attribute type
-   other than facsimileTelephoneNumber then there are no corresponding
-   component values for the component references "value.(2.5.4.23)" and
-   "value.(2.5.4.23).telephoneNumber".
-
-
-4.1.7 Referencing Contained Types
-
-   Sometimes the contents of a BIT STRING or OCTET STRING value are
-   required to be the encodings of other ASN.1 values of specific ASN.1
-   types.  For example, the extnValue component of the Extension type
-   component in the Certificate type [9] is an OCTET STRING that is
-   required to contain a DER encoding of a certificate extension value.
-   It is useful to be able to refer to the embedded encoded value and
-   its components.  An embedded encoded value is here referred to as a
-   contained value and its associated type as the contained type.
-
-   If the ASN.1 type is a BIT STRING or OCTET STRING type containing
-   encodings of other ASN.1 values then the <content> form of
-   ComponentId MAY be used to identify the contained type.
-   Subcomponents of that type can then be identified with further
-   ComponentIds.
-
-   The contained type may be (effectively) an open type, constrained by
-   some other component in an outer enclosing type (e.g. in a
-   certificate Extension, extnValue is constrained by the chosen
-   extnId).  In these cases the next ComponentId, if any, MUST be of the
-   <select> form.
-
-   For the purpose of building component references, the content of the
-
-
-
-Legg                     Expires 2 October 2003                [Page 13]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   extnValue OCTET STRING in the Extension type is assumed to be an open
-   type having a notional component relation constraint with the extnId
-   component as the single referenced component, i.e.
-
-      EXTENSION.&ExtnType ({ExtensionSet}{@extnId})
-
-   The data-value component of the associated types for the EMBEDDED PDV
-   and CHARACTER STRING types is an OCTET STRING containing the encoding
-   of a data value described by the identification component.  For the
-   purpose of building component references, the content of the
-   data-value OCTET STRING in these types is assumed to be an open type
-   having a notional component relation constraint with the
-   identification component as the single referenced component.
-
-
-4.1.7.1 Contained Type Referencing Example
-
-   The Extension ASN.1 type from [9] describes a single certificate
-   extension value of a nominated extension type.
-
-      Extension ::= SEQUENCE {
-          extnId     EXTENSION.&id ({ExtensionSet}),
-          critical   BOOLEAN DEFAULT FALSE,
-          extnValue  OCTET STRING
-              -- contains a DER encoding of a value of type &ExtnType
-              -- for the extension object identified by extnId -- }
-
-   EXTENSION.&id denotes an OBJECT IDENTIFIER and ({ExtensionSet})
-   constrains the OBJECT IDENTIFIER to be the identifier of a supported
-   certificate extension.
-
-   The component reference "extnValue" on Extension refers to a
-   component type of OCTET STRING.  The corresponding component values
-   will be OCTET STRING values.  The component reference
-   "extnValue.content" on Extension refers to the type of the contained
-   type, which in this case is an open type.
-
-   One of the X.509 [X.509] standard extensions is basicConstraints,
-   which is identified with the OBJECT IDENTIFIER 2.5.29.19 and is
-   defined to have the following syntax.
-
-      BasicConstraintsSyntax ::= SEQUENCE {
-          cA                 BOOLEAN DEFAULT FALSE,
-          pathLenConstraint  INTEGER (0..MAX) OPTIONAL }
-
-   The component reference "extnValue.content.(2.5.29.19)" on Extension
-   specifies a BasicConstraintsSyntax extension value and the component
-   reference "extnValue.content.(2.5.29.19).cA" identifies the cA
-
-
-
-Legg                     Expires 2 October 2003                [Page 14]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   component of a BasicConstraintsSyntax extension value.
-
-
-4.2 Matching of Components
-
-   The rule in a ComponentAssertion specifies how the zero, one or more
-   component values identified by the component reference are tested by
-   the assertion.  Attribute matching rules are used to specify the
-   semantics of the test.
-
-   Each matching rule has a notional set of attribute syntaxes
-   (typically one), defined as ASN.1 types, to which it may be applied.
-   When used in a ComponentAssertion these matching rules apply to the
-   same ASN.1 types, only in this context the corresponding ASN.1 values
-   are not necessarily complete attribute values.
-
-   Note that the referenced component type may be a tagged and/or
-   constrained version of the expected attribute syntax (e.g. [0]
-   INTEGER, whereas integerMatch would expect simply INTEGER), or an
-   open type.  Additional type substitutions of the kind described in
-   Section 4.1.1 are performed as required to reduce the component type
-   to the same type as the attribute syntax expected by the matching
-   rule.
-
-   If a matching rule applies to more than one attribute syntax (e.g.
-   objectIdentifierFirstComponentMatch [10]) then the minimum number of
-   substitutions required to conform to any one of those syntaxes is
-   performed.  If a matching rule can apply to any attribute syntax
-   (e.g. the allComponentsMatch rule defined in Section 7.2) then the
-   referenced component type is used as is, with no additional
-   substitutions.
-
-   The value in a ComponentAssertion will be of the assertion syntax
-   (i.e. ASN.1 type) required by the chosen matching rule.  Note that
-   the assertion syntax of a matching rule is not necessarily the same
-   as the attribute syntax(es) to which the rule may be applied.
-
-   Some matching rules do not have a fixed assertion syntax (e.g.
-   allComponentsMatch).  The required assertion syntax is determined in
-   each instance of use by the syntax of the attribute type to which the
-   matching rule is applied.  For these rules the ASN.1 type of the
-   referenced component is used in place of an attribute syntax to
-   decide the required assertion syntax.
-
-   The ComponentAssertion is undefined if:
-
-   a) the matching rule in the ComponentAssertion is not known to the
-      evaluating procedure,
-
-
-
-Legg                     Expires 2 October 2003                [Page 15]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   b) if the matching rule is not applicable to the referenced component
-      type, even with the additional type substitutions,
-
-   c) the value in the ComponentAssertion does not conform to the
-      assertion syntax defined for the matching rule,
-
-   d) some part of the component reference identifies an open type in
-      the tested value that cannot be decoded, or
-
-   e) the implementation does not support the particular combination of
-      component reference and matching rule.
-
-   If the ComponentAssertion is not undefined then the
-   ComponentAssertion evaluates to TRUE if there is at least one
-   component value for which the matching rule applied to that component
-   value returns TRUE, and evaluates to FALSE otherwise (which includes
-   the case where there are no component values).
-
-
-4.2.1 Applicability of Existing Matching Rules
-
-4.2.1.1 String Matching
-
-   ASN.1 has a number of built in restricted character string types with
-   different character sets and/or different character encodings.  A
-   directory user generally has little interest in the particular
-   character set or encoding used to represent a character string
-   component value, and some directory server implementations make no
-   distinction between the different string types in their internal
-   representation of values.  So rather than define string matching
-   rules for each of the restricted character string types, the existing
-   case ignore and case exact string matching rules are extended to
-   apply to component values of any of the restricted character string
-   types and any ChoiceOfStrings type [7], in addition to component
-   values of the DirectoryString type.  This extension is only for the
-   purposes of component matching described in this document.
-
-   The relevant string matching rules are: caseIgnoreMatch,
-   caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch,
-   caseExactOrderingMatch and caseExactSubstringsMatch.  The relevant
-   restricted character string types are: NumericString,
-   PrintableString, VisibleString, IA5String, UTF8String, BMPString,
-   UniversalString, TeletexString, VideotexString, GraphicString and
-   GeneralString.  A ChoiceOfStrings type is a purely syntactic CHOICE
-   of these ASN.1 string types.  Note that [7] declares each and every
-   use of the DirectoryString{} parameterized type to be a
-   ChoiceOfStrings type.
-
-
-
-
-Legg                     Expires 2 October 2003                [Page 16]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   The assertion syntax of the string matching rules is still
-   DirectoryString regardless of the string syntax of the component
-   being matched.  Thus an implementation will be called upon to compare
-   a DirectoryString value to a value of one of the restricted character
-   string types, or a ChoiceOfStrings type.  As is the case when
-   comparing two DirectoryStrings where the chosen alternatives are of
-   different string types, the comparison proceeds so long as the
-   corresponding characters are representable in both character sets.
-   Otherwise matching returns FALSE.
-
-
-4.2.1.2 Telephone Number Matching
-
-   Early editions of X.520 [10] gave the syntax of the telephoneNumber
-   attribute as a constrained PrintableString.  The fourth edition of
-   X.520 equates the ASN.1 type name TelephoneNumber to the constrained
-   PrintableString and uses TelephoneNumber as the attribute and
-   assertion syntax.  For the purposes of component matching,
-   telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted
-   to be applied to any PrintableString value, as well as to
-   TelephoneNumber values.
-
-
-4.2.1.3 Distinguished Name Matching
-
-   The DistinguishedName type is defined by assignment to be the same as
-   the RDNSequence type, however RDNSequence is sometimes directly used
-   in other type definitions.  For the purposes of component matching,
-   distinguishedNameMatch is also permitted to be applied to values of
-   the RDNSequence type.
-
-
-4.2.2 Additional Useful Matching Rules
-
-   This section defines additional matching rules that may prove useful
-   in ComponentAssertions.  These rules MAY also be used in
-   extensibleMatch search filters [3].
-
-
-4.2.2.1 The rdnMatch Matching Rule
-
-   The distinguishedNameMatch matching rule can match whole
-   distinguished names but it is sometimes useful to be able to match
-   specific RDNs in a DN without regard for the other RDNs in the DN.
-   The rdnMatch matching rule allows component RDNs of a DN to be
-   tested.
-
-   The LDAP-style definitions for rdnMatch and its assertion syntax are:
-
-
-
-Legg                     Expires 2 October 2003                [Page 17]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-      ( 1.2.36.79672281.1.13.3 NAME 'rdnMatch'
-          SYNTAX 1.2.36.79672281.1.5.0 )
-
-      ( 1.2.36.79672281.1.5.0 DESC 'RDN' )
-
-   The LDAP-specific encoding for a value of the RDN syntax is given by
-   the <RelativeDistinguishedNameValue> rule in [7].
-
-   The X.500-style definition for rdnMatch is:
-
-      rdnMatch MATCHING-RULE ::= {
-          SYNTAX  RelativeDistinguishedName
-          ID      { 1 2 36 79672281 1 13 3 } }
-
-   The rdnMatch rule evaluates to true if the component value and
-   assertion value are the same RDN, using the same RDN comparison
-   method as distinguishedNameMatch.
-
-   When using rdnMatch to match components of DNs it is important to
-   note that the LDAP-specific encoding of a DN [5] reverses the order
-   of the RDNs.  So for the DN represented in LDAP as "cn=Steven
-   Legg,o=Adacel,c=AU", the RDN "cn=Steven Legg" corresponds to the
-   component reference "3", or alternatively, "-1".
-
-
-4.2.2.2 The presentMatch Matching Rule
-
-   At times it would be useful to test not if a specific value of a
-   particular component is present, but whether any value of a
-   particular component is present.  The presentMatch matching rule
-   allows the presence of a particular component value to be tested.
-
-   The LDAP-style definitions for presentMatch and its assertion syntax
-   are:
-
-      ( 1.2.36.79672281.1.13.5 NAME 'presentMatch'
-          SYNTAX 1.2.36.79672281.1.5.1 )
-
-      ( 1.2.36.79672281.1.5.1 DESC 'NULL' )
-
-   The LDAP-specific encoding for a value of the NULL syntax is given by
-   the <NullValue> rule in [7].
-
-   The X.500-style definition for presentMatch is:
-
-      presentMatch MATCHING-RULE ::= {
-          SYNTAX  NULL
-          ID      { 1 2 36 79672281 1 13 5 } }
-
-
-
-Legg                     Expires 2 October 2003                [Page 18]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   When used in a extensible match filter item, presentMatch behaves
-   like the "present" case of a regular search filter.  In a
-   ComponentAssertion, presentMatch evaluates to TRUE if and only if the
-   component reference identifies one or more component values,
-   regardless of the actual component value contents.  Note that if
-   useDefaultValues is TRUE then the identified component values may be
-   (part of) a DEFAULT value.
-
-   The notional count referenced by the <count> form of ComponentId is
-   taken to be present if the SET OF value is present, and absent
-   otherwise.  Note that in ASN.1 notation an absent SET OF value is
-   distinctly different from a SET OF value that is present but empty.
-   It is up to the specification using the ASN.1 notation to decide
-   whether the distinction matters.  Often an empty SET OF component and
-   an absent SET OF component are treated as semantically equivalent.
-   If a SET OF value is present, but empty, a presentMatch on the SET OF
-   component SHALL return TRUE and the notional count SHALL be regarded
-   as present and equal to zero.
-
-
-4.2.3 Summary of Useful Matching Rules
-
-   The following is a non-exhaustive list of useful matching rules and
-   the ASN.1 types to which they can be applied, taking account of all
-   the extensions described in Section 4.2.1, and the new matching rules
-   defined in Section 4.2.2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg                     Expires 2 October 2003                [Page 19]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-      +================================+==============================+
-      | Matching Rule                  | ASN.1 Type                   |
-      +================================+==============================+
-      | bitStringMatch                 | BIT STRING                   |
-      +--------------------------------+------------------------------+
-      | booleanMatch                   | BOOLEAN                      |
-      +--------------------------------+------------------------------+
-      | caseIgnoreMatch                | NumericString                |
-      | caseIgnoreOrderingMatch        | PrintableString              |
-      | caseIgnoreSubstringsMatch      | VisibleString (ISO646String) |
-      | caseExactMatch                 | IA5String                    |
-      | caseExactOrderingMatch         | UTF8String                   |
-      | caseExactSubstringsMatch       | BMPString (UCS-2, UNICODE)   |
-      |                                | UniversalString (UCS-4)      |
-      |                                | TeletexString (T61String)    |
-      |                                | VideotexString               |
-      |                                | GraphicString                |
-      |                                | GeneralString                |
-      |                                | any ChoiceOfStrings type     |
-      +--------------------------------+------------------------------+
-      | caseIgnoreIA5Match             | IA5String                    |
-      | caseExactIA5Match              |                              |
-      +--------------------------------+------------------------------+
-      | distinguishedNameMatch         | DistinguishedName            |
-      |                                | RDNSequence                  |
-      +--------------------------------+------------------------------+
-      | generalizedTimeMatch           | GeneralizedTime              |
-      | generalizedTimeOrderingMatch   |                              |
-      +--------------------------------+------------------------------+
-      | integerMatch                   | INTEGER                      |
-      | integerOrderingMatch           |                              |
-      +--------------------------------+------------------------------+
-      | numericStringMatch             | NumericString                |
-      | numericStringOrderingMatch     |                              |
-      | numericStringSubstringsMatch   |                              |
-      +--------------------------------+------------------------------+
-      | objectIdentifierMatch          | OBJECT IDENTIFIER            |
-      +--------------------------------+------------------------------+
-      | octetStringMatch               | OCTET STRING                 |
-      | octetStringOrderingMatch       |                              |
-      | octetStringSubstringsMatch     |                              |
-      +--------------------------------+------------------------------+
-      | presentMatch                   | any ASN.1 type               |
-      +--------------------------------+------------------------------+
-      | rdnMatch                       | RelativeDistinguishedName    |
-      +--------------------------------+------------------------------+
-      | telephoneNumberMatch           | PrintableString              |
-      | telephoneNumberSubstringsMatch | TelephoneNumber              |
-
-
-
-Legg                     Expires 2 October 2003                [Page 20]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-      +--------------------------------+------------------------------+
-      | uTCTimeMatch                   | UTCTime                      |
-      | uTCTimeOrderingMatch           |                              |
-      +--------------------------------+------------------------------+
-
-   Note that the allComponentsMatch matching rule defined in Section 7.2
-   can be used for equality matching of values of the ENUMERATED, NULL,
-   REAL and RELATIVE-OID ASN.1 types, among other things.
-
-
-5. ComponentFilter
-
-   The ComponentAssertion allows the value(s) of any one component type
-   in a complex ASN.1 type to be matched, but there is often a desire to
-   match the values of more than one component type.  A ComponentFilter
-   is an assertion about the presence, or values of, multiple components
-   within an ASN.1 value.
-
-   The ComponentFilter assertion, an expression of ComponentAssertions,
-   evaluates to either TRUE, FALSE or undefined for each tested ASN.1
-   value.
-
-   A ComponentFilter is described by the following ASN.1 type (assumed
-   to be defined with "EXPLICIT TAGS" in force):
-
-      ComponentFilter ::= CHOICE {
-          item  [0] ComponentAssertion,
-          and   [1] SEQUENCE OF ComponentFilter,
-          or    [2] SEQUENCE OF ComponentFilter,
-          not   [3] ComponentFilter }
-
-   Note: despite the use of SEQUENCE OF instead of SET OF for the "and"
-   and "or" alternatives in ComponentFilter, the order of the component
-   filters is not significant.
-
-   A ComponentFilter that is a ComponentAssertion evaluates to TRUE if
-   the ComponentAssertion is TRUE, evaluates to FALSE if the
-   ComponentAssertion is FALSE, and evaluates to undefined otherwise.
-
-   The "and" of a sequence of component filters evaluates to TRUE if the
-   sequence is empty or if each component filter evaluates to TRUE,
-   evaluates to FALSE if at least one component filter is FALSE, and
-   evaluates to undefined otherwise.
-
-   The "or" of a sequence of component filters evaluates to FALSE if the
-   sequence is empty or if each component filter evaluates to FALSE,
-   evaluates to TRUE if at least one component filter is TRUE, and
-   evaluates to undefined otherwise.
-
-
-
-Legg                     Expires 2 October 2003                [Page 21]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   The "not" of a component filter evaluates to TRUE if the component
-   filter is FALSE, evaluates to FALSE if the component filter is TRUE,
-   and evaluates to undefined otherwise.
-
-
-6. The componentFilterMatch Matching Rule
-
-   The componentFilterMatch matching rule allows a ComponentFilter to be
-   applied to an attribute value.  The result of the matching rule is
-   the result of applying the ComponentFilter to the attribute value.
-
-   The LDAP-style definitions for componentFilterMatch and its assertion
-   syntax are:
-
-      ( 1.2.36.79672281.1.13.2 NAME 'componentFilterMatch'
-          SYNTAX 1.2.36.79672281.1.5.2 )
-
-      ( 1.2.36.79672281.1.5.2 DESC 'ComponentFilter' )
-
-   The LDAP-specific encoding for the ComponentFilter assertion syntax
-   is specified by the Generic String Encoding Rules in [7].
-
-   As a convenience to implementors, an equivalent ABNF description of
-   the GSER encoding for ComponentFilter is provided here.  In the event
-   that there is a discrepancy between this ABNF and the encoding
-   determined by [7], [7] is to be taken as definitive.  The GSER
-   encoding of a ComponentFilter is described by the following
-   equivalent ABNF:
-
-      ComponentFilter = filter-item /
-                        and-filter /
-                        or-filter /
-                        not-filter
-
-      filter-item     = item-chosen ComponentAssertion
-      and-filter      = and-chosen  SequenceOfComponentFilter
-      or-filter       = or-chosen   SequenceOfComponentFilter
-      not-filter      = not-chosen  ComponentFilter
-
-      item-chosen     = %x69.74.65.6D.3A  ; "item:"
-      and-chosen      = %x61.6E.64.3A     ; "and:"
-      or-chosen       = %x6F.72.3A        ; "or:"
-      not-chosen      = %x6E.6F.74.3A     ; "not:"
-
-      SequenceOfComponentFilter = "{" [ sp ComponentFilter
-                                     *( "," sp ComponentFilter) ] sp "}"
-
-      ComponentAssertion = "{" [ sp component "," ]
-
-
-
-Legg                     Expires 2 October 2003                [Page 22]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-                               [ sp useDefaultValues "," ]
-                                 sp rule ","
-                                 sp assertion-value sp "}"
-      component          = component-label msp StringValue
-      useDefaultValues   = use-defaults-label msp BooleanValue
-      rule               = rule-label msp ObjectIdentifierValue
-      assertion-value    = value-label msp Value
-
-      component-label    = %x63.6F.6D.70.6F.6E.65.6E.74  ; "component"
-      use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75
-                           %x65.73                  ; "useDefaultValues"
-      rule-label         = %x72.75.6C.65            ; "rule"
-      value-label        = %x76.61.6C.75.65         ; "value"
-
-      sp                 =  *%x20  ; zero, one or more space characters
-      msp                = 1*%x20  ; one or more space characters
-
-   The ABNF for <Value>, <StringValue>, <ObjectIdentifierValue> and
-   <BooleanValue> is defined in [7].
-
-   The ABNF descriptions of LDAP-specific encodings for attribute
-   syntaxes typically do not clearly or consistently delineate the
-   component parts of an attribute value.  A regular and uniform
-   character string encoding for arbitrary component data types is
-   needed to encode the assertion value in a ComponentAssertion.  The
-   <Value> rule from [7] provides a human readable text encoding for a
-   component value of any arbitrary ASN.1 type.
-
-   The X.500-style definition [8] for componentFilterMatch is:
-
-      componentFilterMatch MATCHING-RULE ::= {
-          SYNTAX  ComponentFilter
-          ID      { 1 2 36 79672281 1 13 2 } }
-
-   A ComponentAssertion can potentially use any matching rule, including
-   componentFilterMatch, so componentFilterMatch MAY be nested.  The
-   component references in a nested componentFilterMatch are relative to
-   the component corresponding to the containing ComponentAssertion.  In
-   Section 8, an example search on the seeAlso attribute shows this
-   usage.
-
-
-7. Equality Matching of Complex Components
-
-   It is possible to test if an attribute value of a complex ASN.1
-   syntax is the same as some purported (i.e. assertion) value by using
-   a complicated ComponentFilter that tests if corresponding components
-   are the same.  However, it would be more convenient to be able to
-
-
-
-Legg                     Expires 2 October 2003                [Page 23]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   present a whole assertion value to a matching rule that could do the
-   component-wise comparison of an attribute value with the assertion
-   value for any arbitrary attribute syntax.  Similarly, the ability to
-   do a straightforward equality comparison of a component value that is
-   itself of a complex ASN.1 type would also be convenient.
-
-   It would be difficult to define a single matching rule that
-   simultaneously satisfies all notions of what the equality matching
-   semantics should be.  For example, in some instances a case sensitive
-   comparison of string components may be preferable to a case
-   insensitive comparison.  Therefore a basic equality matching rule,
-   allComponentsMatch, is defined in Section 7.2, and the means to
-   derive new matching rules from it with slightly different equality
-   matching semantics are described in Section 7.3.
-
-   The directoryComponentsMatch defined in Section 7.4 is a derivation
-   of allComponentsMatch that suits typical uses of the directory.
-   Other specifications are free to derive new rules from
-   allComponentsMatch or directoryComponentsMatch, that suit their usage
-   of the directory.
-
-   The allComponentsMatch rule, the directoryComponentsMatch rule and
-   any matching rules derived from them are collectively called
-   component equality matching rules.
-
-
-7.1 The OpenAssertionType Syntax
-
-   The component equality matching rules have a variable assertion
-   syntax.  In X.500 this is indicated by omitting the optional SYNTAX
-   field in the MATCHING-RULE information object.  The assertion syntax
-   then defaults to the target attribute's syntax in actual usage,
-   unless the description of the matching rule says otherwise.  The
-   SYNTAX field in the LDAP-specific encoding of a
-   MatchingRuleDescription is mandatory, so the OpenAssertionType syntax
-   is defined to fill the same role.  That is, the OpenAssertionType
-   syntax is semantically equivalent to an omitted SYNTAX field in an
-   X.500 MATCHING-RULE information object.  OpenAssertionType MUST NOT
-   be used as the attribute syntax in an attribute type definition.
-
-   Unless explicitly varied by the description of a particular matching
-   rule, if an OpenAssertionType assertion value appears in a
-   ComponentAssertion its LDAP-specific encoding is described by the
-   <Value> rule in [7], otherwise its LDAP-specific encoding is the
-   encoding defined for the syntax of the attribute type to which the
-   matching rule with the OpenAssertionType assertion syntax is applied.
-
-   The LDAP definition for the OpenAssertionType syntax is:
-
-
-
-Legg                     Expires 2 October 2003                [Page 24]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-      ( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )
-
-
-7.2 The allComponentsMatch Matching Rule
-
-   The LDAP-style definition for allComponentsMatch is:
-
-      ( 1.2.36.79672281.1.13.6 NAME 'allComponentsMatch'
-          SYNTAX 1.2.36.79672281.1.5.3 )
-
-   The X.500-style definition for allComponentsMatch is:
-
-      allComponentsMatch MATCHING-RULE ::= {
-          ID      { 1 2 36 79672281 1 13 6 } }
-
-   When allComponentsMatch is used in a ComponentAssertion the assertion
-   syntax is the same as the ASN.1 type of the identified component.
-   Otherwise, the assertion syntax of allComponentsMatch is the same as
-   the attribute syntax of the attribute to which the matching rule is
-   applied.
-
-   Broadly speaking, this matching rule evaluates to true if and only if
-   corresponding components of the assertion value and the attribute or
-   component value are the same.
-
-   In detail, equality is determined by the following cases applied
-   recursively.
-
-   a) Two values of a SET or SEQUENCE type are the same if and only if,
-      for each component type, the corresponding component values are
-      either,
-
-      1) both absent,
-
-      2) both present and the same, or
-
-      3) absent or the same as the DEFAULT value for the component, if a
-         DEFAULT value is defined.
-
-      Values of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER
-      STRING, or INSTANCE OF type are compared according to their
-      respective associated SEQUENCE type (see Section 4.1.2).
-
-   b) Two values of a SEQUENCE OF type are the same if and only if, the
-      values have the same number of (possibly duplicated) instances and
-      corresponding instances are the same.
-
-   c) Two values of a SET OF type are the same if and only if, the
-
-
-
-Legg                     Expires 2 October 2003                [Page 25]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-      values have the same number of instances and each distinct
-      instance occurs in both values the same number of times, i.e. both
-      values have the same instances, including duplicates, but in any
-      order.
-
-   d) Two values of a CHOICE type are the same if and only if, both
-      values are of the same chosen alternative and the component values
-      are the same.
-
-   e) Two BIT STRING values are the same if and only if the values have
-      the same number of bits and corresponding bits are the same.  If
-      the BIT STRING type is defined with a named bit list then trailing
-      zero bits in the values are treated as absent for the purposes of
-      this comparison.
-
-   f) Two BOOLEAN values are the same if and only if both are TRUE or
-      both are FALSE.
-
-   g) Two values of a string type are the same if and only if the values
-      have the same number of characters and corresponding characters
-      are the same.  Letter case is significant.  For the purposes of
-      allComponentsMatch, the string types are NumericString,
-      PrintableString, TeletexString (T61String), VideotexString,
-      IA5String, GraphicString, VisibleString (ISO646String),
-      GeneralString, UniversalString, BMPString, UTF8String,
-      GeneralizedTime, UTCTime and ObjectDescriptor.
-
-   h) Two INTEGER values are the same if and only if the integers are
-      equal.
-
-   i) Two ENUMERATED values are the same if and only if the enumeration
-      item identifiers are the same (equivalently, if the integer values
-      associated with the identifiers are equal).
-
-   j) Two NULL values are always the same, unconditionally.
-
-   k) Two OBJECT IDENTIFIER values are the same if and only if the
-      values have the same number of arcs and corresponding arcs are the
-      same.
-
-   l) Two OCTET STRING values are the same if and only if the values
-      have the same number of octets and corresponding octets are the
-      same.
-
-   m) Two REAL values are the same if and only if they are both the same
-      special value, or neither is a special value and they have the
-      same base and represent the same real number.  The special values
-      for REAL are zero, PLUS-INFINITY and MINUS-INFINITY.
-
-
-
-Legg                     Expires 2 October 2003                [Page 26]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   n) Two RELATIVE-OID [12] values are the same if and only if the
-      values have the same number of arcs and corresponding arcs are the
-      same.  The respective starting nodes for the RELATIVE-OID values
-      are disregarded in the comparison, i.e. they are assumed to be the
-      same.
-
-   o) Two values of an open type are the same if and only if both are of
-      the same ASN.1 type and are the same according to that type.  If
-      the actual ASN.1 type of the values is unknown then the
-      allComponentsMatch rule evaluates to undefined.
-
-   Tags and constraints, being part of the type definition and not part
-   of the abstract values, are ignored for matching purposes.
-
-   The allComponentsMatch rule MAY be used as the defined equality
-   matching rule for an attribute.
-
-
-7.3 Deriving Component Equality Matching Rules
-
-   A new component equality matching rule with more refined matching
-   semantics may be derived from allComponentsMatch, or any other
-   component equality matching rule, using the convention described in
-   this section.
-
-   The matching behaviour of a derived component equality matching rule
-   is specified by nominating, for each of one or more identified
-   components, a commutative equality matching rule that will be used to
-   match values of that component.  This overrides the matching that
-   would otherwise occur for values of that component using the base
-   rule for the derivation.  These overrides can be conveniently
-   represented as rows in a table of the following form.
-
-      Component   |  Matching Rule
-      ============+===============
-                  |
-                  |
-
-   Usually, all component values of a particular ASN.1 type are to be
-   matched the same way.  An ASN.1 type reference (e.g.
-   DistinguishedName) or an ASN.1 built-in type name (e.g. INTEGER) in
-   the Component column of the table specifies that the nominated
-   equality matching rule is to be applied to all values of the named
-   type, regardless of context.
-
-   An ASN.1 type reference with a component reference appended
-   (separated by a ".")  specifies that the nominated matching rule
-   applies only to the identified components of values of the named
-
-
-
-Legg                     Expires 2 October 2003                [Page 27]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   type.  Other component values that happen to be of the same ASN.1
-   type are not selected.
-
-   Additional type substitutions as described in Section 4.2 are assumed
-   to be performed to align the component type with the matching rule
-   assertion syntax.
-
-   Conceptually, the rows in a table for the base rule are appended to
-   the rows in the table for a derived rule for the purpose of deciding
-   the matching semantics of the derived rule.  Notionally,
-   allComponentsMatch has an empty table.
-
-   A row specifying values of an outer containing type (e.g.
-   DistinguishedName) takes precedence over a row specifying values of
-   an inner component type (e.g. RelativeDistinguishedName), regardless
-   of their order in the table.  Specifying a row for component values
-   of an inner type is only useful if a value of the type can also
-   appear on its own, or as a component of values of a different outer
-   type.  For example, if there is a row for DistinguishedName then a
-   row for RelativeDistinguishedName can only ever apply to
-   RelativeDistinguishedName component values that are not part of a
-   DistinguishedName.  A row for values of an outer type in the table
-   for the base rule takes precedence over a row for values of an inner
-   type in the table for the derived rule.
-
-   Where more than one row applies to a particular component value the
-   earlier row takes precedence over the later row.  Thus rows in the
-   table for the derived rule take precedence over any rows for the same
-   component in the table for the base rule.
-
-
-7.4 The directoryComponentsMatch Matching Rule
-
-   The directoryComponentsMatch matching rule is derived from the
-   allComponentsMatch matching rule.
-
-   The LDAP-style definition for directoryComponentsMatch is:
-
-      ( 1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch'
-          SYNTAX 1.2.36.79672281.1.5.3 )
-
-   The X.500-style definition for directoryComponentsMatch is:
-
-      directoryComponentsMatch MATCHING-RULE ::= {
-          ID      { 1 2 36 79672281 1 13 7 } }
-
-   The matching semantics of directoryComponentsMatch are described by
-   the following table, using the convention described in Section 7.3.
-
-
-
-Legg                     Expires 2 October 2003                [Page 28]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-      ASN.1 Type                               | Matching Rule
-      =========================================+========================
-      RDNSequence                              | distinguishedNameMatch
-      RelativeDistinguishedName                | rdnMatch
-      TelephoneNumber                          | telephoneNumberMatch
-      FacsimileTelephoneNumber.telephoneNumber | telephoneNumberMatch
-      NumericString                            | numericStringMatch
-      GeneralizedTime                          | generalizedTimeMatch
-      UTCTime                                  | uTCTimeMatch
-      DirectoryString{}                        | caseIgnoreMatch
-      BMPString                                | caseIgnoreMatch
-      GeneralString                            | caseIgnoreMatch
-      GraphicString                            | caseIgnoreMatch
-      IA5String                                | caseIgnoreMatch
-      PrintableString                          | caseIgnoreMatch
-      TeletexString                            | caseIgnoreMatch
-      UniversalString                          | caseIgnoreMatch
-      UTF8String                               | caseIgnoreMatch
-      VideotexString                           | caseIgnoreMatch
-      VisibleString                            | caseIgnoreMatch
-
-   Notes.
-
-   1) The DistinguishedName type is defined by assignment to be the same
-      as the RDNSequence type.  Some types (e.g. Name and LocalName)
-      directly reference RDNSequence rather than DistinguishedName.
-      Specifying RDNSequence captures all these DN-like types.
-
-   2) A RelativeDistinguishedName value is only matched by rdnMatch if
-      it is not part of an RDNSequence value.
-
-   3) The telephone number component of the FacsimileTelephoneNumber
-      ASN.1 type [10] is defined as a constrained PrintableString.
-      PrintableString component values that are part of a
-      FacsimileTelephoneNumber value can be identified separately from
-      other components of PrintableString type by the specifier
-      FacsimileTelephoneNumber.telephoneNumber, so that
-      telephoneNumberMatch can be selectively applied.  The fourth
-      edition of X.520 defines the telephoneNumber component of
-      FacsimileTelephoneNumber to be of the type TelephoneNumber, making
-      the row for FacsimileTelephoneNumber.telephoneNumber components
-      redundant.
-
-   The directoryComponentsMatch rule MAY be used as the defined equality
-   matching rule for an attribute.
-
-
-8. Component Matching Examples
-
-
-
-Legg                     Expires 2 October 2003                [Page 29]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   This section contains examples of search filters using the
-   componentFilterMatch matching rule.  The filters are described using
-   the string representation of LDAP search filters from [17].  Note
-   that [17] requires asterisks to be escaped in assertion values (in
-   these examples the assertion values are all <ComponentAssertion>
-   encodings).  The asterisks have not been escaped in these examples
-   for the sake of clarity, and to avoid confusing the LDAP protocol
-   representation of search filter assertion values, where such escaping
-   does not apply.  Line breaks and indenting have been added only as an
-   aid to readability.
-
-   The example search filters are all single extensible match filter
-   items, though there is no reason why componentFilterMatch can't be
-   used in more complicated search filters.
-
-   The first examples describe searches over the objectClasses schema
-   operational attribute, which has an attribute syntax described by the
-   ASN.1 type ObjectClassDescription [8], and holds the definitions of
-   the object classes known to a directory server.  The definition of
-   ObjectClassDescription is as follows:
-
-      ObjectClassDescription ::= SEQUENCE {
-          identifier       OBJECT-CLASS.&id,
-          name             SET OF DirectoryString {ub-schema} OPTIONAL,
-          description      DirectoryString {ub-schema} OPTIONAL,
-          obsolete         BOOLEAN DEFAULT FALSE,
-          information  [0] ObjectClassInformation }
-
-      ObjectClassInformation ::= SEQUENCE {
-          subclassOf       SET OF OBJECT-CLASS.&id OPTIONAL,
-          kind             ObjectClassKind DEFAULT structural,
-          mandatories  [3] SET OF ATTRIBUTE.&id OPTIONAL,
-          optionals    [4] SET OF ATTRIBUTE.&id OPTIONAL }
-
-      ObjectClassKind ::= ENUMERATED {
-          abstract     (0),
-          structural   (1),
-          auxiliary    (2) }
-
-   OBJECT-CLASS.&id and ATTRIBUTE.&id are equivalent to the OBJECT
-   IDENTIFIER ASN.1 type.  A value of OBJECT-CLASS.&id is an OBJECT
-   IDENTIFIER for an object class.  A value of ATTRIBUTE.&id is an
-   OBJECT IDENTIFIER for an attribute type.
-
-   The following search filter finds the object class definition for the
-   object class identified by the OBJECT IDENTIFIER 2.5.6.18:
-
-      (objectClasses:componentFilterMatch:=
-
-
-
-Legg                     Expires 2 October 2003                [Page 30]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-          item:{ component "identifier",
-                 rule objectIdentifierMatch, value 2.5.6.18 })
-
-   A match on the "identifier" component of objectClasses values is
-   equivalent to the objectIdentifierFirstComponentMatch matching rule
-   applied to attribute values of the objectClasses attribute type.  The
-   componentFilterMatch matching rule subsumes the functionality of the
-   objectIdentifierFirstComponentMatch, integerFirstComponentMatch and
-   directoryStringFirstComponentMatch matching rules.
-
-   The following search filter finds the object class definition for the
-   object class called foobar:
-
-      (objectClasses:componentFilterMatch:=
-          item:{ component "name.*",
-                 rule caseIgnoreMatch, value "foobar" })
-
-   An object class definition can have multiple names and the above
-   filter will match an objectClasses value if any one of the names is
-   "foobar".
-
-   The component reference "name.0" identifies the notional count of the
-   number of names in an object class definition.  The following search
-   filter finds object class definitions with exactly one name:
-
-      (objectClasses:componentFilterMatch:=
-          item:{ component "name.0", rule integerMatch, value 1 })
-
-   The "description" component of an ObjectClassDescription is defined
-   to be an OPTIONAL DirectoryString.  The following search filter finds
-   object class definitions that have descriptions, regardless of the
-   contents of the description string:
-
-      (objectClasses:componentFilterMatch:=
-          item:{ component "description",
-                 rule presentMatch, value NULL })
-
-   The presentMatch returns TRUE if the description component is present
-   and FALSE otherwise.
-
-   The following search filter finds object class definitions that don't
-   have descriptions:
-
-      (objectClasses:componentFilterMatch:=
-          not:item:{ component "description",
-                     rule presentMatch, value NULL })
-
-   The following search filter finds object class definitions with the
-
-
-
-Legg                     Expires 2 October 2003                [Page 31]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   word "bogus" in the description:
-
-      (objectClasses:componentFilterMatch:=
-          item:{ component "description",
-                 rule caseIgnoreSubstringsMatch,
-                 value { any:"bogus" } })
-
-   The assertion value is of the SubstringAssertion syntax, i.e.
-
-      SubstringAssertion ::= SEQUENCE OF CHOICE {
-          initial      [0] DirectoryString {ub-match},
-          any          [1] DirectoryString {ub-match},
-          final        [2] DirectoryString {ub-match} }
-
-   The "obsolete" component of an ObjectClassDescription is defined to
-   be DEFAULT FALSE.  An object class is obsolete if the "obsolete"
-   component is present and set to TRUE.  The following search filter
-   finds all obsolete object classes:
-
-      (objectClasses:componentFilterMatch:=
-          item:{ component "obsolete", rule booleanMatch, value TRUE })
-
-   An object class is not obsolete if the "obsolete" component is not
-   present, in which case it defaults to FALSE, or is present but is
-   explicitly set to FALSE.  The following search filter finds all non-
-   obsolete object classes:
-
-      (objectClasses:componentFilterMatch:=
-          item:{ component "obsolete", rule booleanMatch, value FALSE })
-
-   The useDefaultValues flag in the ComponentAssertion defaults to TRUE
-   so the componentFilterMatch rule treats an absent "obsolete"
-   component as being present and set to FALSE.  The following search
-   filter finds only object class definitions where the "obsolete"
-   component has been explicitly set to FALSE, rather than implicitly
-   defaulting to FALSE:
-
-      (objectClasses:componentFilterMatch:=
-          item:{ component "obsolete", useDefaultValues FALSE,
-                 rule booleanMatch, value FALSE })
-
-   With the useDefaultValues flag set to FALSE, if the "obsolete"
-   component is absent the component reference identifies no component
-   value and the matching rule will return FALSE.  The matching rule can
-   only return TRUE if the component is present and set to FALSE.
-
-   The "information.kind" component of the ObjectClassDescription is an
-   ENUMERATED type.  The allComponentsMatch matching rule can be used to
-
-
-
-Legg                     Expires 2 October 2003                [Page 32]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   match values of an ENUMERATED type.  The following search filter
-   finds object class definitions for auxiliary object classes:
-
-      (objectClasses:componentFilterMatch:=
-          item:{ component "information.kind",
-                 rule allComponentsMatch, value auxiliary })
-
-   The following search filter finds auxiliary object classes with
-   commonName (cn or 2.5.4.3) as a mandatory attribute:
-
-      (objectClasses:componentFilterMatch:=and:{
-          item:{ component "information.kind",
-                 rule allComponentsMatch, value auxiliary },
-          item:{ component "information.mandatories.*",
-                 rule objectIdentifierMatch, value cn } })
-
-   The following search filter finds auxiliary object classes with
-   commonName as a mandatory or optional attribute:
-
-      (objectClasses:componentFilterMatch:=and:{
-          item:{ component "information.kind",
-                 rule allComponentsMatch, value auxiliary },
-          or:{
-              item:{ component "information.mandatories.*",
-                     rule objectIdentifierMatch, value cn },
-              item:{ component "information.optionals.*",
-                     rule objectIdentifierMatch, value cn } } })
-
-   Extra care is required when matching optional SEQUENCE OF or SET OF
-   components because of the distinction between an absent list of
-   instances and a present, but empty, list of instances.  The following
-   search filter finds object class definitions with less than three
-   names, including object class definitions with a present but empty
-   list of names, but does not find object class definitions with an
-   absent list of names:
-
-      (objectClasses:componentFilterMatch:=
-          item:{ component "name.0",
-                 rule integerOrderingMatch, value 3 })
-
-   If the "name" component is absent the "name.0" component is also
-   considered to be absent and the ComponentAssertion evaluates to
-   FALSE.  If the "name" component is present, but empty, the "name.0"
-   component is also present and equal to zero, so the
-   ComponentAssertion evaluates to TRUE.  To also find the object class
-   definitions with an absent list of names the following search filter
-   would be used:
-
-
-
-
-Legg                     Expires 2 October 2003                [Page 33]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-      (objectClasses:componentFilterMatch:=or:{
-          not:item:{ component "name", rule presentMatch, value NULL },
-          item:{ component "name.0",
-                 rule integerOrderingMatch, value 3 } })
-
-   Distinguished names embedded in other syntaxes can be matched with a
-   componentFilterMatch.  The uniqueMember attribute type has an
-   attribute syntax described by the ASN.1 type NameAndOptionalUID.
-
-      NameAndOptionalUID ::= SEQUENCE {
-          dn        DistinguishedName,
-          uid       UniqueIdentifier OPTIONAL }
-
-   The following search filter finds values of the uniqueMember
-   attribute containing the author's DN:
-
-      (uniqueMember:componentFilterMatch:=
-          item:{ component "dn",
-                 rule distinguishedNameMatch,
-                 value "cn=Steven Legg,o=Adacel,c=AU" })
-
-   The DistinguishedName and RelativeDistinguishedName ASN.1 types are
-   also complex ASN.1 types so the component matching rules can be
-   applied to their inner components.
-
-      DistinguishedName   ::= RDNSequence
-
-      RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-      RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
-          AttributeTypeAndValue
-
-      AttributeTypeAndValue ::= SEQUENCE {
-          type        AttributeType ({SupportedAttributes}),
-          value       AttributeValue ({SupportedAttributes}{@type}) }
-
-      AttributeType ::= ATTRIBUTE.&id
-
-      AttributeValue ::= ATTRIBUTE.&Type
-
-   ATTRIBUTE.&Type is an open type.  A value of ATTRIBUTE.&Type is
-   constrained by the type component of AttributeTypeAndValue to be of
-   the attribute syntax of the nominated attribute type.  Note: the
-   fourth edition of X.500 extends and renames the AttributeTypeAndValue
-   SEQUENCE type.
-
-   The seeAlso attribute has the DistinguishedName syntax.  The
-   following search filter finds seeAlso attribute values containing the
-
-
-
-Legg                     Expires 2 October 2003                [Page 34]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   RDN, "o=Adacel", anywhere in the DN:
-
-      (seeAlso:componentFilterMatch:=
-          item:{ component "*", rule rdnMatch, value "o=Adacel" })
-
-   The following search filter finds all seeAlso attribute values with
-   "cn=Steven Legg" as the RDN of the named entry (i.e. the "first" RDN
-   in an LDAPDN or the "last" RDN in an X.500 DN):
-
-      (seeAlso:componentFilterMatch:=
-          item:{ component "-1",
-                 rule rdnMatch, value "cn=Steven Legg" })
-
-   The following search filter finds all seeAlso attribute values naming
-   entries in the DIT subtree of "o=Adacel,c=AU":
-
-      (seeAlso:componentFilterMatch:=and:{
-          item:{ component "1", rule rdnMatch, value "c=AU" },
-          item:{ component "2", rule rdnMatch, value "o=Adacel" } })
-
-   The following search filter finds all seeAlso attribute values
-   containing the naming attribute types commonName (cn) and
-   telephoneNumber in the same RDN:
-
-      (seeAlso:componentFilterMatch:=
-          item:{ component "*", rule componentFilterMatch,
-                 value and:{
-                     item:{ component "*.type",
-                            rule objectIdentifierMatch, value cn },
-                     item:{ component "*.type",
-                            rule objectIdentifierMatch,
-                            value telephoneNumber } } })
-
-   The following search filter would find all seeAlso attribute values
-   containing the attribute types commonName and telephoneNumber, but
-   not necessarily in the same RDN:
-
-      (seeAlso:componentFilterMatch:=and:{
-          item:{ component "*.*.type",
-                 rule objectIdentifierMatch, value cn },
-          item:{ component "*.*.type",
-                 rule objectIdentifierMatch, value telephoneNumber } })
-
-   The following search filter finds all seeAlso attribute values
-   containing the word "Adacel" in any organizationalUnitName (ou)
-   attribute value in any AttributeTypeAndValue of any RDN:
-
-      (seeAlso:componentFilterMatch:=
-
-
-
-Legg                     Expires 2 October 2003                [Page 35]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-          item:{ component "*.*.value.(2.5.4.11)",
-                 rule caseIgnoreSubstringsMatch,
-                 value { any:"Adacel" } })
-
-   The component reference "*.*.value" identifies an open type, in this
-   case an attribute value.  In a particular AttributeTypeAndValue, if
-   the attribute type is not organizationalUnitName then the
-   ComponentAssertion evaluates to FALSE.  Otherwise the substring
-   assertion is evaluated against the attribute value.
-
-   Absent component references in ComponentAssertions can be exploited
-   to avoid false positive matches on multi-valued attributes.  For
-   example, suppose there is a multi-valued attribute named
-   productCodes, defined to have the Integer syntax
-   (1.3.6.1.4.1.1466.115.121.1.27).  Consider the following search
-   filter:
-
-      (&(!(productCodes:integerOrderingMatch:=3))
-        (productCodes:integerOrderingMatch:=8))
-
-   An entry whose productCodes attribute contains only the values 1 and
-   10 will match the above filter.  The first subfilter is satisfied by
-   the value 10 (10 is not less than 3), and the second subfilter is
-   satisfied by the value 1 (1 is less than 8).  The following search
-   filter can be used instead to only match entries that have a
-   productCodes value in the range 3 to 7, because the ComponentFilter
-   is evaluated against each productCodes value in isolation:
-
-      (productCodes:componentFilterMatch:= and:{
-           not:item:{ rule integerOrderingMatch, value 3 },
-          item:{ rule integerOrderingMatch, value 8 } })
-
-   An entry whose productCodes attribute contains only the values 1 and
-   10 will not match the above filter.
-
-
-9. Security Considerations
-
-   The component matching rules described in this document allow for a
-   compact specification of matching capabilities that could otherwise
-   have been defined by a plethora of specific matching rules, i.e.
-   despite their expressiveness and flexibility the component matching
-   rules do not behave in a way uncharacteristic of other matching
-   rules, so the security issues for component matching rules are no
-   different than for any other matching rule.  However, because the
-   component matching rules are applicable to any attribute syntax,
-   support for them in a directory server may allow searching of
-   attributes that were previously unsearchable by virtue of there not
-
-
-
-Legg                     Expires 2 October 2003                [Page 36]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   being a suitable matching rule.  Such attribute types ought to be
-   properly protected with appropriate access controls.
-
-
-10. Acknowledgements
-
-   The author would like to thank Tom Gindin for private email
-   discussions that clarified and refined the ideas presented in this
-   document.
-
-
-11. Normative References
-
-   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
-         Specifications: ABNF", RFC 2234, November 1997.
-
-   [3]   Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
-         Protocol (v3)", RFC 2251, December 1997.
-
-   [4]   Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
-         Directory Access Protocol (v3): Attribute Syntax Definitions",
-         RFC 2252, December 1997.
-
-   [5]   Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
-         Protocol (v3): UTF-8 String Representation of Distinguished
-         Names", RFC 2253, December 1997.
-
-   [6]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
-         2279, January 1998.
-
-   [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
-         Protocol (v3): Technical Specification", RFC 3377, September
-         2002.
-
-   [7]   Legg, S., "Generic String Encoding Rules for ASN.1 Types",
-         draft-legg-ldap-gser-xx.txt, a work in progress, October 2002.
-
-   [8]   ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
-         Information Technology - Open Systems Interconnection - The
-         Directory: Models
-
-   [9]   ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
-         Information Technology - Open Systems Interconnection - The
-         Directory: Authentication Framework
-
-
-
-
-Legg                     Expires 2 October 2003                [Page 37]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   [10]  ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
-         Information Technology - Open Systems Interconnection - The
-         Directory: Selected attribute types
-
-   [11]  ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
-         Information Technology - Abstract Syntax Notation One (ASN.1):
-         Specification of basic notation
-
-   [12]  ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC
-         8824-1:1998/Amd 1:2000 Relative object identifiers
-
-   [13]  ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998
-         Information Technology - Abstract Syntax Notation One (ASN.1):
-         Information object specification
-
-   [14]  ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998
-         Information Technology - Abstract Syntax Notation One (ASN.1):
-         Constraint specification
-
-   [15]  ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998
-         Information Technology - Abstract Syntax Notation One (ASN.1):
-         Parameterization of ASN.1 specifications
-
-   [16]  ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
-         Information Technology - ASN.1 encoding rules: Specification of
-         Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
-         Distinguished Encoding Rules (DER)
-
-
-12. Informative References
-
-   [17]  Howes, T., "The String Representation of LDAP Search Filters",
-         RFC 2254, December 1997.
-
-   [18]  ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
-         Information Technology - Open Systems Interconnection - The
-         Directory: Overview of concepts, models and services
-
-
-13. Copyright Notice
-
-      Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-
-
-
-Legg                     Expires 2 October 2003                [Page 38]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-14. Author's Address
-
-   Steven Legg
-   Adacel Technologies Ltd.
-   250 Bay Street
-   Brighton, Victoria 3186
-   AUSTRALIA
-
-   Phone: +61 3 8530 7710
-     Fax: +61 3 8530 7888
-   EMail: steven.legg@adacel.com.au
-
-
-Appendix A - Changes From Previous Drafts
-
-A.1 Changes in Draft 01
-
-   Section 4.1.7 was added to enable component matching of values
-   embedded in encoded form into BIT STRINGs or OCTET STRINGs.  In
-   particular, this is to allow component matching of values in
-   Certificate extensions.  The <content> rule was added in Section 4.1
-   to allow the OCTET STRING contents to be treated as either raw octets
-   or as an embedded value.
-
-   References to a companion document summarizing the ASN.1 types of
-   LDAP syntaxes were removed to avoid holding up this document.
-
-   The OpenType syntax was renamed to OpenAssertionType.
-
-
-
-Legg                     Expires 2 October 2003                [Page 39]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   Object identifiers for the new syntax and matching rule definitions
-   have been allocated from an arc belonging to Adacel Technologies Ltd.
-
-A.2 Changes in Draft 02
-
-   The context specific tagging in the ComponentAssertion ASN.1 type was
-   unnecessary and has been removed.
-
-   The encoding of OpenAssertionType assertion values outside of
-   ComponentAssertions has been clarified, and the description of
-   OpenAssertionType has been promoted to its own section.
-
-A.3 Changes in Draft 03
-
-   The default matching by allComponentsMatch of component values of BIT
-   STRING types with named bit lists has been changed to ignore trailing
-   zero bits.
-
-   Typographical errors in the <SafeUTF8Character> rule have been fixed.
-
-A.4 Changes in Draft 04
-
-   When the matching rule in a ComponentAssertion has a variable
-   assertion syntax it is not possible to determine the syntax of the
-   value component from the ComponentAssertion alone when the associated
-   component reference has referenced through an open type.  Deducing
-   what that syntax should be from inspection of the other
-   ComponentAssertions in a ComponentFilter is difficult to implement in
-   any comprehensive way.  The <select> form of ComponentId has been
-   introduced so that the syntax can always be determined from the
-   contents of the ComponentAssertion alone.  This not only simplifies
-   implementation but can lead to simpler ComponentFilters since there
-   is no longer a requirement to test that the components constraining
-   an open type have particular values.  The open type referencing
-   example has been changed accordingly.  The contained type referencing
-   example has also been changed because it is an example of a contained
-   open type.
-
-   The presentationAddressMatch rule is not commutative so it has been
-   removed from the table defining directoryComponentsMatch. The default
-   behaviour of allComponentsMatch is already a suitable commutative
-   substitute for matching PresentationAddress values.
-
-   The null character has been included in the range of legal characters
-   for <SafeUTF8Character>.
-
-   The ASN.1 type of the notional iteration count associated with SET OF
-   and SEQUENCE OF values has been refined to INTEGER (0..MAX).
-
-
-
-Legg                     Expires 2 October 2003                [Page 40]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-   The encoding rules in Section 8 (now draft-legg-ldap-gser-xx.txt)
-   have been formally named the Generic String Encoding Rules (GSER) and
-   a transfer syntax object identifier has been assigned.
-
-   The term "LDAP string encoding" has been replaced by the term "native
-   LDAP-specific encoding" to align with terminology anticipated to be
-   used in the revision of RFC 2252.
-
-A.5 Changes in Draft 05
-
-   Reformatted the draft to conform to recent and proposed RFC editorial
-   policy.
-
-   The use of the <oid> rule from RFC 2252 has been replaced by a local
-   definition to specifically outlaw leading zero characters in OBJECT
-   IDENTIFIER components.
-
-   Provisions for the RELATIVE-OID ASN.1 type defined in Amendment 1 to
-   X.680 have been added.
-
-   The comparison of REAL values has been clarified and the GSER
-   encoding of REAL values has been extended.
-
-   Removed extraneous spaces from example DNs.
-
-A.6 Changes in Draft 06
-
-   An ABNF syntax error in the <exponent> rule was fixed.
-
-A.7 Changes in Draft 07
-
-   The term "native LDAP encoding" has been replaced by the term "LDAP-
-   specific encoding" to align with terminology anticipated to be used
-   in the revision of RFC 2252.
-
-   Section 8 has been extracted to become a separate Internet draft,
-   draft-legg-ldap-gser-00.txt.  The specifications for ChoiceOfStrings
-   types have also been moved to this new Internet draft.  Various
-   editorial changes have been made to this draft to accommodate this
-   split.
-
-A.8 Changes in Draft 08
-
-   The enumeratedMatch matching rule duplicates a subset of the
-   functionality of allComponentsMatch so it has been removed.  The
-   enumeratedMatch rule has been replaced by allComponentsMatch in the
-   examples.  The description of the OpenAssertionType syntax has been
-   moved into Section 7.
-
-
-
-Legg                     Expires 2 October 2003                [Page 41]
-\f
-INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    April 2, 2003
-
-
-A.9 Changes in Draft 09
-
-   The associated type for the EXTERNAL type has been changed from the
-   one defined in X.680 for ASN.1 value notation to the one defined in
-   X.690 for BER.
-
-A.10 Changes in Draft 10
-
-   The definition of ComponentAssertion has been changed to make the
-   "component" field optional, and non-empty when present.  This change
-   allows the specification of search filters where all the assertions
-   must match the same value of an attribute. Normally each assertion is
-   free to match any of the values of a multi-valued attribute.
-   Corresponding changes have been made to the ABNF in Section 6.  An
-   illustrative example has been added to Section 8.
-
-   Conditions on whether a ComponentAssertion returns FALSE or undefined
-   when some part of the component references identifies an open type
-   have been removed from Section 4.2.  The changes in draft 04 that
-   introduced the <select> form of ComponentId made these conditions
-   unnecessary and inappropriate.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg                     Expires 2 October 2003                [Page 42]
-\f
index 074e295be40c7167e0b5907fed9bc4dd766ebff4..fb7cdf5f469fbd1bfe58064a0b209da6c433022a 100644 (file)
@@ -37,6 +37,10 @@ rfc3671.txt Collective Attributes in LDAP (PS)
 rfc3672.txt Subentries in the LDAP (PS)
 rfc3673.txt LDAPv3: All Operational Attributes (PS)
 rfc3674.txt Feature Discovery in LDAP (PS)
+rfc3687.txt LDAP Component Matching Rules (PS)
+rfc3698.txt LDAP: Additional Matching Rules (PS)
+rfc3712.txt LDAP: Schema for Printer Services (I)
+rfc3727.txt ASN.1 Module for LDAP Component Matching Rules (PS)
 
 Legend:
 STD    Standard
diff --git a/doc/rfc/rfc3687.txt b/doc/rfc/rfc3687.txt
new file mode 100644 (file)
index 0000000..a63ab1f
--- /dev/null
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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 Abstract
+   Syntax Notation One (ASN.1) [13] type definitions.  ASN.1 type
+   notation has a number of simple data types (e.g., PrintableString,
+   INTEGER, BOOLEAN), and combining types (i.e., SET, SEQUENCE, SET OF,
+   SEQUENCE OF, and CHOICE) for constructing arbitrarily complex data
+   types from simpler component types.  In LDAP, the attribute syntaxes
+   are usually described in Augmented Backus-Naur Form (ABNF) [2],
+   though there is an implied association between the LDAP attribute
+   syntaxes and the X.500 ASN.1 types.  To a large extent, the data
+   types of attribute values in either an LDAP or X.500 directory are
+   described by ASN.1 types.  This formal description can be exploited
+   to identify component parts of an attribute value for a variety of
+   purposes.  This document addresses attribute value matching.
+
+   With any complex attribute syntax there is normally a requirement to
+   partially match an attribute value of that syntax by matching only
+   selected components of the value.  Typically, matching rules specific
+   to the attribute syntax are defined to fill this need.  These highly
+   specific matching rules usually only provide the most immediately
+   useful matching capability.  Some complex attribute syntaxes don't
+   even have an equality matching rule let alone any additional matching
+   rules for partial matching.  This document defines a generic way of
+   matching user selected components in an attribute value of any
+   arbitrarily complex attribute syntax, where that syntax is described
+   using ASN.1 type notation.  All of the type notations defined in
+   X.680 [13] are supported.
+
+   Section 3 describes the ComponentAssertion, a testable assertion
+   about the value of a component of an attribute value of any complex
+   syntax.
+
+   Section 4 introduces the ComponentFilter assertion, which is an
+   expression of ComponentAssertions.  The ComponentFilter enables more
+   powerful filter matching of components in an attribute value.
+
+   Section 5 defines the componentFilterMatch matching rule, which
+   enables a ComponentFilter to be evaluated against attribute values.
+
+
+
+
+
+Legg                        Standards Track                     [Page 3]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   Section 6 defines matching rules for component-wise equality matching
+   of attribute values of any syntax described by an ASN.1 type
+   definition.
+
+   Examples showing the usage of componentFilterMatch are in Section 7.
+
+   For a new attribute syntax, the Generic String Encoding Rules [9] and
+   the specifications in sections 3 to 6 of this document make it
+   possible to fully and precisely define the LDAP-specific encoding,
+   the LDAP and X.500 binary encoding (and possibly other ASN.1
+   encodings in the future), a suitable equality matching rule, and a
+   comprehensive collection of component matching capabilities, by
+   simply writing down an ASN.1 type definition for the syntax.  These
+   implicit definitions are also automatically extended if the ASN.1
+   type is later extended.  The algorithmic relationship between the
+   ASN.1 type definition, the various encodings and the component
+   matching behaviour makes directory server implementation support for
+   the component matching rules amenable to automatic code generation
+   from ASN.1 type definitions.
+
+   Schema designers have the choice of storing related items of data as
+   a single attribute value of a complex syntax in some entry, or as a
+   subordinate entry where the related data items are stored as separate
+   attribute values of simpler syntaxes.  The inability to search
+   component parts of a complex syntax has been used as an argument for
+   favouring the subordinate entries approach.  The component matching
+   rules provide the analogous matching capability on an attribute value
+   of a complex syntax that a search filter has on a subordinate entry.
+
+   Most LDAP syntaxes have corresponding ASN.1 type definitions, though
+   they are usually not reproduced or referenced alongside the formal
+   definition of the LDAP syntax.  Syntaxes defined with only a
+   character string encoding, i.e., without an explicit or implied
+   corresponding ASN.1 type definition, cannot use the component
+   matching capabilities described in this document unless and until a
+   semantically equivalent ASN.1 type definition is defined for them.
+
+2.  Conventions
+
+   Throughout this document "type" shall be taken to mean an ASN.1 type
+   unless explicitly qualified as an attribute type, and "value" shall
+   be taken to mean an ASN.1 value unless explicitly qualified as an
+   attribute value.
+
+
+
+
+
+
+
+
+Legg                        Standards Track                     [Page 4]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   Note that "ASN.1 value" does not mean a Basic Encoding Rules (BER)
+   [17] encoded value.  The ASN.1 value is an abstract concept that is
+   independent of any particular encoding.  BER is just one possible
+   encoding of an ASN.1 value.  The component matching rules operate at
+   the abstract level without regard for the possible encodings of a
+   value.
+
+   Attribute type and matching rule definitions in this document are
+   provided in both the X.500 [10] and LDAP [4] description formats.
+   Note that the LDAP descriptions have been rendered with additional
+   white-space and line breaks for the sake of readability.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are
+   to be interpreted as described in BCP 14, RFC 2119 [1].  The key word
+   "OPTIONAL" is exclusively used with its ASN.1 meaning.
+
+3.  ComponentAssertion
+
+   A ComponentAssertion is an assertion about the presence, or values
+   of, components within an ASN.1 value, i.e., an instance of an ASN.1
+   type.  The ASN.1 value is typically an attribute value, where the
+   ASN.1 type is the syntax of the attribute.  However, a
+   ComponentAssertion may also be applied to a component part of an
+   attribute value.  The assertion evaluates to either TRUE, FALSE or
+   Undefined for each tested ASN.1 value.
+
+   A ComponentAssertion is described by the following ASN.1 type
+   (assumed to be defined with "EXPLICIT TAGS" in force):
+
+      ComponentAssertion ::= SEQUENCE {
+          component         ComponentReference (SIZE(1..MAX)) OPTIONAL,
+          useDefaultValues  BOOLEAN DEFAULT TRUE,
+          rule              MATCHING-RULE.&id,
+          value             MATCHING-RULE.&AssertionType }
+
+      ComponentReference ::= UTF8String
+
+   MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
+   rule.  MATCHING-RULE.&AssertionType is an open type (formerly known
+   as the ANY type).
+
+   The "component" field of a ComponentAssertion identifies which
+   component part of a value of some ASN.1 type is to be tested, the
+   "useDefaultValues" field indicates whether DEFAULT values are to be
+   substituted for absent component values, the "rule" field indicates
+
+
+
+
+
+Legg                        Standards Track                     [Page 5]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   how the component is to be tested, and the "value" field is an
+   asserted ASN.1 value against which the component is tested.  The
+   ASN.1 type of the asserted value is determined by the chosen rule.
+
+   The fields of a ComponentAssertion are described in detail in the
+   following sections.
+
+3.1.  Component Reference
+
+   The component field in a ComponentAssertion is a UTF-8 character
+   string [6] whose textual content is a component reference,
+   identifying a component part of some ASN.1 type or value.  A
+   component reference conforms to the following ABNF [2], which extends
+   the notation defined in Clause 14 of X.680 [13]:
+
+      component-reference = ComponentId *( "." ComponentId )
+      ComponentId         = identifier /
+                            from-beginning /
+                            count /
+                            from-end /       ; extends Clause 14
+                            content /        ; extends Clause 14
+                            select /         ; extends Clause 14
+                            all
+
+      identifier          = lowercase *alphanumeric
+                               *(hyphen 1*alphanumeric)
+      alphanumeric        = uppercase / lowercase / decimal-digit
+      uppercase           = %x41-5A  ; "A" to "Z"
+      lowercase           = %x61-7A  ; "a" to "z"
+      hyphen              = "-"
+
+      from-beginning      = positive-number
+      count               = "0"
+      from-end            = "-" positive-number
+      content             = %x63.6F.6E.74.65.6E.74 ; "content"
+      select              = "(" Value *( "," Value ) ")"
+      all                 = "*"
+
+
+      positive-number     = non-zero-digit *decimal-digit
+
+      decimal-digit       = %x30-39  ; "0" to "9"
+      non-zero-digit      = %x31-39  ; "1" to "9"
+
+
+
+
+
+
+
+
+Legg                        Standards Track                     [Page 6]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   An <identifier> conforms to the definition of an identifier in ASN.1
+   notation (Clause 11.3 of X.680 [13]).  It begins with a lowercase
+   letter and is followed by zero or more letters, digits, and hyphens.
+   A hyphen is not permitted to be the last character and a hyphen is
+   not permitted to be followed by another hyphen.
+
+   The <Value> rule is described by the Generic String Encoding Rules
+   (GSER) [9].
+
+   A component reference is a sequence of one or more ComponentIds where
+   each successive ComponentId identifies either an inner component at
+   the next level of nesting of an ASN.1 combining type, i.e., SET,
+   SEQUENCE, SET OF, SEQUENCE OF, or CHOICE, or a specific type within
+   an ASN.1 open type.
+
+   A component reference is always considered in the context of a
+   particular complex ASN.1 type.  When applied to the ASN.1 type the
+   component reference identifies a specific component type.  When
+   applied to a value of the ASN.1 type a component reference identifies
+   zero, one or more component values of that component type.  The
+   component values are potentially in a DEFAULT value if
+   useDefaultValues is TRUE.  The specific component type identified by
+   the component reference determines what matching rules are capable of
+   being used to match the component values.
+
+   The component field in a ComponentAssertion may also be absent, in
+   which case the identified component type is the ASN.1 type to which
+   the ComponentAssertion is applied, and the identified component value
+   is the whole ASN.1 value.
+
+   A valid component reference for a particular complex ASN.1 type is
+   constructed by starting with the outermost combining type and
+   repeatedly selecting one of the permissible forms of ComponentId to
+   identify successively deeper nested components.  A component
+   reference MAY identify a component with a complex ASN.1 type, i.e.,
+   it is not required that the component type identified by a component
+   reference be a simple ASN.1 type.
+
+3.1.1.  Component Type Substitutions
+
+   ASN.1 type notation has a number of constructs for referencing other
+   defined types, and constructs that are irrelevant for matching
+   purposes.  These constructs are not represented in a component
+   reference in any way and substitutions of the component type are
+   performed to eliminate them from further consideration.  These
+   substitutions automatically occur prior to each ComponentId, whether
+   constructing or interpreting a component reference, but do not occur
+   after the last ComponentId, except as allowed by Section 3.2.
+
+
+
+Legg                        Standards Track                     [Page 7]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   If the ASN.1 type is an ASN.1 type reference then the component type
+   is taken to be the actual definition on the right hand side of the
+   type assignment for the referenced type.
+
+   If the ASN.1 type is a tagged type then the component type is taken
+   to be the type without the tag.
+
+   If the ASN.1 type is a constrained type (see X.680 [13] and X.682
+   [15] for the details of ASN.1 constraint notation) then the component
+   type is taken to be the type without the constraint.
+
+   If the ASN.1 type is an ObjectClassFieldType (Clause 14 of X.681
+   [14]) that denotes a specific ASN.1 type (e.g., MATCHING-RULE.&id
+   denotes the OBJECT IDENTIFIER type) then the component type is taken
+   to be the denoted type.  Section 3.1.6 describes the case where the
+   ObjectClassFieldType denotes an open type.
+
+   If the ASN.1 type is a selection type other than one used in the list
+   of components for a SET or SEQUENCE type then the component type is
+   taken to be the selected alternative type from the named CHOICE.
+
+   If the ASN.1 type is a TypeFromObject (Clause 15 of X.681 [14]) then
+   the component type is taken to be the denoted type.
+
+   If the ASN.1 type is a ValueSetFromObjects (Clause 15 of X.681 [14])
+   then the component type is taken to be the governing type of the
+   denoted values.
+
+3.1.2.  Referencing SET, SEQUENCE and CHOICE Components
+
+   If the ASN.1 type is a SET or SEQUENCE type then the <identifier>
+   form of ComponentId may be used to identify the component type within
+   that SET or SEQUENCE having that identifier.  If <identifier>
+   references an OPTIONAL component type and that component is not
+   present in a particular value then there are no corresponding
+   component values.  If <identifier> references a DEFAULT component
+   type and useDefaultValues is TRUE (the default setting for
+   useDefaultValues) and that component is not present in a particular
+   value then the component value is taken to be the default value.  If
+   <identifier> references a DEFAULT component type and useDefaultValues
+   is FALSE and that component is not present in a particular value then
+   there are no corresponding component values.
+
+   If the ASN.1 type is a CHOICE type then the <identifier> form of
+   ComponentId may be used to identify the alternative type within that
+   CHOICE having that identifier.  If <identifier> references an
+   alternative other than the one used in a particular value then there
+   are no corresponding component values.
+
+
+
+Legg                        Standards Track                     [Page 8]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   The COMPONENTS OF notation in Clause 24 of X.680 [13] augments the
+   defined list of components in a SET or SEQUENCE type by including all
+   the components of another defined SET or SEQUENCE type respectively.
+   These included components are referenced directly by identifier as
+   though they were defined in-line in the SET or SEQUENCE type
+   containing the COMPONENTS OF notation.
+
+   The SelectionType (Clause 29 of X.680 [13]), when used in the list of
+   components for a SET or SEQUENCE type, includes a single component
+   from a defined CHOICE type.  This included component is referenced
+   directly by identifier as though it was defined in-line in the SET or
+   SEQUENCE type.
+
+   The REAL type is treated as though it is the SEQUENCE type defined in
+   Clause 20.5 of X.680 [13].
+
+   The EMBEDDED PDV type is treated as though it is the SEQUENCE type
+   defined in Clause 33.5 of X.680 [13].
+
+   The EXTERNAL type is treated as though it is the SEQUENCE type
+   defined in Clause 8.18.1 of X.690 [17].
+
+   The unrestricted CHARACTER STRING type is treated as though it is the
+   SEQUENCE type defined in Clause 40.5 of X.680 [13].
+
+   The INSTANCE OF type is treated as though it is the SEQUENCE type
+   defined in Annex C of X.681 [14].
+
+   The <identifier> form MUST NOT be used on any other ASN.1 type.
+
+3.1.3.  Referencing SET OF and SEQUENCE OF Components
+
+   If the ASN.1 type is a SET OF or SEQUENCE OF type then the
+   <from-beginning>, <from-end>, <count> and <all> forms of ComponentId
+   may be used.
+
+   The <from-beginning> form of ComponentId may be used to identify one
+   instance (i.e., value) of the component type of the SET OF or
+   SEQUENCE OF type (e.g., if Foo ::= SET OF Bar, then Bar is the
+   component type), where the instances are numbered from one upwards.
+   If <from-beginning> references a higher numbered instance than the
+   last instance in a particular value of the SET OF or SEQUENCE OF type
+   then there is no corresponding component value.
+
+   The <from-end> form of ComponentId may be used to identify one
+   instance of the component type of the SET OF or SEQUENCE OF type,
+   where "-1" is the last instance, "-2" is the second last instance,
+
+
+
+
+Legg                        Standards Track                     [Page 9]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   and so on.  If <from-end> references a lower numbered instance than
+   the first instance in a particular value of the SET OF or SEQUENCE OF
+   type then there is no corresponding component value.
+
+   The <count> form of ComponentId identifies a notional count of the
+   number of instances of the component type in a value of the SET OF or
+   SEQUENCE OF type.  This count is not explicitly represented but for
+   matching purposes it has an assumed ASN.1 type of INTEGER (0..MAX).
+   A ComponentId of the <count> form, if used, MUST be the last
+   ComponentId in a component reference.
+
+   The <all> form of ComponentId may be used to simultaneously identify
+   all instances of the component type of the SET OF or SEQUENCE OF
+   type.  It is through the <all> form that a component reference can
+   identify more than one component value.  However, if a particular
+   value of the SET OF or SEQUENCE OF type is an empty list, then there
+   are no corresponding component values.
+
+   Where multiple component values are identified, the remaining
+   ComponentIds in the component reference, if any, can identify zero,
+   one or more subcomponent values for each of the higher level
+   component values.
+
+   The corresponding ASN.1 type for the <from-beginning>, <from-end>,
+   and <all> forms of ComponentId is the component type of the SET OF or
+   SEQUENCE OF type.
+
+   The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be
+   used on ASN.1 types other than SET OF or SEQUENCE OF.
+
+3.1.4.  Referencing Components of Parameterized Types
+
+   A component reference cannot be formed for a parameterized type
+   unless the type has been used with actual parameters, in which case
+   the type is treated as though the DummyReferences [16] have been
+   substituted with the actual parameters.
+
+3.1.5.  Component Referencing Example
+
+   Consider the following ASN.1 type definitions.
+
+      ExampleType ::= SEQUENCE {
+          part1       [0] INTEGER,
+          part2       [1] ExampleSet,
+          part3       [2] SET OF OBJECT IDENTIFIER,
+          part4       [3] ExampleChoice }
+
+
+
+
+
+Legg                        Standards Track                    [Page 10]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+      ExampleSet ::= SET {
+          option      PrintableString,
+          setting     BOOLEAN }
+
+      ExampleChoice ::= CHOICE {
+          eeny-meeny  BIT STRING,
+          miney-mo    OCTET STRING }
+
+   Following are component references constructed with respect to the
+   type ExampleType.
+
+   The component reference "part1" identifies a component of a value of
+   ExampleType having the ASN.1 tagged type [0] INTEGER.
+
+   The component reference "part2" identifies a component of a value of
+   ExampleType having the ASN.1 type of [1] ExampleSet
+
+   The component reference "part2.option" identifies a component of a
+   value of ExampleType having the ASN.1 type of PrintableString.  A
+   ComponentAssertion could also be applied to a value of ASN.1 type
+   ExampleSet, in which case the component reference "option" would
+   identify the same kind of information.
+
+   The component reference "part3" identifies a component of a value of
+   ExampleType having the ASN.1 type of [2] SET OF OBJECT IDENTIFIER.
+
+   The component reference "part3.2" identifies the second instance of
+   the part3 SET OF.  The instance has the ASN.1 type of OBJECT
+   IDENTIFIER.
+
+   The component reference "part3.0" identifies the count of the number
+   of instances in the part3 SET OF.  The count has the corresponding
+   ASN.1 type of INTEGER (0..MAX).
+
+   The component reference "part3.*" identifies all the instances in the
+   part3 SET OF.  Each instance has the ASN.1 type of OBJECT IDENTIFIER.
+
+   The component reference "part4" identifies a component of a value of
+   ExampleType having the ASN.1 type of [3] ExampleChoice.
+
+   The component reference "part4.miney-mo" identifies a component of a
+   value of ExampleType having the ASN.1 type of OCTET STRING.
+
+
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 11]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+3.1.6.  Referencing Components of Open Types
+
+   If a sequence of ComponentIds identifies an ObjectClassFieldType
+   denoting an open type (e.g., ATTRIBUTE.&Type denotes an open type)
+   then the ASN.1 type of the component varies.  An open type is
+   typically constrained by some other component(s) in an outer
+   enclosing type, either formally through the use of a component
+   relation constraint [15], or informally in the accompanying text, so
+   the actual ASN.1 type of a value of the open type will generally be
+   known.  The constraint will also limit the range of permissible
+   types.  The <select> form of ComponentId may be used to identify one
+   of these permissible types in an open type.  Subcomponents of that
+   type can then be identified with further ComponentIds.
+
+   The other components constraining the open type are termed the
+   referenced components [15].  The <select> form contains a list of one
+   or more values which take the place of the value(s) of the referenced
+   component(s) to uniquely identify one of the permissible types of the
+   open type.
+
+   Where the open type is constrained by a component relation
+   constraint, there is a <Value> in the <select> form for each of the
+   referenced components in the component relation constraint, appearing
+   in the same order.  The ASN.1 type of each of these values is the
+   same as the ASN.1 type of the corresponding referenced component.
+   The type of a referenced component is potentially any ASN.1 type
+   however it is typically an OBJECT IDENTIFIER or INTEGER, which means
+   that the <Value> in the <select> form of ComponentId will nearly
+   always be an <ObjectIdentifierValue> or <IntegerValue> [9].
+   Furthermore, component relation constraints typically have only one
+   referenced component.
+
+   Where the open type is not constrained by a component relation
+   constraint, the specification introducing the syntax containing the
+   open type should explicitly nominate the referenced components and
+   their order, so that the <select> form can be used.
+
+   If an instance of <select> contains a value other than the value of
+   the referenced component used in a particular value of the outer
+   enclosing type then there are no corresponding component values for
+   the open type.
+
+3.1.6.1.  Open Type Referencing Example
+
+   The ASN.1 type AttributeTypeAndValue [10] describes a single
+   attribute value of a nominated attribute type.
+
+
+
+
+
+Legg                        Standards Track                    [Page 12]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+      AttributeTypeAndValue ::= SEQUENCE {
+          type    ATTRIBUTE.&id ({SupportedAttributes}),
+          value   ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
+
+   ATTRIBUTE.&id denotes an OBJECT IDENTIFIER and
+   ({SupportedAttributes}) constrains the OBJECT IDENTIFIER to be a
+   supported attribute type.
+
+   ATTRIBUTE.&Type denotes an open type, in this case an attribute
+   value, and ({SupportedAttributes}{@type}) is a component relation
+   constraint that constrains the open type to be of the attribute
+   syntax for the attribute type.  The component relation constraint
+   references only the "type" component, which has the ASN.1 type of
+   OBJECT IDENTIFIER, thus if the <select> form of ComponentId is used
+   to identify attribute values of specific attribute types it will
+   contain a single OBJECT IDENTIFIER value.
+
+   The component reference "value" on AttributeTypeAndValue refers to
+   the open type.
+
+   One of the X.500 standard attributes is facsimileTelephoneNumber
+   [12], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is
+   defined to have the following syntax.
+
+      FacsimileTelephoneNumber ::= SEQUENCE {
+          telephoneNumber PrintableString(SIZE(1..ub-telephone-number)),
+          parameters      G3FacsimileNonBasicParameters OPTIONAL }
+
+   The component reference "value.(2.5.4.23)" on AttributeTypeAndValue
+   specifies an attribute value with the FacsimileTelephoneNumber
+   syntax.
+
+   The component reference "value.(2.5.4.23).telephoneNumber" on
+   AttributeTypeAndValue identifies the telephoneNumber component of a
+   facsimileTelephoneNumber attribute value.  The component reference
+   "value.(facsimileTelephoneNumber)" is equivalent to
+   "value.(2.5.4.23)".
+
+   If the AttributeTypeAndValue ASN.1 value contains an attribute type
+   other than facsimileTelephoneNumber then there are no corresponding
+   component values for the component references "value.(2.5.4.23)" and
+   "value.(2.5.4.23).telephoneNumber".
+
+
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 13]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+3.1.7.  Referencing Contained Types
+
+   Sometimes the contents of a BIT STRING or OCTET STRING value are
+   required to be the encodings of other ASN.1 values of specific ASN.1
+   types.  For example, the extnValue component of the Extension type
+   component in the Certificate type [11] is an OCTET STRING that is
+   required to contain a Distinguished Encoding Rules (DER) [17]
+   encoding of a certificate extension value.  It is useful to be able
+   to refer to the embedded encoded value and its components.  An
+   embedded encoded value is here referred to as a contained value and
+   its associated type as the contained type.
+
+   If the ASN.1 type is a BIT STRING or OCTET STRING type containing
+   encodings of other ASN.1 values then the <content> form of
+   ComponentId may be used to identify the contained type.
+   Subcomponents of that type can then be identified with further
+   ComponentIds.
+
+   The contained type may be (effectively) an open type, constrained by
+   some other component in an outer enclosing type (e.g., in a
+   certificate Extension, extnValue is constrained by the chosen
+   extnId).  In these cases the next ComponentId, if any, MUST be of the
+   <select> form.
+
+   For the purpose of building component references, the content of the
+   extnValue OCTET STRING in the Extension type is assumed to be an open
+   type having a notional component relation constraint with the extnId
+   component as the single referenced component, i.e.,
+
+      EXTENSION.&ExtnType ({ExtensionSet}{@extnId})
+
+   The data-value component of the associated types for the EMBEDDED PDV
+   and CHARACTER STRING types is an OCTET STRING containing the encoding
+   of a data value described by the identification component.  For the
+   purpose of building component references, the content of the
+   data-value OCTET STRING in these types is assumed to be an open type
+   having a notional component relation constraint with the
+   identification component as the single referenced component.
+
+3.1.7.1.  Contained Type Referencing Example
+
+   The Extension ASN.1 type [11] describes a single certificate
+   extension value of a nominated extension type.
+
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 14]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+      Extension ::= SEQUENCE {
+          extnId     EXTENSION.&id ({ExtensionSet}),
+          critical   BOOLEAN DEFAULT FALSE,
+          extnValue  OCTET STRING
+              -- contains a DER encoding of a value of type &ExtnType
+              -- for the extension object identified by extnId -- }
+
+   EXTENSION.&id denotes an OBJECT IDENTIFIER and ({ExtensionSet})
+   constrains the OBJECT IDENTIFIER to be the identifier of a supported
+   certificate extension.
+
+   The component reference "extnValue" on Extension refers to a
+   component type of OCTET STRING.  The corresponding component values
+   will be OCTET STRING values.  The component reference
+   "extnValue.content" on Extension refers to the type of the contained
+   type, which in this case is an open type.
+
+   One of the X.509 [11] standard extensions is basicConstraints, which
+   is identified with the OBJECT IDENTIFIER 2.5.29.19 and is defined to
+   have the following syntax.
+
+      BasicConstraintsSyntax ::= SEQUENCE {
+          cA                 BOOLEAN DEFAULT FALSE,
+          pathLenConstraint  INTEGER (0..MAX) OPTIONAL }
+
+   The component reference "extnValue.content.(2.5.29.19)" on Extension
+   specifies a BasicConstraintsSyntax extension value and the component
+   reference "extnValue.content.(2.5.29.19).cA" identifies the cA
+   component of a BasicConstraintsSyntax extension value.
+
+3.2.  Matching of Components
+
+   The rule in a ComponentAssertion specifies how the zero, one or more
+   component values identified by the component reference are tested by
+   the assertion.  Attribute matching rules are used to specify the
+   semantics of the test.
+
+   Each matching rule has a notional set of attribute syntaxes
+   (typically one), defined as ASN.1 types, to which it may be applied.
+   When used in a ComponentAssertion these matching rules apply to the
+   same ASN.1 types, only in this context the corresponding ASN.1 values
+   are not necessarily complete attribute values.
+
+   Note that the referenced component type may be a tagged and/or
+   constrained version of the expected attribute syntax (e.g.,
+   [0] INTEGER, whereas integerMatch would expect simply INTEGER), or an
+   open type.  Additional type substitutions of the kind described in
+
+
+
+
+Legg                        Standards Track                    [Page 15]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   Section 3.1.1 are performed as required to reduce the component type
+   to the same type as the attribute syntax expected by the matching
+   rule.
+
+   If a matching rule applies to more than one attribute syntax (e.g.,
+   objectIdentifierFirstComponentMatch [12]) then the minimum number of
+   substitutions required to conform to any one of those syntaxes is
+   performed.  If a matching rule can apply to any attribute syntax
+   (e.g., the allComponentsMatch rule defined in Section 6.2) then the
+   referenced component type is used as is, with no additional
+   substitutions.
+
+   The value in a ComponentAssertion will be of the assertion syntax
+   (i.e., ASN.1 type) required by the chosen matching rule.  Note that
+   the assertion syntax of a matching rule is not necessarily the same
+   as the attribute syntax(es) to which the rule may be applied.
+
+   Some matching rules do not have a fixed assertion syntax (e.g.,
+   allComponentsMatch).  The required assertion syntax is determined in
+   each instance of use by the syntax of the attribute type to which the
+   matching rule is applied.  For these rules the ASN.1 type of the
+   referenced component is used in place of an attribute syntax to
+   decide the required assertion syntax.
+
+   The ComponentAssertion is Undefined if:
+
+   a) the matching rule in the ComponentAssertion is not known to the
+      evaluating procedure,
+
+   b) the matching rule is not applicable to the referenced component
+      type, even with the additional type substitutions,
+
+   c) the value in the ComponentAssertion does not conform to the
+      assertion syntax defined for the matching rule,
+
+   d) some part of the component reference identifies an open type in
+      the tested value that cannot be decoded, or
+
+   e) the implementation does not support the particular combination of
+      component reference and matching rule.
+
+   If the ComponentAssertion is not Undefined then the
+   ComponentAssertion evaluates to TRUE if there is at least one
+   component value for which the matching rule applied to that component
+   value returns TRUE, and evaluates to FALSE otherwise (which includes
+   the case where there are no component values).
+
+
+
+
+
+Legg                        Standards Track                    [Page 16]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+3.2.1.  Applicability of Existing Matching Rules
+
+3.2.1.1.  String Matching
+
+   ASN.1 has a number of built in restricted character string types with
+   different character sets and/or different character encodings.  A
+   directory user generally has little interest in the particular
+   character set or encoding used to represent a character string
+   component value, and some directory server implementations make no
+   distinction between the different string types in their internal
+   representation of values.  So rather than define string matching
+   rules for each of the restricted character string types, the existing
+   case ignore and case exact string matching rules are extended to
+   apply to component values of any of the restricted character string
+   types and any ChoiceOfStrings type [9], in addition to component
+   values of the DirectoryString type.  This extension is only for the
+   purposes of component matching described in this document.
+
+   The relevant string matching rules are: caseIgnoreMatch,
+   caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch,
+   caseExactOrderingMatch and caseExactSubstringsMatch.  The relevant
+   restricted character string types are: NumericString,
+   PrintableString, VisibleString, IA5String, UTF8String, BMPString,
+   UniversalString, TeletexString, VideotexString, GraphicString and
+   GeneralString.  A ChoiceOfStrings type is a purely syntactic CHOICE
+   of these ASN.1 string types.  Note that GSER [9] declares each and
+   every use of the DirectoryString{} parameterized type to be a
+   ChoiceOfStrings type.
+
+   The assertion syntax of the string matching rules is still
+   DirectoryString regardless of the string syntax of the component
+   being matched.  Thus an implementation will be called upon to compare
+   a DirectoryString value to a value of one of the restricted character
+   string types, or a ChoiceOfStrings type.  As is the case when
+   comparing two DirectoryStrings where the chosen alternatives are of
+   different string types, the comparison proceeds so long as the
+   corresponding characters are representable in both character sets.
+   Otherwise matching returns FALSE.
+
+3.2.1.2.  Telephone Number Matching
+
+   Early editions of X.520 [12] gave the syntax of the telephoneNumber
+   attribute as a constrained PrintableString.  The fourth edition of
+   X.520 equates the ASN.1 type name TelephoneNumber to the constrained
+   PrintableString and uses TelephoneNumber as the attribute and
+   assertion syntax.  For the purposes of component matching,
+
+
+
+
+
+Legg                        Standards Track                    [Page 17]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted
+   to be applied to any PrintableString value, as well as to
+   TelephoneNumber values.
+
+3.2.1.3.  Distinguished Name Matching
+
+   The DistinguishedName type is defined by assignment to be the same as
+   the RDNSequence type, however RDNSequence is sometimes directly used
+   in other type definitions.  For the purposes of component matching,
+   distinguishedNameMatch is also permitted to be applied to values of
+   the RDNSequence type.
+
+3.2.2.  Additional Useful Matching Rules
+
+   This section defines additional matching rules that may prove useful
+   in ComponentAssertions.  These rules may also be used in
+   extensibleMatch search filters [3].
+
+3.2.2.1.  The rdnMatch Matching Rule
+
+   The distinguishedNameMatch matching rule can match whole
+   distinguished names but it is sometimes useful to be able to match
+   specific Relative Distinguished Names (RDNs) in a Distinguished Name
+   (DN) without regard for the other RDNs in the DN.  The rdnMatch
+   matching rule allows component RDNs of a DN to be tested.
+
+   The LDAP-style definitions for rdnMatch and its assertion syntax are:
+
+      ( 1.2.36.79672281.1.13.3 NAME 'rdnMatch'
+          SYNTAX 1.2.36.79672281.1.5.0 )
+
+      ( 1.2.36.79672281.1.5.0 DESC 'RDN' )
+
+   The LDAP-specific encoding for a value of the RDN syntax is given by
+   the <RelativeDistinguishedNameValue> rule [9].
+
+   The X.500-style definition for rdnMatch is:
+
+      rdnMatch MATCHING-RULE ::= {
+          SYNTAX  RelativeDistinguishedName
+          ID      { 1 2 36 79672281 1 13 3 } }
+
+   The rdnMatch rule evaluates to true if the component value and
+   assertion value are the same RDN, using the same RDN comparison
+   method as distinguishedNameMatch.
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 18]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   When using rdnMatch to match components of DNs it is important to
+   note that the LDAP-specific encoding of a DN [5] reverses the order
+   of the RDNs.  So for the DN represented in LDAP as
+   "cn=Steven Legg,o=Adacel,c=AU", the RDN "cn=Steven Legg" corresponds
+   to the component reference "3", or alternatively, "-1".
+
+3.2.2.2.  The presentMatch Matching Rule
+
+   At times it would be useful to test not if a specific value of a
+   particular component is present, but whether any value of a
+   particular component is present.  The presentMatch matching rule
+   allows the presence of a particular component value to be tested.
+
+   The LDAP-style definitions for presentMatch and its assertion syntax
+   are:
+
+      ( 1.2.36.79672281.1.13.5 NAME 'presentMatch'
+          SYNTAX 1.2.36.79672281.1.5.1 )
+
+      ( 1.2.36.79672281.1.5.1 DESC 'NULL' )
+
+   The LDAP-specific encoding for a value of the NULL syntax is given by
+   the <NullValue> rule [9].
+
+   The X.500-style definition for presentMatch is:
+
+      presentMatch MATCHING-RULE ::= {
+          SYNTAX  NULL
+          ID      { 1 2 36 79672281 1 13 5 } }
+
+   When used in a extensible match filter item, presentMatch behaves
+   like the "present" case of a regular search filter.  In a
+   ComponentAssertion, presentMatch evaluates to TRUE if and only if the
+   component reference identifies one or more component values,
+   regardless of the actual component value contents.  Note that if
+   useDefaultValues is TRUE then the identified component values may be
+   (part of) a DEFAULT value.
+
+   The notional count referenced by the <count> form of ComponentId is
+   taken to be present if the SET OF value is present, and absent
+   otherwise.  Note that in ASN.1 notation an absent SET OF value is
+   distinctly different from a SET OF value that is present but empty.
+   It is up to the specification using the ASN.1 notation to decide
+   whether the distinction matters.  Often an empty SET OF component and
+   an absent SET OF component are treated as semantically equivalent.
+   If a SET OF value is present, but empty, a presentMatch on the SET OF
+   component SHALL return TRUE and the notional count SHALL be regarded
+   as present and equal to zero.
+
+
+
+Legg                        Standards Track                    [Page 19]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+3.2.3.  Summary of Useful Matching Rules
+
+   The following is a non-exhaustive list of useful matching rules and
+   the ASN.1 types to which they can be applied, taking account of all
+   the extensions described in Section 3.2.1, and the new matching rules
+   defined in Section 3.2.2.
+
+      +================================+==============================+
+      | Matching Rule                  | ASN.1 Type                   |
+      +================================+==============================+
+      | bitStringMatch                 | BIT STRING                   |
+      +--------------------------------+------------------------------+
+      | booleanMatch                   | BOOLEAN                      |
+      +--------------------------------+------------------------------+
+      | caseIgnoreMatch                | NumericString                |
+      | caseIgnoreOrderingMatch        | PrintableString              |
+      | caseIgnoreSubstringsMatch      | VisibleString (ISO646String) |
+      | caseExactMatch                 | IA5String                    |
+      | caseExactOrderingMatch         | UTF8String                   |
+      | caseExactSubstringsMatch       | BMPString (UCS-2, UNICODE)   |
+      |                                | UniversalString (UCS-4)      |
+      |                                | TeletexString (T61String)    |
+      |                                | VideotexString               |
+      |                                | GraphicString                |
+      |                                | GeneralString                |
+      |                                | any ChoiceOfStrings type     |
+      +--------------------------------+------------------------------+
+      | caseIgnoreIA5Match             | IA5String                    |
+      | caseExactIA5Match              |                              |
+      +--------------------------------+------------------------------+
+      | distinguishedNameMatch         | DistinguishedName            |
+      |                                | RDNSequence                  |
+      +--------------------------------+------------------------------+
+      | generalizedTimeMatch           | GeneralizedTime              |
+      | generalizedTimeOrderingMatch   |                              |
+      +--------------------------------+------------------------------+
+      | integerMatch                   | INTEGER                      |
+      | integerOrderingMatch           |                              |
+      +--------------------------------+------------------------------+
+      | numericStringMatch             | NumericString                |
+      | numericStringOrderingMatch     |                              |
+      | numericStringSubstringsMatch   |                              |
+      +--------------------------------+------------------------------+
+      | objectIdentifierMatch          | OBJECT IDENTIFIER            |
+      +--------------------------------+------------------------------+
+      | octetStringMatch               | OCTET STRING                 |
+      | octetStringOrderingMatch       |                              |
+      | octetStringSubstringsMatch     |                              |
+
+
+
+Legg                        Standards Track                    [Page 20]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+      +--------------------------------+------------------------------+
+      | presentMatch                   | any ASN.1 type               |
+      +--------------------------------+------------------------------+
+      | rdnMatch                       | RelativeDistinguishedName    |
+      +--------------------------------+------------------------------+
+      | telephoneNumberMatch           | PrintableString              |
+      | telephoneNumberSubstringsMatch | TelephoneNumber              |
+      +--------------------------------+------------------------------+
+      | uTCTimeMatch                   | UTCTime                      |
+      | uTCTimeOrderingMatch           |                              |
+      +--------------------------------+------------------------------+
+
+   Note that the allComponentsMatch matching rule defined in Section 6.2
+   can be used for equality matching of values of the ENUMERATED, NULL,
+   REAL and RELATIVE-OID ASN.1 types, among other things.
+
+4.  ComponentFilter
+
+   The ComponentAssertion allows the value(s) of any one component type
+   in a complex ASN.1 type to be matched, but there is often a desire to
+   match the values of more than one component type.  A ComponentFilter
+   is an assertion about the presence, or values of, multiple components
+   within an ASN.1 value.
+
+   The ComponentFilter assertion, an expression of ComponentAssertions,
+   evaluates to either TRUE, FALSE or Undefined for each tested ASN.1
+   value.
+
+   A ComponentFilter is described by the following ASN.1 type (assumed
+   to be defined with "EXPLICIT TAGS" in force):
+
+      ComponentFilter ::= CHOICE {
+          item  [0] ComponentAssertion,
+          and   [1] SEQUENCE OF ComponentFilter,
+          or    [2] SEQUENCE OF ComponentFilter,
+          not   [3] ComponentFilter }
+
+   Note: despite the use of SEQUENCE OF instead of SET OF for the "and"
+   and "or" alternatives in ComponentFilter, the order of the component
+   filters is not significant.
+
+   A ComponentFilter that is a ComponentAssertion evaluates to TRUE if
+   the ComponentAssertion is TRUE, evaluates to FALSE if the
+   ComponentAssertion is FALSE, and evaluates to Undefined otherwise.
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 21]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   The "and" of a sequence of component filters evaluates to TRUE if the
+   sequence is empty or if each component filter evaluates to TRUE,
+   evaluates to FALSE if at least one component filter is FALSE, and
+   evaluates to Undefined otherwise.
+
+   The "or" of a sequence of component filters evaluates to FALSE if the
+   sequence is empty or if each component filter evaluates to FALSE,
+   evaluates to TRUE if at least one component filter is TRUE, and
+   evaluates to Undefined otherwise.
+
+   The "not" of a component filter evaluates to TRUE if the component
+   filter is FALSE, evaluates to FALSE if the component filter is TRUE,
+   and evaluates to Undefined otherwise.
+
+5.  The componentFilterMatch Matching Rule
+
+   The componentFilterMatch matching rule allows a ComponentFilter to be
+   applied to an attribute value.  The result of the matching rule is
+   the result of applying the ComponentFilter to the attribute value.
+
+   The LDAP-style definitions for componentFilterMatch and its assertion
+   syntax are:
+
+      ( 1.2.36.79672281.1.13.2 NAME 'componentFilterMatch'
+          SYNTAX 1.2.36.79672281.1.5.2 )
+
+      ( 1.2.36.79672281.1.5.2 DESC 'ComponentFilter' )
+
+   The LDAP-specific encoding for the ComponentFilter assertion syntax
+   is specified by GSER [9].
+
+   As a convenience to implementors, an equivalent ABNF description of
+   the GSER encoding for ComponentFilter is provided here.  In the event
+   that there is a discrepancy between this ABNF and the encoding
+   determined by GSER, GSER is to be taken as definitive.  The GSER
+   encoding of a ComponentFilter is described by the following
+   equivalent ABNF:
+
+      ComponentFilter = filter-item /
+                        and-filter /
+                        or-filter /
+                        not-filter
+
+      filter-item     = item-chosen ComponentAssertion
+      and-filter      = and-chosen  SequenceOfComponentFilter
+      or-filter       = or-chosen   SequenceOfComponentFilter
+      not-filter      = not-chosen  ComponentFilter
+
+
+
+
+Legg                        Standards Track                    [Page 22]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+      item-chosen     = %x69.74.65.6D.3A  ; "item:"
+      and-chosen      = %x61.6E.64.3A     ; "and:"
+      or-chosen       = %x6F.72.3A        ; "or:"
+      not-chosen      = %x6E.6F.74.3A     ; "not:"
+
+      SequenceOfComponentFilter = "{" [ sp ComponentFilter
+                                     *( "," sp ComponentFilter) ] sp "}"
+
+      ComponentAssertion = "{" [ sp component "," ]
+                               [ sp useDefaultValues "," ]
+                                 sp rule ","
+                                 sp assertion-value sp "}"
+      component          = component-label msp StringValue
+      useDefaultValues   = use-defaults-label msp BooleanValue
+      rule               = rule-label msp ObjectIdentifierValue
+      assertion-value    = value-label msp Value
+
+      component-label    = %x63.6F.6D.70.6F.6E.65.6E.74  ; "component"
+      use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75
+                           %x65.73                  ; "useDefaultValues"
+      rule-label         = %x72.75.6C.65            ; "rule"
+      value-label        = %x76.61.6C.75.65         ; "value"
+
+      sp                 =  *%x20  ; zero, one or more space characters
+      msp                = 1*%x20  ; one or more space characters
+
+   The ABNF for <Value>, <StringValue>, <ObjectIdentifierValue> and
+   <BooleanValue> is defined by GSER [9].
+
+   The ABNF descriptions of LDAP-specific encodings for attribute
+   syntaxes typically do not clearly or consistently delineate the
+   component parts of an attribute value.  A regular and uniform
+   character string encoding for arbitrary component data types is
+   needed to encode the assertion value in a ComponentAssertion.  The
+   <Value> rule from GSER provides a human readable text encoding for a
+   component value of any arbitrary ASN.1 type.
+
+   The X.500-style definition [10] for componentFilterMatch is:
+
+      componentFilterMatch MATCHING-RULE ::= {
+          SYNTAX  ComponentFilter
+          ID      { 1 2 36 79672281 1 13 2 } }
+
+   A ComponentAssertion can potentially use any matching rule, including
+   componentFilterMatch, so componentFilterMatch may be nested.  The
+   component references in a nested componentFilterMatch are relative to
+
+
+
+
+
+Legg                        Standards Track                    [Page 23]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   the component corresponding to the containing ComponentAssertion.  In
+   Section 7, an example search on the seeAlso attribute shows this
+   usage.
+
+6.  Equality Matching of Complex Components
+
+   It is possible to test if an attribute value of a complex ASN.1
+   syntax is the same as some purported (i.e., assertion) value by using
+   a complicated ComponentFilter that tests if corresponding components
+   are the same.  However, it would be more convenient to be able to
+   present a whole assertion value to a matching rule that could do the
+   component-wise comparison of an attribute value with the assertion
+   value for any arbitrary attribute syntax.  Similarly, the ability to
+   do a straightforward equality comparison of a component value that is
+   itself of a complex ASN.1 type would also be convenient.
+
+   It would be difficult to define a single matching rule that
+   simultaneously satisfies all notions of what the equality matching
+   semantics should be.  For example, in some instances a case sensitive
+   comparison of string components may be preferable to a case
+   insensitive comparison.  Therefore a basic equality matching rule,
+   allComponentsMatch, is defined in Section 6.2, and the means to
+   derive new matching rules from it with slightly different equality
+   matching semantics are described in Section 6.3.
+
+   The directoryComponentsMatch defined in Section 6.4 is a derivation
+   of allComponentsMatch that suits typical uses of the directory.
+   Other specifications are free to derive new rules from
+   allComponentsMatch or directoryComponentsMatch, that suit their usage
+   of the directory.
+
+   The allComponentsMatch rule, the directoryComponentsMatch rule and
+   any matching rules derived from them are collectively called
+   component equality matching rules.
+
+6.1.  The OpenAssertionType Syntax
+
+   The component equality matching rules have a variable assertion
+   syntax.  In X.500 this is indicated by omitting the optional SYNTAX
+   field in the MATCHING-RULE information object.  The assertion syntax
+   then defaults to the target attribute's syntax in actual usage,
+   unless the description of the matching rule says otherwise.  The
+   SYNTAX field in the LDAP-specific encoding of a
+   MatchingRuleDescription is mandatory, so the OpenAssertionType syntax
+   is defined to fill the same role.  That is, the OpenAssertionType
+   syntax is semantically equivalent to an omitted SYNTAX field in an
+   X.500 MATCHING-RULE information object.  OpenAssertionType MUST NOT
+   be used as the attribute syntax in an attribute type definition.
+
+
+
+Legg                        Standards Track                    [Page 24]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   Unless explicitly varied by the description of a particular matching
+   rule, if an OpenAssertionType assertion value appears in a
+   ComponentAssertion its LDAP-specific encoding is described by the
+   <Value> rule in GSER [9], otherwise its LDAP-specific encoding is the
+   encoding defined for the syntax of the attribute type to which the
+   matching rule with the OpenAssertionType assertion syntax is applied.
+
+   The LDAP definition for the OpenAssertionType syntax is:
+
+      ( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )
+
+6.2.  The allComponentsMatch Matching Rule
+
+   The LDAP-style definition for allComponentsMatch is:
+
+      ( 1.2.36.79672281.1.13.6 NAME 'allComponentsMatch'
+          SYNTAX 1.2.36.79672281.1.5.3 )
+
+   The X.500-style definition for allComponentsMatch is:
+
+      allComponentsMatch MATCHING-RULE ::= {
+          ID      { 1 2 36 79672281 1 13 6 } }
+
+   When allComponentsMatch is used in a ComponentAssertion the assertion
+   syntax is the same as the ASN.1 type of the identified component.
+   Otherwise, the assertion syntax of allComponentsMatch is the same as
+   the attribute syntax of the attribute to which the matching rule is
+   applied.
+
+   Broadly speaking, this matching rule evaluates to true if and only if
+   corresponding components of the assertion value and the attribute or
+   component value are the same.
+
+   In detail, equality is determined by the following cases applied
+   recursively.
+
+   a) Two values of a SET or SEQUENCE type are the same if and only if,
+      for each component type, the corresponding component values are
+      either,
+
+      1) both absent,
+
+      2) both present and the same, or
+
+      3) absent or the same as the DEFAULT value for the component, if a
+         DEFAULT value is defined.
+
+
+
+
+
+Legg                        Standards Track                    [Page 25]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+         Values of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER
+         STRING, or INSTANCE OF type are compared according to their
+         respective associated SEQUENCE type (see Section 3.1.2).
+
+   b) Two values of a SEQUENCE OF type are the same if and only if, the
+      values have the same number of (possibly duplicated) instances and
+      corresponding instances are the same.
+
+   c) Two values of a SET OF type are the same if and only if, the
+      values have the same number of instances and each distinct
+      instance occurs in both values the same number of times, i.e.,
+      both values have the same instances, including duplicates, but in
+      any order.
+
+   d) Two values of a CHOICE type are the same if and only if, both
+      values are of the same chosen alternative and the component values
+      are the same.
+
+   e) Two BIT STRING values are the same if and only if the values have
+      the same number of bits and corresponding bits are the same.  If
+      the BIT STRING type is defined with a named bit list then trailing
+      zero bits in the values are treated as absent for the purposes of
+      this comparison.
+
+   f) Two BOOLEAN values are the same if and only if both are TRUE or
+      both are FALSE.
+
+   g) Two values of a string type are the same if and only if the values
+      have the same number of characters and corresponding characters
+      are the same.  Letter case is significant.  For the purposes of
+      allComponentsMatch, the string types are NumericString,
+      PrintableString, TeletexString (T61String), VideotexString,
+      IA5String, GraphicString, VisibleString (ISO646String),
+      GeneralString, UniversalString, BMPString, UTF8String,
+      GeneralizedTime, UTCTime and ObjectDescriptor.
+
+   h) Two INTEGER values are the same if and only if the integers are
+      equal.
+
+   i) Two ENUMERATED values are the same if and only if the enumeration
+      item identifiers are the same (equivalently, if the integer values
+      associated with the identifiers are equal).
+
+   j) Two NULL values are always the same, unconditionally.
+
+   k) Two OBJECT IDENTIFIER values are the same if and only if the
+      values have the same number of arcs and corresponding arcs are the
+      same.
+
+
+
+Legg                        Standards Track                    [Page 26]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   l) Two OCTET STRING values are the same if and only if the values
+      have the same number of octets and corresponding octets are the
+      same.
+
+   m) Two REAL values are the same if and only if they are both the same
+      special value, or neither is a special value and they have the
+      same base and represent the same real number.  The special values
+      for REAL are zero, PLUS-INFINITY and MINUS-INFINITY.
+
+   n) Two RELATIVE-OID values are the same if and only if the values
+      have the same number of arcs and corresponding arcs are the same.
+      The respective starting nodes for the RELATIVE-OID values are
+      disregarded in the comparison, i.e., they are assumed to be the
+      same.
+
+   o) Two values of an open type are the same if and only if both are of
+      the same ASN.1 type and are the same according to that type.  If
+      the actual ASN.1 type of the values is unknown then the
+      allComponentsMatch rule evaluates to Undefined.
+
+   Tags and constraints, being part of the type definition and not part
+   of the abstract values, are ignored for matching purposes.
+
+   The allComponentsMatch rule may be used as the defined equality
+   matching rule for an attribute.
+
+6.3.  Deriving Component Equality Matching Rules
+
+   A new component equality matching rule with more refined matching
+   semantics may be derived from allComponentsMatch, or any other
+   component equality matching rule, using the convention described in
+   this section.
+
+   The matching behaviour of a derived component equality matching rule
+   is specified by nominating, for each of one or more identified
+   components, a commutative equality matching rule that will be used to
+   match values of that component.  This overrides the matching that
+   would otherwise occur for values of that component using the base
+   rule for the derivation.  These overrides can be conveniently
+   represented as rows in a table of the following form.
+
+      Component   |  Matching Rule
+      ============+===============
+                  |
+                  |
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 27]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   Usually, all component values of a particular ASN.1 type are to be
+   matched the same way.  An ASN.1 type reference (e.g.,
+   DistinguishedName) or an ASN.1 built-in type name (e.g., INTEGER) in
+   the Component column of the table specifies that the nominated
+   equality matching rule is to be applied to all values of the named
+   type, regardless of context.
+
+   An ASN.1 type reference with a component reference appended
+   (separated by a ".")  specifies that the nominated matching rule
+   applies only to the identified components of values of the named
+   type.  Other component values that happen to be of the same ASN.1
+   type are not selected.
+
+   Additional type substitutions as described in Section 3.2 are assumed
+   to be performed to align the component type with the matching rule
+   assertion syntax.
+
+   Conceptually, the rows in a table for the base rule are appended to
+   the rows in the table for a derived rule for the purpose of deciding
+   the matching semantics of the derived rule.  Notionally,
+   allComponentsMatch has an empty table.
+
+   A row specifying values of an outer containing type (e.g.,
+   DistinguishedName) takes precedence over a row specifying values of
+   an inner component type (e.g., RelativeDistinguishedName), regardless
+   of their order in the table.  Specifying a row for component values
+   of an inner type is only useful if a value of the type can also
+   appear on its own, or as a component of values of a different outer
+   type.  For example, if there is a row for DistinguishedName then a
+   row for RelativeDistinguishedName can only ever apply to
+   RelativeDistinguishedName component values that are not part of a
+   DistinguishedName.  A row for values of an outer type in the table
+   for the base rule takes precedence over a row for values of an inner
+   type in the table for the derived rule.
+
+   Where more than one row applies to a particular component value the
+   earlier row takes precedence over the later row.  Thus rows in the
+   table for the derived rule take precedence over any rows for the same
+   component in the table for the base rule.
+
+6.4.  The directoryComponentsMatch Matching Rule
+
+   The directoryComponentsMatch matching rule is derived from the
+   allComponentsMatch matching rule.
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 28]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   The LDAP-style definition for directoryComponentsMatch is:
+
+      ( 1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch'
+          SYNTAX 1.2.36.79672281.1.5.3 )
+
+   The X.500-style definition for directoryComponentsMatch is:
+
+      directoryComponentsMatch MATCHING-RULE ::= {
+          ID      { 1 2 36 79672281 1 13 7 } }
+
+   The matching semantics of directoryComponentsMatch are described by
+   the following table, using the convention described in Section 6.3.
+
+      ASN.1 Type                               | Matching Rule
+      =========================================+========================
+      RDNSequence                              | distinguishedNameMatch
+      RelativeDistinguishedName                | rdnMatch
+      TelephoneNumber                          | telephoneNumberMatch
+      FacsimileTelephoneNumber.telephoneNumber | telephoneNumberMatch
+      NumericString                            | numericStringMatch
+      GeneralizedTime                          | generalizedTimeMatch
+      UTCTime                                  | uTCTimeMatch
+      DirectoryString{}                        | caseIgnoreMatch
+      BMPString                                | caseIgnoreMatch
+      GeneralString                            | caseIgnoreMatch
+      GraphicString                            | caseIgnoreMatch
+      IA5String                                | caseIgnoreMatch
+      PrintableString                          | caseIgnoreMatch
+      TeletexString                            | caseIgnoreMatch
+      UniversalString                          | caseIgnoreMatch
+      UTF8String                               | caseIgnoreMatch
+      VideotexString                           | caseIgnoreMatch
+      VisibleString                            | caseIgnoreMatch
+
+   Notes:
+
+   1) The DistinguishedName type is defined by assignment to be the same
+      as the RDNSequence type.  Some types (e.g., Name and LocalName)
+      directly reference RDNSequence rather than DistinguishedName.
+      Specifying RDNSequence captures all these DN-like types.
+
+   2) A RelativeDistinguishedName value is only matched by rdnMatch if
+      it is not part of an RDNSequence value.
+
+   3) The telephone number component of the FacsimileTelephoneNumber
+      ASN.1 type [12] is defined as a constrained PrintableString.
+      PrintableString component values that are part of a
+      FacsimileTelephoneNumber value can be identified separately from
+
+
+
+Legg                        Standards Track                    [Page 29]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+      other components of PrintableString type by the specifier
+      FacsimileTelephoneNumber.telephoneNumber, so that
+      telephoneNumberMatch can be selectively applied.  The fourth
+      edition of X.520 defines the telephoneNumber component of
+      FacsimileTelephoneNumber to be of the type TelephoneNumber, making
+      the row for FacsimileTelephoneNumber.telephoneNumber components
+      redundant.
+
+   The directoryComponentsMatch rule may be used as the defined equality
+   matching rule for an attribute.
+
+7.  Component Matching Examples
+
+   This section contains examples of search filters using the
+   componentFilterMatch matching rule.  The filters are described using
+   the string representation of LDAP search filters [18].  Note that
+   this representation requires asterisks to be escaped in assertion
+   values (in these examples the assertion values are all
+   <ComponentAssertion> encodings).  The asterisks have not been escaped
+   in these examples for the sake of clarity, and to avoid confusing the
+   protocol representation of LDAP search filter assertion values, where
+   such escaping does not apply.  Line breaks and indenting have been
+   added only as an aid to readability.
+
+   The example search filters using componentFilterMatch are all single
+   extensible match filter items, though there is no reason why
+   componentFilterMatch can't be used in more complicated search
+   filters.
+
+   The first examples describe searches over the objectClasses schema
+   operational attribute, which has an attribute syntax described by the
+   ASN.1 type ObjectClassDescription [10], and holds the definitions of
+   the object classes known to a directory server.  The definition of
+   ObjectClassDescription is as follows:
+
+      ObjectClassDescription ::= SEQUENCE {
+          identifier       OBJECT-CLASS.&id,
+          name             SET OF DirectoryString {ub-schema} OPTIONAL,
+          description      DirectoryString {ub-schema} OPTIONAL,
+          obsolete         BOOLEAN DEFAULT FALSE,
+          information  [0] ObjectClassInformation }
+
+      ObjectClassInformation ::= SEQUENCE {
+          subclassOf       SET OF OBJECT-CLASS.&id OPTIONAL,
+          kind             ObjectClassKind DEFAULT structural,
+          mandatories  [3] SET OF ATTRIBUTE.&id OPTIONAL,
+          optionals    [4] SET OF ATTRIBUTE.&id OPTIONAL }
+
+
+
+
+Legg                        Standards Track                    [Page 30]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+      ObjectClassKind ::= ENUMERATED {
+          abstract     (0),
+          structural   (1),
+          auxiliary    (2) }
+
+   OBJECT-CLASS.&id and ATTRIBUTE.&id are equivalent to the OBJECT
+   IDENTIFIER ASN.1 type.  A value of OBJECT-CLASS.&id is an OBJECT
+   IDENTIFIER for an object class.  A value of ATTRIBUTE.&id is an
+   OBJECT IDENTIFIER for an attribute type.
+
+   The following search filter finds the object class definition for the
+   object class identified by the OBJECT IDENTIFIER 2.5.6.18:
+
+      (objectClasses:componentFilterMatch:=
+           item:{ component "identifier",
+                  rule objectIdentifierMatch, value 2.5.6.18 })
+
+   A match on the "identifier" component of objectClasses values is
+   equivalent to the objectIdentifierFirstComponentMatch matching rule
+   applied to attribute values of the objectClasses attribute type.  The
+   componentFilterMatch matching rule subsumes the functionality of the
+   objectIdentifierFirstComponentMatch, integerFirstComponentMatch and
+   directoryStringFirstComponentMatch matching rules.
+
+   The following search filter finds the object class definition for the
+   object class called foobar:
+
+      (objectClasses:componentFilterMatch:=
+          item:{ component "name.*",
+                 rule caseIgnoreMatch, value "foobar" })
+
+   An object class definition can have multiple names and the above
+   filter will match an objectClasses value if any one of the names is
+   "foobar".
+
+   The component reference "name.0" identifies the notional count of the
+   number of names in an object class definition.  The following search
+   filter finds object class definitions with exactly one name:
+
+      (objectClasses:componentFilterMatch:=
+          item:{ component "name.0", rule integerMatch, value 1 })
+
+   The "description" component of an ObjectClassDescription is defined
+   to be an OPTIONAL DirectoryString.  The following search filter finds
+   object class definitions that have descriptions, regardless of the
+   contents of the description string:
+
+
+
+
+
+Legg                        Standards Track                    [Page 31]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+      (objectClasses:componentFilterMatch:=
+          item:{ component "description",
+                 rule presentMatch, value NULL })
+
+   The presentMatch returns TRUE if the description component is present
+   and FALSE otherwise.
+
+   The following search filter finds object class definitions that don't
+   have descriptions:
+
+      (objectClasses:componentFilterMatch:=
+          not:item:{ component "description",
+                     rule presentMatch, value NULL })
+
+   The following search filter finds object class definitions with the
+   word "bogus" in the description:
+
+      (objectClasses:componentFilterMatch:=
+          item:{ component "description",
+                 rule caseIgnoreSubstringsMatch,
+                 value { any:"bogus" } })
+
+   The assertion value is of the SubstringAssertion syntax, i.e.,
+
+      SubstringAssertion ::= SEQUENCE OF CHOICE {
+          initial      [0] DirectoryString {ub-match},
+          any          [1] DirectoryString {ub-match},
+          final        [2] DirectoryString {ub-match} }
+
+   The "obsolete" component of an ObjectClassDescription is defined to
+   be DEFAULT FALSE.  An object class is obsolete if the "obsolete"
+   component is present and set to TRUE.  The following search filter
+   finds all obsolete object classes:
+
+      (objectClasses:componentFilterMatch:=
+          item:{ component "obsolete", rule booleanMatch, value TRUE })
+
+   An object class is not obsolete if the "obsolete" component is not
+   present, in which case it defaults to FALSE, or is present but is
+   explicitly set to FALSE.  The following search filter finds all non-
+   obsolete object classes:
+
+      (objectClasses:componentFilterMatch:=
+          item:{ component "obsolete", rule booleanMatch, value FALSE })
+
+   The useDefaultValues flag in the ComponentAssertion defaults to TRUE
+   so the componentFilterMatch rule treats an absent "obsolete"
+   component as being present and set to FALSE.  The following search
+
+
+
+Legg                        Standards Track                    [Page 32]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   filter finds only object class definitions where the "obsolete"
+   component has been explicitly set to FALSE, rather than implicitly
+   defaulting to FALSE:
+
+      (objectClasses:componentFilterMatch:=
+          item:{ component "obsolete", useDefaultValues FALSE,
+                 rule booleanMatch, value FALSE })
+
+   With the useDefaultValues flag set to FALSE, if the "obsolete"
+   component is absent the component reference identifies no component
+   value and the matching rule will return FALSE.  The matching rule can
+   only return TRUE if the component is present and set to FALSE.
+
+   The "information.kind" component of the ObjectClassDescription is an
+   ENUMERATED type.  The allComponentsMatch matching rule can be used to
+   match values of an ENUMERATED type.  The following search filter
+   finds object class definitions for auxiliary object classes:
+
+      (objectClasses:componentFilterMatch:=
+          item:{ component "information.kind",
+                 rule allComponentsMatch, value auxiliary })
+
+   The following search filter finds auxiliary object classes with
+   commonName (cn or 2.5.4.3) as a mandatory attribute:
+
+      (objectClasses:componentFilterMatch:=and:{
+          item:{ component "information.kind",
+                 rule allComponentsMatch, value auxiliary },
+          item:{ component "information.mandatories.*",
+                 rule objectIdentifierMatch, value cn } })
+
+   The following search filter finds auxiliary object classes with
+   commonName as a mandatory or optional attribute:
+
+      (objectClasses:componentFilterMatch:=and:{
+          item:{ component "information.kind",
+                 rule allComponentsMatch, value auxiliary },
+          or:{
+              item:{ component "information.mandatories.*",
+                     rule objectIdentifierMatch, value cn },
+              item:{ component "information.optionals.*",
+                     rule objectIdentifierMatch, value cn } } })
+
+   Extra care is required when matching optional SEQUENCE OF or SET OF
+   components because of the distinction between an absent list of
+   instances and a present, but empty, list of instances.  The following
+   search filter finds object class definitions with less than three
+
+
+
+
+Legg                        Standards Track                    [Page 33]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   names, including object class definitions with a present but empty
+   list of names, but does not find object class definitions with an
+   absent list of names:
+
+      (objectClasses:componentFilterMatch:=
+          item:{ component "name.0",
+                 rule integerOrderingMatch, value 3 })
+
+   If the "name" component is absent the "name.0" component is also
+   considered to be absent and the ComponentAssertion evaluates to
+   FALSE.  If the "name" component is present, but empty, the "name.0"
+   component is also present and equal to zero, so the
+   ComponentAssertion evaluates to TRUE.  To also find the object class
+   definitions with an absent list of names the following search filter
+   would be used:
+
+      (objectClasses:componentFilterMatch:=or:{
+          not:item:{ component "name", rule presentMatch, value NULL },
+          item:{ component "name.0",
+                 rule integerOrderingMatch, value 3 } })
+
+   Distinguished names embedded in other syntaxes can be matched with a
+   componentFilterMatch.  The uniqueMember attribute type has an
+   attribute syntax described by the ASN.1 type NameAndOptionalUID.
+
+      NameAndOptionalUID ::= SEQUENCE {
+          dn        DistinguishedName,
+          uid       UniqueIdentifier OPTIONAL }
+
+   The following search filter finds values of the uniqueMember
+   attribute containing the author's DN:
+
+      (uniqueMember:componentFilterMatch:=
+          item:{ component "dn",
+                 rule distinguishedNameMatch,
+                 value "cn=Steven Legg,o=Adacel,c=AU" })
+
+   The DistinguishedName and RelativeDistinguishedName ASN.1 types are
+   also complex ASN.1 types so the component matching rules can be
+   applied to their inner components.
+
+      DistinguishedName   ::= RDNSequence
+
+      RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+      RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+          AttributeTypeAndValue
+
+
+
+
+Legg                        Standards Track                    [Page 34]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+      AttributeTypeAndValue ::= SEQUENCE {
+          type        AttributeType ({SupportedAttributes}),
+          value       AttributeValue ({SupportedAttributes}{@type}) }
+
+      AttributeType ::= ATTRIBUTE.&id
+
+      AttributeValue ::= ATTRIBUTE.&Type
+
+   ATTRIBUTE.&Type is an open type.  A value of ATTRIBUTE.&Type is
+   constrained by the type component of AttributeTypeAndValue to be of
+   the attribute syntax of the nominated attribute type.  Note: the
+   fourth edition of X.500 extends and renames the AttributeTypeAndValue
+   SEQUENCE type.
+
+   The seeAlso attribute has the DistinguishedName syntax.  The
+   following search filter finds seeAlso attribute values containing the
+   RDN, "o=Adacel", anywhere in the DN:
+
+      (seeAlso:componentFilterMatch:=
+          item:{ component "*", rule rdnMatch, value "o=Adacel" })
+
+   The following search filter finds all seeAlso attribute values with
+   "cn=Steven Legg" as the RDN of the named entry (i.e., the "first" RDN
+   in an LDAPDN or the "last" RDN in an X.500 DN):
+
+      (seeAlso:componentFilterMatch:=
+          item:{ component "-1",
+                 rule rdnMatch, value "cn=Steven Legg" })
+
+   The following search filter finds all seeAlso attribute values naming
+   entries in the DIT subtree of "o=Adacel,c=AU":
+
+      (seeAlso:componentFilterMatch:=and:{
+          item:{ component "1", rule rdnMatch, value "c=AU" },
+          item:{ component "2", rule rdnMatch, value "o=Adacel" } })
+
+   The following search filter finds all seeAlso attribute values
+   containing the naming attribute types commonName (cn) and
+   telephoneNumber in the same RDN:
+
+      (seeAlso:componentFilterMatch:=
+          item:{ component "*", rule componentFilterMatch,
+                 value and:{
+                     item:{ component "*.type",
+                            rule objectIdentifierMatch, value cn },
+                     item:{ component "*.type",
+                            rule objectIdentifierMatch,
+                            value telephoneNumber } } })
+
+
+
+Legg                        Standards Track                    [Page 35]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   The following search filter would find all seeAlso attribute values
+   containing the attribute types commonName and telephoneNumber, but
+   not necessarily in the same RDN:
+
+      (seeAlso:componentFilterMatch:=and:{
+          item:{ component "*.*.type",
+                 rule objectIdentifierMatch, value cn },
+          item:{ component "*.*.type",
+                 rule objectIdentifierMatch, value telephoneNumber } })
+
+   The following search filter finds all seeAlso attribute values
+   containing the word "Adacel" in any organizationalUnitName (ou)
+   attribute value in any AttributeTypeAndValue of any RDN:
+
+      (seeAlso:componentFilterMatch:=
+          item:{ component "*.*.value.(2.5.4.11)",
+                 rule caseIgnoreSubstringsMatch,
+                 value { any:"Adacel" } })
+
+   The component reference "*.*.value" identifies an open type, in this
+   case an attribute value.  In a particular AttributeTypeAndValue, if
+   the attribute type is not organizationalUnitName then the
+   ComponentAssertion evaluates to FALSE.  Otherwise the substring
+   assertion is evaluated against the attribute value.
+
+   Absent component references in ComponentAssertions can be exploited
+   to avoid false positive matches on multi-valued attributes.  For
+   example, suppose there is a multi-valued attribute named
+   productCodes, defined to have the Integer syntax
+   (1.3.6.1.4.1.1466.115.121.1.27).  Consider the following search
+   filter:
+
+      (&(!(productCodes:integerOrderingMatch:=3))
+        (productCodes:integerOrderingMatch:=8))
+
+   An entry whose productCodes attribute contains only the values 1 and
+   10 will match the above filter.  The first subfilter is satisfied by
+   the value 10 (10 is not less than 3), and the second subfilter is
+   satisfied by the value 1 (1 is less than 8).  The following search
+   filter can be used instead to only match entries that have a
+   productCodes value in the range 3 to 7, because the ComponentFilter
+   is evaluated against each productCodes value in isolation:
+
+      (productCodes:componentFilterMatch:= and:{
+           not:item:{ rule integerOrderingMatch, value 3 },
+          item:{ rule integerOrderingMatch, value 8 } })
+
+
+
+
+
+Legg                        Standards Track                    [Page 36]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   An entry whose productCodes attribute contains only the values 1 and
+   10 will not match the above filter.
+
+8.  Security Considerations
+
+   The component matching rules described in this document allow for a
+   compact specification of matching capabilities that could otherwise
+   have been defined by a plethora of specific matching rules, i.e.,
+   despite their expressiveness and flexibility the component matching
+   rules do not behave in a way uncharacteristic of other matching
+   rules, so the security issues for component matching rules are no
+   different than for any other matching rule.  However, because the
+   component matching rules are applicable to any attribute syntax,
+   support for them in a directory server may allow searching of
+   attributes that were previously unsearchable by virtue of there not
+   being a suitable matching rule.  Such attribute types ought to be
+   properly protected with appropriate access controls.  A generic,
+   interoperable access control mechanism has not yet been developed,
+   however, and implementors should be aware of the interaction of that
+   lack with the increased risk of exposure described above.
+
+9.  Acknowledgements
+
+   The author would like to thank Tom Gindin for private email
+   discussions that clarified and refined the ideas presented in this
+   document.
+
+10.  IANA Considerations
+
+   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+   descriptors registry [8] as indicated by the following templates:
+
+      Subject: Request for LDAP Descriptor Registration
+      Descriptor (short name): componentFilterMatch
+      Object Identifier: 1.2.36.79672281.1.13.2
+      Person & email address to contact for further information:
+        Steven Legg <steven.legg@adacel.com.au>
+      Usage: other (matching rule)
+      Specification: RFC 3687
+      Author/Change Controller: IESG
+
+
+
+
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 37]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+      Subject: Request for LDAP Descriptor Registration
+      Descriptor (short name): rdnMatch
+      Object Identifier: 1.2.36.79672281.1.13.3
+      Person & email address to contact for further information:
+        Steven Legg <steven.legg@adacel.com.au>
+      Usage: other (matching rule)
+      Specification: RFC 3687
+      Author/Change Controller: IESG
+
+      Subject: Request for LDAP Descriptor Registration
+      Descriptor (short name): presentMatch
+      Object Identifier: 1.2.36.79672281.1.13.5
+      Person & email address to contact for further information:
+        Steven Legg <steven.legg@adacel.com.au>
+      Usage: other (matching rule)
+      Specification: RFC 3687
+      Author/Change Controller: IESG
+
+      Subject: Request for LDAP Descriptor Registration
+      Descriptor (short name): allComponentsMatch
+      Object Identifier: 1.2.36.79672281.1.13.6
+      Person & email address to contact for further information:
+        Steven Legg <steven.legg@adacel.com.au>
+      Usage: other (matching rule)
+      Specification: RFC 3687
+      Author/Change Controller: IESG
+
+      Subject: Request for LDAP Descriptor Registration
+      Descriptor (short name): directoryComponentsMatch
+      Object Identifier: 1.2.36.79672281.1.13.7
+      Person & email address to contact for further information:
+        Steven Legg <steven.legg@adacel.com.au>
+      Usage: other (matching rule)
+      Specification: RFC 3687
+      Author/Change Controller: IESG
+
+   The object identifiers have been assigned for use in this
+   specification by Adacel Technologies, under an arc assigned to Adacel
+   by Standards Australia.
+
+11.  References
+
+11.1.  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Legg                        Standards Track                    [Page 38]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   [2]   Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+         Specifications: ABNF", RFC 2234, November 1997.
+
+   [3]   Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+         Protocol (v3)", RFC 2251, December 1997.
+
+   [4]   Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+         Directory Access Protocol (v3): Attribute Syntax Definitions",
+         RFC 2252, December 1997.
+
+   [5]   Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
+         Protocol (v3): UTF-8 String Representation of Distinguished
+         Names", RFC 2253, December 1997.
+
+   [6]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
+         63, RFC 3629, November 2003.
+
+   [7]   Hodges, J. and R. Morgan, "Lightweight Directory Access
+         Protocol (v3): Technical Specification", RFC 3377, September
+         2002.
+
+   [8]   Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+         Considerations for the Lightweight Directory Access Protocol
+         (LDAP)", BCP 64, RFC 3383, September 2002.
+
+   [9]   Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+         Types", RFC 3641, October 2003.
+
+   [10]  ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+         Information Technology - Open Systems Interconnection - The
+         Directory: Models
+
+   [11]  ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
+         Information Technology - Open Systems Interconnection - The
+         Directory: Authentication Framework
+
+   [12]  ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
+         Information technology - Open Systems Interconnection - The
+         Directory: Selected attribute types
+
+   [13]  ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
+         Information technology - Abstract Syntax Notation One (ASN.1):
+         Specification of basic notation
+
+   [14]  ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2:2002,
+         Information technology - Abstract Syntax Notation One (ASN.1):
+         Information object specification
+
+
+
+
+Legg                        Standards Track                    [Page 39]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+   [15]  ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3:2002,
+         Information technology - Abstract Syntax Notation One (ASN.1):
+         Constraint specification
+
+   [16]  ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4:2002,
+         Information technology - Abstract Syntax Notation One (ASN.1):
+         Parameterization of ASN.1 specifications
+
+   [17]  ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
+         Information technology - ASN.1 encoding rules: Specification of
+         Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
+         Distinguished Encoding Rules (DER)
+
+12.2.  Informative References
+
+   [18]  Howes, T., "The String Representation of LDAP Search Filters",
+         RFC 2254, December 1997.
+
+   [19]  ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+         Information Technology - Open Systems Interconnection - The
+         Directory: Overview of concepts, models and services
+
+12.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 40]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+13.  Author's Address
+
+   Steven Legg
+   Adacel Technologies Ltd.
+   250 Bay Street
+   Brighton, Victoria 3186
+   AUSTRALIA
+
+   Phone: +61 3 8530 7710
+   Fax:   +61 3 8530 7888
+   EMail: steven.legg@adacel.com.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 41]
+\f
+RFC 3687        LDAP and X.500 Component Matching Rules    February 2004
+
+
+14.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 42]
+\f
diff --git a/doc/rfc/rfc3698.txt b/doc/rfc/rfc3698.txt
new file mode 100644 (file)
index 0000000..0062ade
--- /dev/null
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                   K. Zeilenga, Ed.
+Request for Comments: 3698                           OpenLDAP Foundation
+Updates: 2798                                              February 2004
+Category: Standards Track
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                       Additional 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
+
+   This document provides a collection of matching rules for use with
+   the Lightweight Directory Access Protocol (LDAP).  As these matching
+   rules are simple adaptations of matching rules specified for use with
+   the X.500 Directory, most are already in wide use.
+
+Table of Contents
+
+   1.  Background and Intended Use. . . . . . . . . . . . . . . . . .  2
+   2.  Matching Rules . . . . . . . . . . . . . . . . . . . . . . . .  2
+       2.1.  booleanMatch . . . . . . . . . . . . . . . . . . . . . .  2
+       2.2.  caseExactMatch . . . . . . . . . . . . . . . . . . . . .  2
+       2.3.  caseExactOrderingMatch . . . . . . . . . . . . . . . . .  3
+       2.4.  caseExactSubstringsMatch . . . . . . . . . . . . . . . .  3
+       2.5.  caseIgnoreListSubstringsMatch. . . . . . . . . . . . . .  3
+       2.6.  directoryStringFirstComponentMatch . . . . . . . . . . .  4
+       2.7.  integerOrderingMatch . . . . . . . . . . . . . . . . . .  4
+       2.8.  keywordMatch . . . . . . . . . . . . . . . . . . . . . .  4
+       2.9.  numericStringOrderingMatch . . . . . . . . . . . . . . .  5
+       2.10. octetStringOrderingMatch . . . . . . . . . . . . . . . .  5
+       2.11. storedPrefixMatch. . . . . . . . . . . . . . . . . . . .  5
+       2.12. wordMatch. . . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  Security Considerations. . . . . . . . . . . . . . . . . . . .  6
+   4.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  7
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+\f
+RFC 3698            LDAP: Additional Matching Rules        February 2004
+
+
+       6.1.  Normative References . . . . . . . . . . . . . . . . . .  7
+       6.2.  Informative References . . . . . . . . . . . . . . . . .  7
+   7.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
+   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  9
+
+1.  Background and Intended Use
+
+   This document adapts additional X.500 Directory [X.500] matching
+   rules [X.520] for use with the Lightweight Directory Access Protocol
+   (LDAP) [RFC3377].  Most of these rules are widely used today on the
+   Internet, such as in support of the inetOrgPerson [RFC2798] and
+   Policy Core Information Model [RFC3703] LDAP schemas.  The rules are
+   applicable to many other applications.
+
+   This document supersedes the informational matching rules
+   descriptions provided in RFC 2798 that are now provided in this
+   document.  Specifically, section 2 of this document replaces section
+   9.3.3 of RFC 2798.
+
+   Schema definitions are provided using LDAP description formats
+   [RFC2252].  Definitions provided here are formatted (line wrapped)
+   for readability.
+
+2.  Matching Rules
+
+2.1.  booleanMatch
+
+   The booleanMatch rule compares for equality a asserted Boolean value
+   with an attribute value of BOOLEAN syntax.  The rule returns TRUE if
+   and only if the values are the same, i.e., both are TRUE or both are
+   FALSE.  (Source: X.520)
+
+       ( 2.5.13.13 NAME 'booleanMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
+
+   The BOOLEAN (1.3.6.1.4.1.1466.115.121.1.7) syntax is described in
+   [RFC2252].
+
+2.2.  caseExactMatch
+
+   The caseExactMatch rule compares for equality the asserted value with
+   an attribute value of DirectoryString syntax.  The rule is identical
+   to the caseIgnoreMatch [RFC2252] rule except that case is not
+   ignored.  (Source: X.520)
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+\f
+RFC 3698            LDAP: Additional Matching Rules        February 2004
+
+
+       ( 2.5.13.5 NAME 'caseExactMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+   described in [RFC2252].
+
+2.3.  caseExactOrderingMatch
+
+   The caseExactOrderingMatch rule compares the collation order of the
+   asserted string with an attribute value of DirectoryString syntax.
+   The rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule
+   except that letters are not folded.  (Source: X.520)
+
+       ( 2.5.13.6 NAME 'caseExactOrderingMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+   described in [RFC2252].
+
+2.4.  caseExactSubstringsMatch
+
+   The caseExactSubstringsMatch rule determines whether the asserted
+   value(s) are substrings of an attribute value of DirectoryString
+   syntax.  The rule is identical to the caseIgnoreSubstringsMatch
+   [RFC2252] rule except that case is not ignored.  (Source: X.520)
+
+       ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is
+   described in [RFC2252].
+
+2.5. caseIgnoreListSubstringsMatch
+
+   The caseIgnoreListSubstringMatch rule compares the asserted substring
+   with an attribute value which is a sequence of DirectoryStrings, but
+   where the case (upper or lower) is not significant for comparison
+   purposes.  The asserted value matches a stored value if and only if
+   the asserted value matches the string formed by concatenating the
+   strings of the stored value.  This matching is done according to the
+   caseIgnoreSubstringsMatch [RFC2252] rule; however, none of the
+   initial, any, or final values of the asserted value are considered to
+   match a substring of the concatenated string which spans more than
+   one of the strings of the stored value.  (Source: X.520)
+
+       ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+\f
+RFC 3698            LDAP: Additional Matching Rules        February 2004
+
+
+   The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is
+   described in [RFC2252].
+
+2.6.  directoryStringFirstComponentMatch
+
+   The directoryStringFirstComponentMatch rule compares for equality the
+   asserted DirectoryString value with an attribute value of type
+   SEQUENCE whose first component is mandatory and of type
+   DirectoryString.  The rule returns TRUE if and only if the attribute
+   value has a first component whose value matches the asserted
+   DirectoryString using the rules of caseIgnoreMatch [RFC2252].  A
+   value of the assertion syntax is derived from a value of the
+   attribute syntax by using the value of the first component of the
+   SEQUENCE.  (Source: X.520)
+
+       ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+   described in [RFC2252].
+
+2.7.  integerOrderingMatch
+
+   The integerOrderingMatch rule compares the ordering of the asserted
+   integer with an attribute value of INTEGER syntax.  The rule returns
+   True if the attribute value is less than the asserted value. (Source:
+   X.520)
+
+       ( 2.5.13.15 NAME 'integerOrderingMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+   The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is described in
+   [RFC2252].
+
+2.8.  keywordMatch
+
+   The keywordMatch rule compares the asserted string with keywords in
+   an attribute value of DirectoryString syntax.  The rule returns TRUE
+   if and only if the asserted value matches any keyword in the
+   attribute value.  The identification of keywords in an attribute
+   value and of the exactness of match are both implementation specific.
+   (Source: X.520)
+
+       ( 2.5.13.33 NAME 'keywordMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+   described in [RFC2252].
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+\f
+RFC 3698            LDAP: Additional Matching Rules        February 2004
+
+
+2.9.  numericStringOrderingMatch
+
+   The numericStringOrderingMatch rule compares the collation order of
+   the asserted string with an attribute value of NumericString syntax.
+   The rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule
+   except that all space characters are skipped during comparison (case
+   is irrelevant as characters are numeric).  (Source: X.520)
+
+       ( 2.5.13.9 NAME 'numericStringOrderingMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+   The NumericString (1.3.6.1.4.1.1466.115.121.1.36) syntax is described
+   in [RFC2252].
+
+2.10.  octetStringOrderingMatch
+
+   The octetStringOrderingMatch rule compares the collation order of the
+   asserted octet string with an attribute value of OCTET STRING syntax.
+   The rule compares octet strings from first octet to 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 are identical but contain different numbers of octets, the
+   shorter string precedes the longer string.  (Source: X.520)
+
+       ( 2.5.13.18 NAME 'octetStringOrderingMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+   The OCTET STRING (1.3.6.1.4.1.1466.115.121.1.40) syntax is described
+   in [RFC2252].
+
+2.11.  storedPrefixMatch
+
+   The storedPrefixMatch rule determines whether an attribute value,
+   whose syntax is DirectoryString is a prefix (i.e., initial substring)
+   of the asserted value, without regard to the case (upper or lower) of
+   the strings.  The rule returns TRUE if and only if the attribute
+   value is an initial substring of the asserted value with
+   corresponding characters identical except possibly with regard to
+   case.  (Source: X.520)
+
+       ( 2.5.13.41 NAME 'storedPrefixMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+\f
+RFC 3698            LDAP: Additional Matching Rules        February 2004
+
+
+   Note: This rule can be used, for example, to compare values in the
+         Directory which are telephone area codes with a purported value
+         which is a telephone number.
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+   described in [RFC2252].
+
+2.12.  wordMatch
+
+   The wordMatch rule compares the asserted string with words in an
+   attribute value of DirectoryString syntax.  The rule returns TRUE if
+   and only if the asserted word matches any word in the attribute
+   value.  Individual word matching is as for the caseIgnoreMatch
+   [RFC2252] matching rule.  The precise definition of a "word" is
+   implementation specific.  (Source: X.520)
+
+       ( 2.5.13.32 NAME 'wordMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+   described in [RFC2252].
+
+3.  Security Considerations
+
+   General LDAP security considerations [RFC3377] is applicable to the
+   use of this schema.  Additional considerations are noted above where
+   appropriate.
+
+4.  IANA Considerations
+
+   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+   descriptors registry [RFC3383] as indicated in the following
+   template:
+
+       Subject: Request for LDAP Descriptor Registration Update
+       Descriptor (short name): see comment
+       Object Identifier: see comments
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Usage: see comments
+       Specification: RFC 3698
+       Author/Change Controller: IESG
+       Comments:
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+\f
+RFC 3698            LDAP: Additional Matching Rules        February 2004
+
+
+       The following descriptors have been added:
+
+         NAME                               Type OID
+         ------------------------           ---- ---------
+         booleanMatch                       M    2.5.13.13
+         caseExactMatch                     M    2.5.13.5
+         caseExactOrderingMatch             M    2.5.13.6
+         caseExactSubstringsMatch           M    2.5.13.7
+         caseIgnoreListSubstringsMatch      M    2.5.13.12
+         directoryStringFirstComponentMatch M    2.5.13.31
+         integerOrderingMatch               M    2.5.13.15
+         keywordMatch                       M    2.5.13.33
+         numericStringOrderingMatch         M    2.5.13.9
+         octetStringOrderingMatch           M    2.5.13.18
+         storedPrefixMatch                  M    2.5.13.41
+         wordMatch                          M    2.5.13.32
+
+       where Type M is Matching Rule.
+
+   This document makes no new OID assignments.  It only associates LDAP
+   matching rule descriptions with existing X.500 matching rules.
+
+5.  Acknowledgments
+
+   This document borrows from [X.520], an ITU-T Recommendation.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2252]     Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+                 "Lightweight Directory Access Protocol (v3):  Attribute
+                 Syntax Definitions", RFC 2252, December 1997.
+
+   [RFC3377]     Hodges, J. and R. Morgan, "Lightweight Directory Access
+                 Protocol (v3): Technical Specification", RFC 3377,
+                 September 2002.
+
+6.2.  Informative References
+
+   [RFC2798]     Smith, M., "The LDAP inetOrgPerson Object Class", RFC
+                 2798, April 2000.
+
+   [RFC3383]     Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+                 RFC 3383, September 2002.
+
+   [RFC3703]     Strassner, J., Moore, B., Moats, R. and E. Ellesson,
+                 "Policy Core LDAP Schema", RFC 3703, February 2004.
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+\f
+RFC 3698            LDAP: Additional Matching Rules        February 2004
+
+
+   [X.500]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Overview of concepts, models and
+                 services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+   [X.520]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory: Selected Attribute Types", X.520(1997).
+
+7.  Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+\f
+RFC 3698            LDAP: Additional Matching Rules        February 2004
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed
+   to pertain to the implementation or use of the technology
+   described in this document or the extent to which any license
+   under such rights might or might not be available; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 9]
+\f
diff --git a/doc/rfc/rfc3712.txt b/doc/rfc/rfc3712.txt
new file mode 100644 (file)
index 0000000..f5bb966
--- /dev/null
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group                                         P. Fleming
+Request for Comments: 3712                                           IBM
+Category: Informational                                      I. McDonald
+                                                              High North
+                                                           February 2004
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                      Schema for Printer Services
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document defines a schema, object classes and attributes, for
+   printers and printer services, for use with directories that support
+   Lightweight Directory Access Protocol v3 (LDAP-TS).  This document is
+   based on the printer attributes listed in Appendix E of Internet
+   Printing Protocol/1.1 (IPP) (RFC 2911).  A few additional printer
+   attributes are based on definitions in the Printer MIB (RFC 1759).
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Rationale for using DirectoryString Syntax . . . . . . .  3
+       1.2.  Rationale for using caseIgnoreMatch. . . . . . . . . . .  4
+       1.3.  Rationale for using caseIgnoreSubstringsMatch. . . . . .  5
+   2.  Terminology and Conventions. . . . . . . . . . . . . . . . . .  5
+   3.  Definition of Object Classes . . . . . . . . . . . . . . . . .  6
+       3.1.  slpServicePrinter. . . . . . . . . . . . . . . . . . . .  6
+       3.2.  printerAbstract. . . . . . . . . . . . . . . . . . . . .  7
+       3.3.  printerService . . . . . . . . . . . . . . . . . . . . .  8
+       3.4.  printerServiceAuxClass . . . . . . . . . . . . . . . . .  8
+       3.5.  printerIPP . . . . . . . . . . . . . . . . . . . . . . .  8
+       3.6.  printerLPR . . . . . . . . . . . . . . . . . . . . . . .  9
+   4.  Definition of Attribute Types. . . . . . . . . . . . . . . . .  9
+       4.1.  printer-uri. . . . . . . . . . . . . . . . . . . . . . . 11
+       4.2.  printer-xri-supported. . . . . . . . . . . . . . . . . . 11
+       4.3.  printer-name . . . . . . . . . . . . . . . . . . . . . . 13
+       4.4.  printer-natural-language-configured. . . . . . . . . . . 13
+
+
+
+Fleming & McDonald           Informational                      [Page 1]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+       4.5.  printer-location . . . . . . . . . . . . . . . . . . . . 14
+       4.6.  printer-info . . . . . . . . . . . . . . . . . . . . . . 14
+       4.7.  printer-more-info. . . . . . . . . . . . . . . . . . . . 14
+       4.8.  printer-make-and-model . . . . . . . . . . . . . . . . . 15
+       4.9.  printer-ipp-versions-supported . . . . . . . . . . . . . 15
+       4.10. printer-multiple-document-jobs-supported . . . . . . . . 16
+       4.11. printer-charset-configured . . . . . . . . . . . . . . . 16
+       4.12. printer-charset-supported. . . . . . . . . . . . . . . . 16
+       4.13. printer-generated-natural-language-supported . . . . . . 17
+       4.14. printer-document-format-supported. . . . . . . . . . . . 17
+       4.15. printer-color-supported. . . . . . . . . . . . . . . . . 18
+       4.16. printer-compression-supported. . . . . . . . . . . . . . 18
+       4.17. printer-pages-per-minute . . . . . . . . . . . . . . . . 18
+       4.18. printer-pages-per-minute-color . . . . . . . . . . . . . 19
+       4.19. printer-finishings-supported . . . . . . . . . . . . . . 19
+       4.20. printer-number-up-supported. . . . . . . . . . . . . . . 19
+       4.21. printer-sides-supported. . . . . . . . . . . . . . . . . 20
+       4.22. printer-media-supported. . . . . . . . . . . . . . . . . 20
+       4.23. printer-media-local-supported. . . . . . . . . . . . . . 20
+       4.24. printer-resolution-supported . . . . . . . . . . . . . . 21
+       4.25. printer-print-quality-supported. . . . . . . . . . . . . 22
+       4.26. printer-job-priority-supported . . . . . . . . . . . . . 22
+       4.27. printer-copies-supported . . . . . . . . . . . . . . . . 22
+       4.28. printer-job-k-octets-supported . . . . . . . . . . . . . 23
+       4.29. printer-current-operator . . . . . . . . . . . . . . . . 23
+       4.30. printer-service-person . . . . . . . . . . . . . . . . . 24
+       4.31. printer-delivery-orientation-supported . . . . . . . . . 24
+       4.32. printer-stacking-order-supported . . . . . . . . . . . . 24
+       4.33. printer-output-features-supported. . . . . . . . . . . . 25
+       4.34. printer-aliases. . . . . . . . . . . . . . . . . . . . . 25
+   5.  Definition of Syntaxes . . . . . . . . . . . . . . . . . . . . 26
+   6.  Definition of Matching Rules . . . . . . . . . . . . . . . . . 26
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
+       7.1.  Registration of Object Classes . . . . . . . . . . . . . 26
+       7.2.  Registration of Attribute Types. . . . . . . . . . . . . 27
+   8.  Internationalization Considerations. . . . . . . . . . . . . . 28
+   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 29
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+       10.1. Normative References . . . . . . . . . . . . . . . . . . 29
+       10.2. Informative References . . . . . . . . . . . . . . . . . 30
+   11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 32
+   12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
+   13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
+
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                      [Page 2]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+1.  Introduction
+
+   This document defines several object classes to provide Lightweight
+   Directory Access Protocol v3 [LDAP-TS] applications with flexible
+   options in defining printer information using LDAP schema.  Classes
+   are provided for defining directory entries with common printer
+   information as well as for extending existing directory entries with
+   SLPv2 [RFC2608], IPP/1.1 [RFC2911], and LPR [RFC1179] specific
+   information.
+
+   The schema defined in this document is based on the printer
+   attributes listed in Appendix E 'Generic Directory Schema' of
+   Internet Printing Protocol/1.1 (IPP) [RFC2911].  A few additional
+   printer attributes are based on definitions in the Printer MIB
+   [RFC1759].
+
+   The schema defined in this document is technically aligned with the
+   stable IANA-registered 'service:printer:' v2.0 template [SLP-PRT],
+   for compatibility with already deployed Service Location Protocol
+   (SLPv2) [RFC2608] service advertising and discovery infrastructure.
+   The attribute syntaxes are technically aligned with the
+   'service:printer:' v2.0 template - therefore simpler types are
+   sometimes used (for example, 'DirectoryString' [RFC2252] rather than
+   'labeledURI' [RFC2079] for the 'printer-uri' attribute).
+
+   Please send comments directly to the authors at the addresses listed
+   in Section 13 "Authors' Addresses".
+
+1.1.  Rationale for using DirectoryString Syntax
+
+   The attribute syntax 'DirectoryString' (UTF-8 [RFC2279]) defined in
+   [RFC2252] is specified for several groups of string attributes that
+   are defined in this document:
+
+   1)  URI
+       - printer-uri, printer-xri-supported, printer-more-info
+
+       The UTF-8 encoding is forward compatible with any future
+       deployment of (UTF-8 based) IRI (Internationalized Resource
+       Identifiers) [W3C-IRI] currently being developed by the W3C
+       Internationalization Working Group.
+
+   2)  Description
+       - printer-name, printer-location, printer-info,
+       printer-make-and-model
+
+
+
+
+
+
+Fleming & McDonald           Informational                      [Page 3]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+       The UTF-8 encoding supports descriptions in any language,
+       conformant with the "IETF Policy on Character Sets and Languages"
+       [RFC2277].
+
+       Note:  The printer-natural-language-configured attribute contains
+       a language tag [RFC3066] for these description attributes (for
+       example, to support text-to-speech conversions).
+
+   3)  Keyword
+       - printer-compression-supported, printer-finishings-supported,
+       printer-media-supported, printer-media-local-supported,
+       printer-print-quality-supported
+
+       The UTF-8 encoding is compatible with the current IPP/1.1
+       [RFC2911] definition of the equivalent attributes, most of which
+       have the IPP/1.1 union syntax 'keyword or name'.  The keyword
+       attributes defined in this document are extensible by
+       site-specific or vendor-specific 'names' which behave like new
+       'keywords'
+
+       Note:  In IPP/1.1, each value is strongly typed over-the-wire as
+       either 'keyword' or 'name'.  This union selector is not preserved
+       in the definitions of these equivalent LDAP attributes.
+
+1.2.  Rationale for using caseIgnoreMatch
+
+   The EQUALITY matching rule 'caseIgnoreMatch' defined in [RFC2252] is
+   specified for several groups of string attributes that are defined in
+   this document:
+
+   1)  URI
+
+       These URI attributes specify EQUALITY matching with
+       'caseIgnoreMatch' (rather than with 'caseExactMatch') in order to
+       conform to the spirit of [RFC2396], which requires case
+       insensitive matching on the host part of a URI versus case
+       sensitive matching on the remainder of a URI.
+
+       These URI attributes follow existing practice of supporting case
+       insensitive equality matching for host names in the
+       associatedDomain attribute defined in [RFC1274].
+
+       Either equality matching rule choice would be a compromise:
+       a) case sensitive whole URI matching may lead to false negative
+       matches and has been shown to be fragile (given deployed client
+       applications that 'pretty up' host names displayed and
+       transferred in URI);
+
+
+
+
+Fleming & McDonald           Informational                      [Page 4]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+       b) case insensitive whole URI matching may lead to false positive
+       matches, although it is a dangerous practice to publish URI that
+       differ only by case (for example, in the path elements).
+
+   2)  Description
+
+       Case insensitive equality matching is more user-friendly for
+       description attributes.
+
+   3)  Keyword
+
+       Case insensitive equality matching is more user-friendly for
+       keyword attributes.
+
+1.3.  Rationale for using caseIgnoreSubstringsMatch
+
+   The SUBSTR matching rule 'caseIgnoreSubstringsMatch' defined in
+   [RFC2252] is specified for several groups of string attributes that
+   are defined in this document:
+
+   1)  URI
+
+       These URI attributes follow existing practice of supporting case
+       insensitive equality matching for host names in the
+       associatedDomain attribute defined in [RFC1274].
+
+   2)  Description
+
+       Support for case insensitive substring matching is more
+       user-friendly for description attributes.
+
+   3)  Keyword
+
+       Support for case insensitive substring matching is more
+       user-friendly for keyword attributes.
+
+2.  Terminology and Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+   Schema definitions are provided using LDAPv3 [LDAP-TS] description
+   formats.  Definitions provided here are formatted (line wrapped) for
+   readability.
+
+
+
+
+
+
+Fleming & McDonald           Informational                      [Page 5]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+3.  Definition of Object Classes
+
+   We define the following LDAP object classes for use with both generic
+   printer related information and services specific to SLPv2 [RFC2608],
+   IPP/1.1 [RFC2911], and LPR [RFC1179].
+
+   slpServicePrinter - auxiliary class for SLP registered printers
+   printerAbstract - abstract class for all printer classes
+   printerService - structural class for printers
+   printerServiceAuxClass - auxiliary class for printers
+   printerIPP - auxiliary class for IPP printers
+   printerLPR - auxiliary class for LPR printers
+
+   The following are some examples of how applications may choose to use
+   these classes when creating directory entries:
+
+   1)  Use printerService for directory entries containing common
+       printer information.
+
+   2)  Use both printerService and slpServicePrinter for directory
+       entries containing common printer information for SLP registered
+       printers.
+
+   3)  Use printerService, printerLPR and printerIPP for directory
+       entries containing common printer information for printers that
+       support both LPR and IPP.
+
+   4)  Use printerServiceAuxClass and object classes not defined by this
+       document for directory entries containing common printer
+       information.  In this example, printerServiceAuxClass is used for
+       extending other structural classes defining printer information
+       with common printer information defined in this document.
+
+   Refer to Section 4 for definition of attribute types referenced by
+   these object classes.  We use attribute names instead of OIDs in
+   object class definitions for clarity.  Some attribute names described
+   in [RFC2911] have been prefixed with 'printer-' as recommended in
+   [RFC2926] and [SLP-PRT].
+
+3.1.  slpServicePrinter
+
+   ( 1.3.18.0.2.6.254
+   NAME  'slpServicePrinter'
+   DESC  'Service Location Protocol (SLP) information.'
+   AUXILIARY
+   SUP   slpService
+   )
+
+
+
+
+Fleming & McDonald           Informational                      [Page 6]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   This auxiliary class defines Service Location Protocol (SLPv2)
+   [RFC2608] specific information.  It should be used with a structural
+   class such as printerService.  It may be used to create new or extend
+   existing directory entries with SLP 'service:printer' abstract
+   service type information as defined in [SLP-PRT].  This object class
+   is derived from 'slpService', the parent class for all SLP services,
+   defined in [RFC2926].
+
+3.2.  printerAbstract
+
+   ( 1.3.18.0.2.6.258
+   NAME  'printerAbstract'
+   DESC  'Printer related information.'
+   ABSTRACT
+   SUP   top
+   MAY   ( printer-name $
+           printer-natural-language-configured $
+           printer-location $ printer-info $ printer-more-info $
+           printer-make-and-model $
+           printer-multiple-document-jobs-supported $
+           printer-charset-configured $ printer-charset-supported $
+           printer-generated-natural-language-supported $
+           printer-document-format-supported $ printer-color-supported $
+           printer-compression-supported $ printer-pages-per-minute $
+           printer-pages-per-minute-color $
+           printer-finishings-supported $ printer-number-up-supported $
+           printer-sides-supported $ printer-media-supported $
+           printer-media-local-supported $
+           printer-resolution-supported $
+           printer-print-quality-supported $
+           printer-job-priority-supported $ printer-copies-supported $
+           printer-job-k-octets-supported $ printer-current-operator $
+           printer-service-person $
+           printer-delivery-orientation-supported $
+           printer-stacking-order-supported $
+           printer-output-features-supported )
+   )
+
+   This abstract class defines printer information.  It is a base class
+   for deriving other printer related classes, such as, but not limited
+   to, classes defined in this document.  It defines a common set of
+   printer attributes that are not specific to any one type of service,
+   protocol or operating system.
+
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                      [Page 7]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+3.3.  printerService
+
+   ( 1.3.18.0.2.6.255
+   NAME  'printerService'
+   DESC  'Printer information.'
+   STRUCTURAL
+   SUP   printerAbstract
+   MAY   ( printer-uri $ printer-xri-supported )
+   )
+
+   This structural class defines printer information.  It is derived
+   from class printerAbstract and thus inherits common printer
+   attributes.  This class can be used with or without auxiliary classes
+   to define printer information.  Auxiliary classes can be used to
+   extend the common printer information with protocol, service or
+   operating system specific information.
+
+   Note:  When extending other structural classes with auxiliary
+   classes, printerService should not be used.
+
+3.4.  printerServiceAuxClass
+
+   ( 1.3.18.0.2.6.257
+   NAME  'printerServiceAuxClass'
+   DESC  'Printer information.'
+   AUXILIARY
+   SUP   printerAbstract
+   MAY   ( printer-uri $ printer-xri-supported )
+   )
+
+   This auxiliary class defines printer information.  It is derived from
+   class printerAbstract and thus inherits common printer attributes.
+   This class should be used with a structural class.
+
+3.5.  printerIPP
+
+   ( 1.3.18.0.2.6.256
+   NAME  'printerIPP'
+   DESC  'Internet Printing Protocol (IPP) information.'
+   AUXILIARY
+   SUP   top
+   MAY   ( printer-ipp-versions-supported $
+           printer-multiple-document-jobs-supported )
+   )
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                      [Page 8]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   This auxiliary class defines Internet Printing Protocol (IPP/1.1)
+   [RFC2911] information.  It should be used with a structural class
+   such as printerService.  It is used to extend structural classes with
+   IPP specific printer information.
+
+3.6.  printerLPR
+
+   ( 1.3.18.0.2.6.253
+   NAME  'printerLPR'
+   DESC  'LPR information.'
+   AUXILIARY
+   SUP   top
+   MUST  ( printer-name )
+   MAY   ( printer-aliases)
+   )
+
+   This auxiliary class defines LPR [RFC1179] information.  It should be
+   used with a structural class such as printerService.  It is used to
+   identify directory entries that support LPR.
+
+4.  Definition of Attribute Types
+
+   The following attribute types are referenced by the object classes
+   defined in Section 3.
+
+   The following attribute types reference syntax OIDs defined in
+   Section 6 of [RFC2252] (see Section 5 'Definition of Syntaxes'
+   below).
+
+   The following attribute types reference matching rule names (instead
+   of OIDs) for clarity (see Section 6 below).  For optional attributes,
+   if the printer information is not known, the attribute value should
+   not be set.  In the following definitions, referenced matching rules
+   are defined in Section 8 of [RFC2252] and/or Section 2 of [RFC3698]
+   (see Section 6 'Definition of Matching Rules' below).
+
+   The following table is a summary of the attribute names defined by
+   this document and their corresponding names from [RFC2911].  Some
+   attribute names described in [RFC2911] have been prefixed with
+   'printer-' as recommended in [RFC2926], to address the flat namespace
+   for LDAP identifiers.
+
+
+
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                      [Page 9]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   LDAP & SLP Printer Schema       IPP Model [RFC2911]
+   ------------------------------  -------------------------------------
+   printer-uri
+   printer-xri-supported
+                                   [IPP printer-uri-supported]
+                                   [IPP uri-authentication-supported]
+                                   [IPP uri-security-supported]
+   printer-name                    printer-name
+   printer-natural-language-configured
+                                   natural-language-configured
+   printer-location                printer-location
+   printer-info                    printer-info
+   printer-more-info               printer-more-info
+   printer-make-and-model          printer-make-and-model
+   printer-ipp-versions-supported  ipp-versions-supported
+   printer-multiple-document-jobs-supported
+                                   multiple-document-jobs-supported
+   printer-charset-configured      charset-configured
+   printer-charset-supported       charset-supported
+   printer-generated-natural-language-supported
+                                   generated-natural-language-supported
+   printer-document-format-supported
+                                   document-format-supported
+   printer-color-supported         color-supported
+   printer-compression-supported   compression-supported
+   printer-pages-per-minute        pages-per-minute
+   printer-pages-per-minute-color  pages-per-minute-color
+   printer-finishings-supported    finishings-supported
+   printer-number-up-supported     number-up-supported
+   printer-sides-supported         sides-supported
+   printer-media-supported         media-supported
+   printer-media-local-supported   [site names from IPP media-supported]
+   printer-resolution-supported    printer-resolution-supported
+   printer-print-quality-supported print-quality-supported
+   printer-job-priority-supported  job-priority-supported
+   printer-copies-supported        copies-supported
+   printer-job-k-octets-supported  job-k-octets-supported
+   printer-current-operator
+   printer-service-person
+   printer-delivery-orientation-supported
+   printer-stacking-order-supported
+   printer-output-features-supported
+   printer-aliases
+
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 10]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+4.1.  printer-uri
+
+   ( 1.3.18.0.2.4.1140
+   NAME 'printer-uri'
+   DESC 'A URI supported by this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15
+   SINGLE-VALUE
+   )
+
+   If the printer-xri-supported LDAP attribute is implemented, then this
+   printer-uri value should be listed in printer-xri-supported.
+
+   Values of URI should conform to [RFC2396], although URI schemes may
+   be defined which do not conform to [RFC2396] (see [RFC2717] and
+   [RFC2718]).
+
+   Note:  LDAP application clients should not attempt to use malformed
+   URI values read from this attribute.  LDAP administrative clients
+   should not write malformed URI values into this attribute.
+
+   Note:  For SLP registered printers, the LDAP printer-uri attribute
+   should be set to the value of the SLP-registered URL of the printer,
+   for interworking with SLPv2 [RFC2608] service discovery.
+
+   Note:  See Sections 1.1, 1.2, and 1.3 for rationale for design
+   choices.
+
+4.2.  printer-xri-supported
+
+   ( 1.3.18.0.2.4.1107
+   NAME 'printer-xri-supported'
+   DESC 'The unordered list of XRI (extended resource identifiers)
+         supported by this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+   )
+
+   A list of XRI (extended resource identifiers) supported by this
+   printer.  Each value of this list should consist of a URI (uniform
+   resource identifier) followed by (optional) authentication and
+   security fields.
+
+   Values of URI should conform to [RFC2396], although URI schemes may
+   be defined which do not conform to [RFC2396] (see [RFC2717] and
+   [RFC2718]).
+
+
+
+Fleming & McDonald           Informational                     [Page 11]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   Note:  LDAP application clients should not attempt to use malformed
+   URI values read from this attribute.  LDAP administrative clients
+   should not write malformed URI values into this attribute.
+
+   Note:  This attribute is based on 'printer-uri-supported', 'uri-
+   authentication-supported', and `'uri-security-supported' (called the
+   'Three Musketeers' because they are parallel ordered attributes)
+   defined in IPP/1.1 [RFC2911].  This attribute unfolds those IPP/1.1
+   attributes and thus avoids the ordering (and same number of values)
+   constraints of the IPP/1.1 separate attributes.
+
+   Defined keywords for fields include:
+
+       'uri' (IPP 'printer-uri-supported')
+       'auth' (IPP 'uri-authentication-supported')
+       'sec' (IPP 'uri-security-supported')
+
+   A missing 'auth' field should be interpreted to mean 'none'.  Per
+   IPP/1.1 [RFC2911], defined values of the 'auth' field include:
+
+       'none' (no authentication for this URI)
+       'requesting-user-name' (from operation request)
+       'basic' (HTTP/1.1 Basic [RFC2617])
+       'digest' (HTTP/1.1 Basic, [RFC2617])
+       'certificate' (from certificate)
+
+   A missing 'sec' field should be interpreted to mean 'none'.  Per
+   IPP/1.1 [RFC2911], defined values of the 'sec' field include:
+
+       'none' (no security for this URI)
+       'ssl3' (Netscape SSL3)
+       'tls' (IETF TLS/1.0, [RFC2246])
+
+   Each XRI field should be delimited by '<'.  For example:
+
+       'uri=ipp://foo.com< auth=digest< sec=tls<'
+       'uri=lpr://bar.com< auth=none< sec=none<'
+       'uri=mailto:printer@foobar.com< auth=none< sec=none<'
+
+   Note:  The syntax and delimiter for this attribute are aligned with
+   the equivalent attribute in the 'service:printer:' v2.0 template
+   [SLP-PRT].  Whitespace is permitted after (but not before) the
+   delimiter '<'.  Note that this delimiter differs from printer-
+   resolution-supported.
+
+   Note:  See Sections 1.1, 1.2, and 1.3 for rationale for design
+   choices.
+
+
+
+
+Fleming & McDonald           Informational                     [Page 12]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+4.3.  printer-name
+
+   ( 1.3.18.0.2.4.1135
+   NAME 'printer-name'
+   DESC 'The site-specific administrative name of this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   SINGLE-VALUE
+   )
+
+   Values of this attribute should be specified in the language
+   specified in printer-natural-language-configured (for example, to
+   support text-to-speech conversions), although the printer's name may
+   be specified in any language.  This name may be the last part of the
+   printer's URI or it may be completely unrelated.  This name may
+   contain characters that are not allowed in a conventional URI (see
+   [RFC2396]).
+
+4.4.  printer-natural-language-configured
+
+   ( 1.3.18.0.2.4.1119
+   NAME 'printer-natural-language-configured'
+   DESC 'The configured natural language in which error and status
+         messages will be generated (by default) by this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   SINGLE-VALUE
+   )
+
+   Also, a possible natural language for printer string attributes set
+   by operator, system administrator, or manufacturer.  Also, the
+   (declared) natural language of the printer-name, printer-location,
+   printer-info, and printer-make-and-model attributes of this printer.
+
+   Values of language tags should conform to "Tags for the
+   Identification of Languages" [RFC3066].  For example:
+
+       'en-us' (English as spoken in the US)
+       'fr-fr' (French as spoken in France)
+
+   For consistency with IPP/1.1 [RFC2911], language tags in this
+   attribute should be lowercase normalized.
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 13]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+4.5.  printer-location
+
+   ( 1.3.18.0.2.4.1136
+   NAME 'printer-location'
+   DESC 'The physical location of this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   SINGLE-VALUE
+   )
+
+   For example:
+
+       'Room 123A'
+       'Second floor of building XYZ'
+
+4.6.  printer-info
+
+   ( 1.3.18.0.2.4.1139
+   NAME 'printer-info'
+   DESC 'Descriptive information about this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   SINGLE-VALUE
+   )
+
+   For example:
+
+      'This printer can be used for printing color transparencies for
+       HR presentations'
+      'Out of courtesy for others, please print only small (1-5 page)
+       jobs at this printer'
+      'This printer is going away on July 1, 1997, please find a new
+       printer'
+
+4.7.  printer-more-info
+
+   ( 1.3.18.0.2.4.1134
+   NAME 'printer-more-info'
+   DESC 'A URI for more information about this specific printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15
+   SINGLE-VALUE
+   )
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 14]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   For example, this could be an HTTP type URI referencing an HTML page
+   accessible to a Web Browser.  The information obtained from this URI
+   is intended for end user consumption.
+
+   Values of URI should conform to [RFC2396], although URI schemes may
+   be defined which do not conform to [RFC2396] (see [RFC2717] and
+   [RFC2718]).
+
+   Note:  LDAP application clients should not attempt to use malformed
+   URI values read from this attribute.  LDAP administrative clients
+   should not write malformed URI values into this attribute.
+
+   Note:  See Sections 1.1, 1.2, and 1.3 for rationale for design
+   choices.
+
+4.8.  printer-make-and-model
+
+   ( 1.3.18.0.2.4.1138
+   NAME 'printer-make-and-model'
+   DESC 'Make and model of this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   SINGLE-VALUE
+   )
+
+   Note:  The printer manufacturer may initially populate this
+   attribute.
+
+4.9.  printer-ipp-versions-supported
+
+   ( 1.3.18.0.2.4.1133
+   NAME 'printer-ipp-versions-supported'
+   DESC 'IPP protocol version(s) that this printer supports.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   )
+
+   The IPP protocol version(s) should include major and minor versions,
+   i.e., the exact version numbers for which this Printer implementation
+   meets the IPP version-specific conformance requirements.
+
+
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 15]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+4.10.  printer-multiple-document-jobs-supported
+
+   ( 1.3.18.0.2.4.1132
+   NAME 'printer-multiple-document-jobs-supported'
+   DESC 'Indicates whether or not this printer supports more than one
+         document per job.'
+   EQUALITY booleanMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.7
+   SINGLE-VALUE
+   )
+
+4.11.  printer-charset-configured
+
+   ( 1.3.18.0.2.4.1109
+   NAME 'printer-charset-configured'
+   DESC 'The configured charset in which error and status messages will
+         be generated (by default) by this printer.'
+   EQUALITY caseIgnoreMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{63}
+   SINGLE-VALUE
+   )
+
+   Also, a possible charset for printer string attributes set by
+   operator, system administrator, or manufacturer.  For example:
+
+       'utf-8' (ISO 10646/Unicode in UTF-8 transform [RFC2279])
+       'iso-8859-1' (Latin1)
+
+   Values of charset tags should be defined in the IANA Registry of
+   Coded Character Sets [IANA-CHAR] (see also [RFC2978]) and the
+   '(preferred MIME name)' should be used as the charset tag in this
+   attribute.
+
+   For consistency with IPP/1.1 [RFC2911], charset tags in this
+   attribute should be lowercase normalized.
+
+4.12.  printer-charset-supported
+
+   ( 1.3.18.0.2.4.1131
+   NAME 'printer-charset-supported'
+   DESC 'Set of charsets supported for the attribute values of syntax
+         DirectoryString for this directory entry.'
+   EQUALITY caseIgnoreMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{63}
+   )
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 16]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   For example:
+
+       'utf-8' (ISO 10646/Unicode in UTF-8 transform [RFC2279])
+       'iso-8859-1' (Latin1)
+
+   Values of charset tags should be defined in the IANA Registry of
+   Coded Character Sets [IANA-CHAR] (see also [RFC2978]) and the
+   '(preferred MIME name)' should be used as the charset tag in this
+   attribute.
+
+   For consistency with IPP/1.1 [RFC2911], charset tags in this
+   attribute should be lowercase normalized.
+
+4.13.  printer-generated-natural-language-supported
+
+   ( 1.3.18.0.2.4.1137
+   NAME 'printer-generated-natural-language-supported'
+   DESC 'Natural language(s) supported for this directory entry.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{63}
+   )
+
+   Values of language tags should conform to "Tags for the
+   Identification of Languages" [RFC3066].  For example:
+
+       'en-us' (English as spoken in the US)
+       'fr-fr' (French as spoken in France)
+
+   For consistency with IPP/1.1 [RFC2911], language tags in this
+   attribute should be lowercase normalized.
+
+4.14.  printer-document-format-supported
+
+   ( 1.3.18.0.2.4.1130
+   NAME 'printer-document-format-supported'
+   DESC 'The possible source document formats which may be interpreted
+         and printed by this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   )
+
+   Values of document formats should be MIME media types defined in the
+   IANA Registry of MIME Media Types [IANA-MIME] (see also [RFC2048]).
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 17]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+4.15.  printer-color-supported
+
+   ( 1.3.18.0.2.4.1129
+   NAME 'printer-color-supported'
+   DESC 'Indicates whether this printer is capable of any type of color
+         printing at all, including highlight color.'
+   EQUALITY booleanMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.7
+   SINGLE-VALUE
+   )
+
+4.16.  printer-compression-supported
+
+   ( 1.3.18.0.2.4.1128
+   NAME 'printer-compression-supported'
+   DESC 'Compression algorithms supported by this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255}
+   )
+
+   Values defined in IPP/1.1 [RFC2911] include:
+
+       'none' (no compression is used)
+       'deflate' (public domain ZIP described in [RFC1951])
+       'gzip' (GNU ZIP described in [RFC1952])
+       'compress' (UNIX compression described in [RFC1977])
+
+4.17.  printer-pages-per-minute
+
+   ( 1.3.18.0.2.4.1127
+   NAME 'printer-pages-per-minute'
+   DESC 'The nominal number of pages per minute which may be output by
+         this printer.'
+   EQUALITY integerMatch
+   ORDERING integerOrderingMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.27
+   SINGLE-VALUE
+   )
+
+   This attribute is informative, not a service guarantee.  Typically,
+   it is the value used in marketing literature to describe this
+   printer.  For example, the value for a simplex or black-and-white
+   print mode.
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 18]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+4.18.  printer-pages-per-minute-color
+
+   ( 1.3.18.0.2.4.1126
+   NAME 'printer-pages-per-minute-color'
+   DESC 'The nominal number of color pages per minute which may be
+         output by this printer.'
+   EQUALITY integerMatch
+   ORDERING integerOrderingMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.27
+   SINGLE-VALUE
+   )
+
+   This attribute is informative, not a service guarantee.  Typically,
+   it is the value used in marketing literature to describe this
+   printer.
+
+
+4.19.  printer-finishings-supported
+
+   ( 1.3.18.0.2.4.1125
+   NAME 'printer-finishings-supported'
+   DESC 'The possible finishing operations supported by this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255}
+   )
+
+   Values defined in IPP/1.1 [RFC2911] include:  'none', 'staple',
+   'punch', 'cover', 'bind', 'saddle-stitch', 'edge-stitch',
+   'staple-top-left', 'staple-bottom-left', 'staple-top-right',
+   'staple-bottom-right', 'edge-stitch-left', 'edge-stitch-top',
+   'edge-stitch-right', 'edge-stitch-bottom', 'staple-dual-left',
+   'staple-dual-top', 'staple-dual-right', 'staple-dual-bottom'.
+
+   Note:  Implementations may support other values.
+
+4.20.  printer-number-up-supported
+
+   ( 1.3.18.0.2.4.1124
+   NAME 'printer-number-up-supported'
+   DESC 'The possible numbers of print-stream pages to impose upon a
+         single side of an instance of a selected medium.'
+   EQUALITY integerMatch
+   ORDERING integerOrderingMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.27
+   )
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 19]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   Values defined in IPP/1.1 [RFC2911] include: '1', '2', and '4'.
+
+   Note:  Implementations may support other values.
+
+4.21.  printer-sides-supported
+
+   ( 1.3.18.0.2.4.1123
+   NAME 'printer-sides-supported'
+   DESC 'The number of impression sides (one or two) and the two-sided
+         impression rotations supported by this printer.'
+   EQUALITY caseIgnoreMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   )
+
+   Values defined in IPP/1.1 [RFC2911] include:  'one-sided', 'two-
+   sided-long-edge', 'two-sided-short-edge'.'
+
+4.22.  printer-media-supported
+
+   ( 1.3.18.0.2.4.1122
+   NAME 'printer-media-supported'
+   DESC 'The standard names/types/sizes (and optional color suffixes) of
+         the media supported by this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255}
+   )
+
+   Values are defined in IPP/1.1 [RFC2911] or any IANA registered
+   extensions.  For example:
+
+       'iso-a4'
+       'envelope'
+       'na-letter-white'
+
+4.23.  printer-media-local-supported
+
+   ( 1.3.18.0.2.4.1117
+   NAME 'printer-media-local-supported'
+   DESC 'Site-specific names of media supported by this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255}
+   )
+
+   Values should be in the natural language specified by printer-
+   natural-language-configured.
+
+
+
+
+Fleming & McDonald           Informational                     [Page 20]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   For example:
+
+       'purchasing-form' (site-specific name)
+
+   as opposed to 'na-letter' (standard keyword from IPP/1.1 [RFC2911])
+   in the printer-media-supported attribute.
+
+4.24.  printer-resolution-supported
+
+   ( 1.3.18.0.2.4.1121
+   NAME 'printer-resolution-supported'
+   DESC 'List of resolutions supported for printing documents by this
+         printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255}
+   )
+
+   Each resolution value should be a string containing 3 fields:
+   1)  Cross feed direction resolution (positive integer);
+   2)  Feed direction resolution (positive integer);
+   3)  Unit - 'dpi' (dots per inch) or 'dpcm' (dots per centimeter).
+
+   Each resolution field should be delimited by '>'.  For example:
+
+       '300> 300> dpi>'
+       '600> 600> dpi>'
+
+   Note:  This attribute is based on 'printer-resolution-supported'
+   defined in IPP/1.1 [RFC2911] (which has a binary complex encoding)
+   derived from 'prtMarkerAddressabilityFeedDir',
+   'prtMarkerAddressabilityXFeedDir', and 'prtMarkerAddressabilityUnit'
+   defined in the Printer MIB [RFC1759] (which have integer encodings).
+
+   Note:  The syntax and delimiter for this attribute are aligned with
+   the equivalent attribute in the 'service:printer:' v2.0 template
+   [SLP-PRT].  Whitespace is permitted after (but not before) the
+   delimiter '>'.  Note that this delimiter differs from printer-xri-
+   supported.
+
+
+
+
+
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 21]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+4.25.  printer-print-quality-supported
+
+   ( 1.3.18.0.2.4.1120
+   NAME 'printer-print-quality-supported'
+   DESC 'List of print qualities supported for printing documents on
+         this printer.'
+   EQUALITY caseIgnoreMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   )
+
+   Values defined in IPP/1.1 [RFC2911] include:
+
+       'unknown'
+       'draft'
+       'normal'
+       'high'
+
+4.26.  printer-job-priority-supported
+
+   ( 1.3.18.0.2.4.1110
+   NAME 'printer-job-priority-supported'
+   DESC 'Indicates the number of job priority levels supported by this
+         printer.'
+   EQUALITY integerMatch
+   ORDERING integerOrderingMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.27
+   SINGLE-VALUE
+   )
+
+   An IPP/1.1 [RFC2911] conformant Printer, which supports job priority,
+   always supports a full range of priorities from '1' to '100' (to
+   ensure consistent behavior), therefore this attribute describes the
+   'granularity' of priority supported.  Values of this attribute are
+   from '1' to '100'.
+
+4.27.  printer-copies-supported
+
+   ( 1.3.18.0.2.4.1118
+   NAME 'printer-copies-supported'
+   DESC 'The maximum number of copies of a document that may be printed
+         as a single job on this printer.'
+   EQUALITY integerMatch
+   ORDERING integerOrderingMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.27
+   SINGLE-VALUE
+   )
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 22]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   A positive value indicates the maximum supported copies.  A value of
+   '0' indicates no maximum limit.  A value of '-1' indicates 'unknown'.
+
+   Note:  The syntax and values for this attribute are aligned with the
+   equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+   PRT].
+
+4.28.  printer-job-k-octets-supported
+
+   ( 1.3.18.0.2.4.1111
+   NAME 'printer-job-k-octets-supported'
+   DESC 'The maximum size in kilobytes (1,024 octets actually) incoming
+         print job that this printer will accept.'
+   EQUALITY integerMatch
+   ORDERING integerOrderingMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.27
+   SINGLE-VALUE
+   )
+
+   A positive value indicates the maximum supported job size.  A value
+   of '0' indicates no maximum limit.  A value of '-1' indicates
+   'unknown'.
+
+   Note:  The syntax and values for this attribute are aligned with the
+   equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+   PRT].
+
+4.29.  printer-current-operator
+
+   ( 1.3.18.0.2.4.1112
+   NAME 'printer-current-operator'
+   DESC 'The identity of the current human operator responsible for
+         operating this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   SINGLE-VALUE
+   )
+
+   The value of this attribute should include information that would
+   enable other humans to reach the operator, such as a telephone
+   number.
+
+
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 23]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+4.30.  printer-service-person
+
+   ( 1.3.18.0.2.4.1113
+   NAME 'printer-service-person'
+   DESC 'The identity of the current human service person responsible
+         for servicing this printer.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   SINGLE-VALUE
+   )
+
+   The value of this attribute should include information that would
+   enable other humans to reach the service person, such as a telephone
+   number.
+
+4.31.  printer-delivery-orientation-supported
+
+   ( 1.3.18.0.2.4.1114
+   NAME 'printer-delivery-orientation-supported'
+   DESC 'The possible delivery orientations of pages as they are printed
+         and ejected from this printer.'
+   EQUALITY caseIgnoreMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   )
+
+   Values defined include:
+
+       'unknown'
+       'face-up'
+       'face-down'
+
+   Note:  The syntax and values for this attribute are aligned with the
+   equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+   PRT].
+
+4.32.  printer-stacking-order-supported
+
+   ( 1.3.18.0.2.4.1115
+   NAME 'printer-stacking-order-supported'
+   DESC 'The possible stacking order of pages as they are printed and
+         ejected from this printer.'
+   EQUALITY caseIgnoreMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   )
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 24]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   Values defined include:
+
+       'unknown'
+       'first-to-last'
+       'last-to-first'
+
+   Note:  The syntax and values for this attribute are aligned with the
+   equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+   PRT].
+
+4.33.  printer-output-features-supported
+
+   ( 1.3.18.0.2.4.1116
+   NAME 'printer-output-features-supported'
+   DESC 'The possible output features supported by this printer.'
+   EQUALITY caseIgnoreMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   )
+
+   Values defined include:
+
+       'unknown'
+       'bursting'
+       'decollating'
+       'page-collating'
+       'offset-stacking'
+
+   Note:  The syntax and values for this attribute are aligned with the
+   equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+   PRT].
+
+   Note:  Implementations may support other values.
+
+4.34.  printer-aliases
+
+   ( 1.3.18.0.2.4.1108
+   NAME 'printer-aliases'
+   DESC 'List of site-specific administrative names of this printer in
+         addition to the value specified for printer-name.'
+   EQUALITY caseIgnoreMatch
+   SUBSTR caseIgnoreSubstringsMatch
+   SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}
+   )
+
+   Values of this attribute should be specified in the language
+   specified in printer-natural-language-configured (for example, to
+   support text-to-speech conversions), although the printer's alias may
+   be specified in any language.
+
+
+
+Fleming & McDonald           Informational                     [Page 25]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+5.  Definition of Syntaxes
+
+   No new attribute syntaxes are defined by this document.
+
+   The attribute types defined in Section 4 of this document reference
+   syntax OIDs defined in Section 6 of [RFC2252], which are summarized
+   below:
+
+   Syntax OID                      Syntax Description
+   ------------------------------  ------------------
+   1.3.6.1.4.1.1466.115.121.1.7    Boolean
+   1.3.6.1.4.1.1466.115.121.1.15   DirectoryString (UTF-8 [RFC2279])
+   1.3.6.1.4.1.1466.115.121.1.27   Integer
+
+6.  Definition of Matching Rules
+
+   No new matching rules are defined by this document.
+
+   The attribute types defined in Section 4 of this document reference
+   matching rules defined in Section 8 of [RFC2252] and/or Section 2 of
+   [RFC3698], which are summarized below:
+
+   Matching Rule OID               Matching Rule Name          Usage
+   ------------------------------  ------------------          -----
+   2.5.13.13                       booleanMatch                EQUALITY
+   2.5.13.2                        caseIgnoreMatch             EQUALITY
+   2.5.13.14                       integerMatch                EQUALITY
+   2.5.13.15                       integerOrderingMatch        ORDERING
+   2.5.13.4                        caseIgnoreSubstringsMatch   SUBSTR
+
+7.  IANA Considerations
+
+   This document does not define any new syntaxes or matching rules.
+
+   This document does define the following Object Identifier
+   Descriptors.  They have been registered by the IANA:
+
+7.1.  Registration of Object Classes
+
+   Subject:  Request for LDAP Descriptor Registration
+
+   Descriptor (short name):  see table below
+
+   Object Identifier:  see table below
+
+   Person & email address to contact for further information:  see below
+
+   Usage:  object class
+
+
+
+Fleming & McDonald           Informational                     [Page 26]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   Specification:  RFC3712
+
+   Author/Change Controller:
+
+       Pat Fleming
+       IBM
+       Highway 52 N
+       Rochester, MN 55901
+       USA
+       Phone: +1 507-253-7583
+       EMail: flemingp@us.ibm.com
+
+   Comments:
+
+   Object Class                                    OID
+   ------------------------------------            ---------------------
+   slpServicePrinter                               1.3.18.0.2.6.254
+   printerAbstract                                 1.3.18.0.2.6.258
+   printerService                                  1.3.18.0.2.6.255
+   printerServiceAuxClass                          1.3.18.0.2.6.257
+   printerIPP                                      1.3.18.0.2.6.256
+   printerLPR                                      1.3.18.0.2.6.253
+
+7.2.  Registration of Attribute Types
+
+   Subject:  Request for LDAP Descriptor Registration
+
+   Descriptor (short name):  see table below
+
+   Object Identifier:  see table below
+
+   Person & email address to contact for further information:  see below
+
+   Usage:  attribute type
+
+   Specification:  RFC3712
+
+   Author/Change Controller:
+
+       Pat Fleming
+       IBM
+       Highway 52 N
+       Rochester, MN 55901
+       USA
+       Phone: +1 507-253-7583
+       EMail: flemingp@us.ibm.com
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 27]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   Comments:
+
+   Attribute Type                                  OID
+   ------------------------------------            ---------------------
+   printer-uri                                     1.3.18.0.2.4.1140
+   printer-xri-supported                           1.3.18.0.2.4.1107
+   printer-name                                    1.3.18.0.2.4.1135
+   printer-natural-language-configured             1.3.18.0.2.4.1119
+   printer-location                                1.3.18.0.2.4.1136
+   printer-info                                    1.3.18.0.2.4.1139
+   printer-more-info                               1.3.18.0.2.4.1134
+   printer-make-and-model                          1.3.18.0.2.4.1138
+   printer-ipp-versions-supported                  1.3.18.0.2.4.1133
+   printer-multiple-document-jobs-supported        1.3.18.0.2.4.1132
+   printer-charset-configured                      1.3.18.0.2.4.1109
+   printer-charset-supported                       1.3.18.0.2.4.1131
+   printer-generated-natural-language-supported    1.3.18.0.2.4.1137
+   printer-document-format-supported               1.3.18.0.2.4.1130
+   printer-color-supported                         1.3.18.0.2.4.1129
+   printer-compression-supported                   1.3.18.0.2.4.1128
+   printer-pages-per-minute                        1.3.18.0.2.4.1127
+   printer-pages-per-minute-color                  1.3.18.0.2.4.1126
+   printer-finishings-supported                    1.3.18.0.2.4.1125
+   printer-number-up-supported                     1.3.18.0.2.4.1124
+   printer-sides-supported                         1.3.18.0.2.4.1123
+   printer-media-supported                         1.3.18.0.2.4.1122
+   printer-media-local-supported                   1.3.18.0.2.4.1117
+   printer-resolution-supported                    1.3.18.0.2.4.1121
+   printer-print-quality-supported                 1.3.18.0.2.4.1120
+   printer-job-priority-supported                  1.3.18.0.2.4.1110
+   printer-copies-supported                        1.3.18.0.2.4.1118
+   printer-job-k-octets-supported                  1.3.18.0.2.4.1111
+   printer-current-operator                        1.3.18.0.2.4.1112
+   printer-service-person                          1.3.18.0.2.4.1113
+   printer-delivery-orientation-supported          1.3.18.0.2.4.1114
+   printer-stacking-order-supported                1.3.18.0.2.4.1115
+   printer-output-features-supported               1.3.18.0.2.4.1116
+   printer-aliases                                 1.3.18.0.2.4.1108
+
+8.  Internationalization Considerations
+
+   All text string attributes defined in this document of syntax
+   [RFC2279], as required by [RFC2252].
+
+   A language tag [RFC3066] for all of the text string attributes
+   defined in this document is contained in the printer-natural-
+   language-configured attribute.
+
+
+
+
+Fleming & McDonald           Informational                     [Page 28]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   Therefore, all object classes defined in this document conform to the
+   "IETF Policy on Character Sets and Languages" [RFC2277].
+
+9.  Security Considerations
+
+   See [RFC2829] for detailed guidance on authentication methods for
+   LDAP.  See [RFC2830] for detailed guidance of using TLS/1.0 [RFC2246]
+   to supply connection confidentiality and data integrity for LDAP
+   sessions.
+
+   As with any LDAP schema, it is important to protect specific entries
+   and attributes with the appropriate access control.  It is
+   particularly important that only administrators can modify entries
+   defined in this LDAP printer schema.  Otherwise, an LDAP client might
+   be fooled into diverting print service requests from the original
+   printer (or spooler) to a malicious intruder's host system, thus
+   exposing the information in printed documents.
+
+   For additional security considerations of deploying printers in an
+   IPP environment, see Section 8 of [RFC2911].
+
+10.  References
+
+10.1.  Normative References
+
+   [IANA-CHAR] IANA Registry of Character Sets
+               http://www.iana.org/assignments/charset-reg/...
+
+   [IANA-MIME] IANA Registry of MIME Media Types
+               http://www.iana.org/assignments/media-types/...
+
+   [LDAP-TS]   Hodges, J. and R. Morgan, "Lightweight Directory Access
+               Protocol (v3): Technical Specification", RFC 3377,
+               September 2002.
+
+   [RFC1274]   Barker, P. and S. Kille, "The COSINE and Internet X.500
+               Schema", RFC 1274, November 1991.
+
+   [RFC1759]   Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
+               Gyllenskog, "Printer MIB", RFC 1759, March 1995.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2252]   Wahl, M., Coulbeck, T., Howes, T. and S. Kille,
+               "Lightweight Directory Access Protocol (v3): Attribute
+               Syntax Definitions", RFC 2252, December 1997.
+
+
+
+
+Fleming & McDonald           Informational                     [Page 29]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   [RFC2396]   Berners-Lee. T., Fielding, R. and L. Masinter, "URI
+               Generic Syntax", RFC 2396, August 1998.
+
+   [RFC2829]   Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+               "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+   [RFC2830]   Hodges, J., Morgan, R. and M. Wahl, "Lightweight
+               Directory Access Protocol (v3): Extension for Transport
+               Layer Security", RFC 2830, May 2000.
+
+   [RFC2911]   Hastings, T., Ed.., Herrito, R., deBry, R., Isaacson, S.
+               and P. Powell, "Internet Printing Protocol/1.1: Model and
+               Semantics", RFC 2911, September 2000.
+
+   [RFC2926]   Kempf, J., Moats, R. and P. St. Pierre, "Conversion of
+               LDAP Schemas to and from SLP Templates", RFC 2926,
+               September 2000.
+
+   [RFC3066]   Alvestrand, H., "Tags for the Identification of
+               Languages", BCP 47, RFC 3066, January 2001.
+
+   [RFC3698]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+               (LDAP): Additional Matching Rules", RFC 3698, February
+               2004.
+
+10.2.  Informative References
+
+   [IANA-SLPT] IANA Registry of SLP Templates
+               http://www.iana.org/assignments/svrloc-templates/...
+
+   [RFC1179]   McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179,
+               August 1990.
+
+   [RFC1951]   Deutsch, P., "DEFLATE Compressed Data Format
+               Specification Version 1.3", RFC 1951, May 1996.
+
+   [RFC1952]   Deutsch, P., "GZIP File Format Specification Version
+               4.3", RFC 1952, May 1996.
+
+   [RFC1977]   Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
+               August 1996.
+
+   [RFC2048]   Freed, N., Klensin, J. and J. Postel, "Multipurpose
+               Internet Mail Extensions (MIME) Part Four: Registration
+               Procedures", BCP 13, RFC 2048, November 1996.
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 30]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+   [RFC2079]   Smith, M., "Definition of an X.500 Attribute Type and an
+               Object Class to Hold Uniform Resource Identifiers
+               (URIs)", RFC 2079, January 1997.
+
+   [RFC2246]   Dierks, T. and C. Allen, "TLS Protocol Version 1.0", RFC
+               2246, January 1999.
+
+   [RFC2277]   Alvestrand, H., "IETF Policy on Character Sets and
+               Languages", RFC 2277, January 1998.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a Transformation Format of ISO
+               10646", RFC 2279, January 1998.
+
+   [RFC2608]   Guttman, E., Perkins, C., Veizades, J. and M. Day,
+               "Service Location Protocol v2", RFC 2608, June 1999.
+
+   [RFC2609]   Guttman, E., Perkins, C. and J. Kempf, "Service Templates
+               and Service: Schemes", RFC 2609, June 1999.
+
+   [RFC2617]   Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
+               S., Leach, P., Luotonen, A. and L. Stewart, "HTTP
+               Authentication: Basic and Digest Access Authentication",
+               RFC 2617, June 1999.
+
+   [RFC2717]   Petke, R. and I. King, "Registration Procedures for URL
+               Scheme Names", RFC 2717, November 1999.
+
+   [RFC2718]   Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
+               "Guidelines for new URL Schemes", BCP 19, RFC 2718,
+               November 1999.
+
+   [RFC2978]   Freed, N. and J.Postel, "IANA Charset Registration
+               Procedures", RFC2978, October 2000.
+
+   [SLP-PRT]   St. Pierre, Isaacson, McDonald.  Definition of the
+               Printer Abstract Service Type v2.0, <durable URL below>,
+               May 2000. Reviewed and approved by IETF SLP Designated
+               Expert, according to Section 5 'IANA Considerations' in
+               [RFC2609].
+
+               Archived in the IANA Registry of SLP Templates [IANA-
+               SLPT] at: http://www.iana.org/assignments/svrloc-
+               templates/printer.2.0.en
+
+   [W3C-IRI]   Duerst, Suignard, "Internationalized Resource Identifiers
+               (IRI), Work in Progress.
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 31]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+11.  Acknowledgments
+
+   The editors wish to acknowledge the very significant contributions of
+   Ken Jones (Bytemobile) and Harry Lewis (IBM) during the development
+   of this document.
+
+   Thanks to Patrik Faltstrom (Cisco), Ryan Moats (Lemur Networks),
+   Robert Moore (IBM), Lee Rafalow (IBM), Kimberly Reger (IBM), Kurt
+   Zeilenga (OpenLDAP), and the members of the IETF IPP Working Group,
+   for review comments and help in preparing this document.
+
+12.  Authors' Addresses
+
+   Please send comments to the authors at the addresses listed below.
+
+   Pat Fleming
+   IBM
+   Highway 52 N
+   Rochester, MN 55901
+   USA
+
+   Phone: +1 507-253-7583
+   EMail: flemingp@us.ibm.com
+
+
+   Ira McDonald
+   High North Inc
+   221 Ridge Ave
+   Grand Marais, MI 49839
+   USA
+
+   Phone: +1 906-494-2434
+   Email: imcdonald@sharplabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 32]
+\f
+RFC 3712            LDAP Schema for Printer Services       February 2004
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed
+   to pertain to the implementation or use of the technology
+   described in this document or the extent to which any license
+   under such rights might or might not be available; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Fleming & McDonald           Informational                     [Page 33]
+\f
diff --git a/doc/rfc/rfc3727.txt b/doc/rfc/rfc3727.txt
new file mode 100644 (file)
index 0000000..97c4126
--- /dev/null
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                            S. Legg
+Request for Comments: 3727                           Adacel Technologies
+Category: Standards Track                                  February 2004
+
+
+                    ASN.1 Module Definition for the
+                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
+
+   This document updates the specification of the component matching
+   rules for Lightweight Directory Access Protocol (LDAP) and X.500
+   directories (RFC3687) by collecting the Abstract Syntax Notation One
+   (ASN.1) definitions of the component matching rules into an
+   appropriately identified ASN.1 module so that other specifications
+   may reference the component matching rule definitions from within
+   their own ASN.1 modules.
+
+1.  Introduction
+
+   The structure or data type of data held in an attribute of a
+   Lightweight Directory Access Protocol (LDAP) [LDAP] or X.500 [X500]
+   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.  RFC 3687 [CMR] defines a
+   generic way of matching user selected components in a directory
+   attribute value of any arbitrarily complex attribute syntax.
+
+   This document updates RFC 3687 by collecting the Abstract Syntax
+   Notation One (ASN.1) [ASN1] definitions of RFC 3687 into an
+   appropriately identified ASN.1 module so that other specifications
+   may reference these definitions from within their own ASN.1 modules.
+
+
+
+
+
+
+Legg                        Standards Track                     [Page 1]
+\f
+RFC 3727             Module for Component Matching         February 2004
+
+
+2.  Module Definition for Component Matching
+
+   ComponentMatching
+       {iso(1) 2 36 79672281 xed(3) module(0) component-matching(4)}
+
+   --  Copyright (C) The Internet Society (2004).  This version of
+   --  this ASN.1 module is part of RFC 3727; see the RFC itself
+   --  for full legal notices.
+
+   DEFINITIONS
+   EXPLICIT TAGS
+   EXTENSIBILITY IMPLIED ::= BEGIN
+
+   IMPORTS
+       MATCHING-RULE,
+       RelativeDistinguishedName
+           FROM InformationFramework
+               {joint-iso-itu-t ds(5) module(1)
+                   informationFramework(1) 4} ;
+
+   ComponentAssertion ::= SEQUENCE {
+       component         ComponentReference (SIZE(1..MAX)) OPTIONAL,
+       useDefaultValues  BOOLEAN DEFAULT TRUE,
+       rule              MATCHING-RULE.&id,
+       value             MATCHING-RULE.&AssertionType }
+
+   ComponentReference ::= UTF8String
+
+   ComponentFilter ::= CHOICE {
+       item  [0] ComponentAssertion,
+       and   [1] SEQUENCE OF ComponentFilter,
+       or    [2] SEQUENCE OF ComponentFilter,
+       not   [3] ComponentFilter }
+
+   componentFilterMatch MATCHING-RULE ::= {
+       SYNTAX  ComponentFilter
+       ID      { 1 2 36 79672281 1 13 2 } }
+
+   allComponentsMatch MATCHING-RULE ::= {
+       ID      { 1 2 36 79672281 1 13 6 } }
+
+   directoryComponentsMatch MATCHING-RULE ::= {
+       ID      { 1 2 36 79672281 1 13 7 } }
+
+
+   -- Additional Useful Matching Rules --
+
+   rdnMatch MATCHING-RULE ::= {
+
+
+
+Legg                        Standards Track                     [Page 2]
+\f
+RFC 3727             Module for Component Matching         February 2004
+
+
+       SYNTAX  RelativeDistinguishedName
+       ID      { 1 2 36 79672281 1 13 3 } }
+
+   presentMatch MATCHING-RULE ::= {
+       SYNTAX  NULL
+       ID      { 1 2 36 79672281 1 13 5 } }
+
+   END
+
+   The InformationFramework ASN.1 module from which the MATCHING-RULE
+   and RelativeDistinguishedName definitions are imported is defined in
+   X.501 [X501].
+
+   The object identifiers used in this document have been assigned for
+   use in specifying the component matching rules by Adacel
+   Technologies, under an arc assigned to Adacel by Standards Australia.
+
+3.  Security Considerations
+
+   This document collects together the ASN.1 definitions of the
+   component matching rules into an ASN.1 module, but does not modify
+   those definitions in any way.  See RFC 3687 [CMR] for the security
+   considerations of using the component matching rules.
+
+4.  References
+
+4.1.  Normative References
+
+   [CMR]   Legg, S., "Lightweight Directory Access Protocol (LDAP) and
+           X.500 Component Matching Rules", RFC 3687, February 2004.
+
+   [X501]  ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+           Information Technology - Open Systems Interconnection - The
+           Directory: Models
+
+   [ASN1]  ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
+           Information technology - Abstract Syntax Notation One
+           (ASN.1): Specification of basic notation
+
+4.2.  Informative References
+
+   [LDAP]  Hodges, J. and R. Morgan, "Lightweight Directory Access
+           Protocol (v3): Technical Specification", RFC 3377, September
+           2002.
+
+   [X500]  ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+           Information Technology - Open Systems Interconnection - The
+           Directory: Overview of concepts, models and services
+
+
+
+Legg                        Standards Track                     [Page 3]
+\f
+RFC 3727             Module for Component Matching         February 2004
+
+
+5.  Author's Address
+
+   Steven Legg
+   Adacel Technologies Ltd.
+   250 Bay Street
+   Brighton, Victoria 3186
+   AUSTRALIA
+
+   Phone: +61 3 8530 7710
+   Fax:   +61 3 8530 7888
+   EMail: steven.legg@adacel.com.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg                        Standards Track                     [Page 4]
+\f
+RFC 3727             Module for Component Matching         February 2004
+
+
+6.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed
+   to pertain to the implementation or use of the technology
+   described in this document or the extent to which any license
+   under such rights might or might not be available; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Legg                        Standards Track                     [Page 5]
+\f