From: Kurt Zeilenga <kurt@openldap.org>
Date: Thu, 11 Mar 2004 21:10:05 +0000 (+0000)
Subject: New LDAP RFCs
X-Git-Tag: OPENLDAP_REL_ENG_2_2_BP~309
X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=95459fef7f17bda271f51f724102eef932258630;p=openldap
New LDAP RFCs
---
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
index 230cbc33f7..0000000000
--- a/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
+++ /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
index 0825eb98df..0000000000
--- a/doc/drafts/draft-legg-ldapext-component-matching-xx.txt
+++ /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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX
index 074e295be4..fb7cdf5f46 100644
--- a/doc/rfc/INDEX
+++ b/doc/rfc/INDEX
@@ -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
index 0000000000..a63ab1fc99
--- /dev/null
+++ b/doc/rfc/rfc3687.txt
@@ -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]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. ComponentAssertion . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Component Reference. . . . . . . . . . . . . . . . . . . 6
+ 3.1.1. Component Type Substitutions . . . . . . . . . . 7
+ 3.1.2. Referencing SET, SEQUENCE and CHOICE Components. 8
+ 3.1.3. Referencing SET OF and SEQUENCE OF Components. . 9
+ 3.1.4. Referencing Components of Parameterized Types. . 10
+ 3.1.5. Component Referencing Example. . . . . . . . . . 10
+ 3.1.6. Referencing Components of Open Types . . . . . . 12
+ 3.1.6.1. Open Type Referencing Example . . . . . 12
+ 3.1.7. Referencing Contained Types. . . . . . . . . . . 14
+ 3.1.7.1. Contained Type Referencing Example. . . 14
+ 3.2. Matching of Components . . . . . . . . . . . . . . . . . 15
+ 3.2.1. Applicability of Existing Matching Rules . . . . 17
+ 3.2.1.1. String Matching . . . . . . . . . . . . 17
+ 3.2.1.2. Telephone Number Matching . . . . . . . 17
+ 3.2.1.3. Distinguished Name Matching . . . . . . 18
+ 3.2.2. Additional Useful Matching Rules . . . . . . . . 18
+ 3.2.2.1. The rdnMatch Matching Rule. . . . . . . 18
+ 3.2.2.2. The presentMatch Matching Rule. . . . . 19
+ 3.2.3. Summary of Useful Matching Rules . . . . . . . . 20
+ 4. ComponentFilter. . . . . . . . . . . . . . . . . . . . . . . . 21
+ 5. The componentFilterMatch Matching Rule . . . . . . . . . . . . 22
+ 6. Equality Matching of Complex Components. . . . . . . . . . . . 24
+ 6.1. The OpenAssertionType Syntax . . . . . . . . . . . . . . 24
+ 6.2. The allComponentsMatch Matching Rule . . . . . . . . . . 25
+ 6.3. Deriving Component Equality Matching Rules . . . . . . . 27
+ 6.4. The directoryComponentsMatch Matching Rule . . . . . . . 28
+ 7. Component Matching Examples. . . . . . . . . . . . . . . . . . 30
+ 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
+ 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 37
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
+ 11.1. Normative References. . . . . . . . . . . . . . . . . . 38
+ 11.2. Informative References. . . . . . . . . . . . . . . . . 40
+ 12. Intellectual Property Statement. . . . . . . . . . . . . . . . 40
+ 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 41
+ 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 42
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 2]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+1. Introduction
+
+ The structure or data type of data held in an attribute of a
+ Lightweight Directory Access Protocol (LDAP) [7] or X.500 [19]
+ directory is described by the attribute's syntax. Attribute syntaxes
+ range from simple data types, such as text string, integer, or
+ boolean, to complex data types, for example, the syntaxes of the
+ directory schema operational attributes.
+
+ In X.500, the attribute syntaxes are explicitly described by 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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
diff --git a/doc/rfc/rfc3698.txt b/doc/rfc/rfc3698.txt
new file mode 100644
index 0000000000..0062adebbe
--- /dev/null
+++ b/doc/rfc/rfc3698.txt
@@ -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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
diff --git a/doc/rfc/rfc3712.txt b/doc/rfc/rfc3712.txt
new file mode 100644
index 0000000000..f5bb966ea2
--- /dev/null
+++ b/doc/rfc/rfc3712.txt
@@ -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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
diff --git a/doc/rfc/rfc3727.txt b/doc/rfc/rfc3727.txt
new file mode 100644
index 0000000000..97c4126d71
--- /dev/null
+++ b/doc/rfc/rfc3727.txt
@@ -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]
+
+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]
+
+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]
+
+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]
+
+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]
+