+++ /dev/null
-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]
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
-INTERNET-DRAFT S. Legg
-draft-legg-ldapext-component-matching-10.txt Adacel Technologies
-Intended Category: Standard Track April 2, 2003
+Network Working Group S. Legg
+Request for Comments: 3687 Adacel Technologies
+Category: Standards Track February 2004
- LDAP & X.500 Component Matching Rules
+ Lightweight Directory Access Protocol (LDAP)
+ and X.500 Component Matching Rules
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+Status of this Memo
- 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
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
- 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.
+Abstract
- 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 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.
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
- Distribution of this document is unlimited. Comments should be sent
- to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
- or to the author.
- This Internet-Draft expires on 2 October 2003.
-Abstract
- The syntaxes of attributes in a Lightweight Directory Access Protocol
- or X.500 directory range from simple data types, such as text string,
- integer, or boolean, to complex structured data types, such as the
- syntaxes of the directory schema operational attributes. The
- matching rules defined for the complex syntaxes, if any, usually only
- provide the most immediately useful matching capability. This
- document defines generic matching rules that can match any user
- selected component parts in an attribute value of any arbitrarily
-Legg Expires 2 October 2003 [Page 1]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
- complex attribute syntax.
-
-
-1. Table of Contents
-
- 1. Table of Contents ............................................. 2
- 2. Introduction .................................................. 2
- 3. Conventions ................................................... 4
- 4. ComponentAssertion ............................................ 5
- 4.1 Component Reference ....................................... 5
- 4.1.1 Component Type Substitutions ......................... 7
- 4.1.2 Referencing SET, SEQUENCE and CHOICE Components ...... 8
- 4.1.3 Referencing SET OF and SEQUENCE OF Components ........ 9
- 4.1.4 Referencing Components of Parameterized Types ........ 10
- 4.1.5 Component Referencing Example ........................ 10
- 4.1.6 Referencing Components of Open Types ................. 11
- 4.1.6.1 Open Type Referencing Example ................... 12
- 4.1.7 Referencing Contained Types .......................... 13
- 4.1.7.1 Contained Type Referencing Example .............. 14
- 4.2 Matching of Components .................................... 15
- 4.2.1 Applicability of Existing Matching Rules ............. 16
- 4.2.1.1 String Matching ................................. 16
- 4.2.1.2 Telephone Number Matching ....................... 17
- 4.2.1.3 Distinguished Name Matching ..................... 17
- 4.2.2 Additional Useful Matching Rules ..................... 17
- 4.2.2.1 The rdnMatch Matching Rule ...................... 17
- 4.2.2.2 The presentMatch Matching Rule .................. 18
- 4.2.3 Summary of Useful Matching Rules ..................... 19
- 5. ComponentFilter ............................................... 21
- 6. The componentFilterMatch Matching Rule ........................ 22
- 7. Equality Matching of Complex Components ....................... 23
- 7.1 The OpenAssertionType Syntax .............................. 24
- 7.2 The allComponentsMatch Matching Rule ...................... 25
- 7.3 Deriving Component Equality Matching Rules ................ 27
- 7.4 The directoryComponentsMatch Matching Rule ................ 28
- 8. Component Matching Examples ................................... 29
- 9. Security Considerations ....................................... 36
- 10. Acknowledgements ............................................. 37
- 11. Normative References ......................................... 37
- 12. Informative References ....................................... 38
- 13. Copyright Notice ............................................. 38
- 14. Author's Address ............................................. 39
-
-
-2. Introduction
-
- The structure or data type of data held in an attribute of an LDAP
- [RFC3377] or X.500 [18] directory is described by the attribute's
-
-
-
-Legg Expires 2 October 2003 [Page 2]
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 1]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+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
+
+
+
- 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
+
+
+
+
+Legg Standards Track [Page 2]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+1. Introduction
+
+ The structure or data type of data held in an attribute of a
+ Lightweight Directory Access Protocol (LDAP) [7] or X.500 [19]
+ directory is described by the attribute's syntax. Attribute syntaxes
+ range from simple data types, such as text string, integer, or
+ boolean, to complex data types, for example, the syntaxes of the
+ directory schema operational attributes.
+
+ In X.500, the attribute syntaxes are explicitly described by Abstract
+ Syntax Notation One (ASN.1) [13] type definitions. ASN.1 type
+ notation has a number of simple data types (e.g., PrintableString,
+ INTEGER, BOOLEAN), and combining types (i.e., SET, SEQUENCE, SET OF,
+ SEQUENCE OF, and CHOICE) for constructing arbitrarily complex data
+ types from simpler component types. In LDAP, the attribute syntaxes
+ are usually described in Augmented Backus-Naur Form (ABNF) [2],
+ though there is an implied association between the LDAP attribute
syntaxes and the X.500 ASN.1 types. To a large extent, the data
types of attribute values in either an LDAP or X.500 directory are
described by ASN.1 types. This formal description can be exploited
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.
+ using ASN.1 type notation. All of the type notations defined in
+ X.680 [13] are supported.
- Section 4 describes the ComponentAssertion, a testable assertion
+ Section 3 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
+ 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 6 defines the componentFilterMatch matching rule, which
+ Section 5 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]
+Legg Standards Track [Page 3]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+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.
- 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
+ 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
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
+ 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
+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.
- 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]
+
+
+
+Legg Standards Track [Page 4]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
- 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].
+ 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.
-4. ComponentAssertion
+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
+ 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
+ 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.
+ 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):
ComponentReference ::= UTF8String
MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
- rule. MATCHING-RULE.&AssertionType is an open type (formally known
+ rule. MATCHING-RULE.&AssertionType is an open type (formerly known
as the ANY type).
The "component" field of a ComponentAssertion identifies which
component part of a value of some ASN.1 type is to be tested, the
"useDefaultValues" field indicates whether DEFAULT values are to be
substituted for absent component values, the "rule" field indicates
+
+
+
+
+
+Legg Standards Track [Page 5]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
how the component is to be tested, and the "value" field is an
asserted ASN.1 value against which the component is tested. The
ASN.1 type of the asserted value is determined by the chosen rule.
The fields of a ComponentAssertion are described in detail in the
following sections.
+3.1. Component Reference
-4.1 Component Reference
-
- The component field in a ComponentAssertion is a UTF8 character
+ 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
-
-
-
-Legg Expires 2 October 2003 [Page 5]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
- the notation defined in Clause 14 of [11]:
+ the notation defined in Clause 14 of X.680 [13]:
component-reference = ComponentId *( "." ComponentId )
ComponentId = identifier /
decimal-digit = %x30-39 ; "0" to "9"
non-zero-digit = %x31-39 ; "1" to "9"
+
+
+
+
+
+
+
+Legg Standards Track [Page 6]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
An <identifier> conforms to the definition of an identifier in ASN.1
- notation (Clause 11.3 of [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.
+ 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 in [7].
+ 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,
+ the next level of nesting of an ASN.1 combining type, i.e., SET,
SEQUENCE, SET OF, SEQUENCE OF, or CHOICE, or a specific type within
an ASN.1 open type.
A component reference is always considered in the context of a
particular complex ASN.1 type. When applied to the ASN.1 type the
component reference identifies a specific component type. When
-
-
-
-Legg Expires 2 October 2003 [Page 6]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
applied to a value of the ASN.1 type a component reference identifies
zero, one or more component values of that component type. The
component values are potentially in a DEFAULT value if
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 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
+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
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.
+ after the last ComponentId, except as allowed by Section 3.2.
+
+
+
+Legg Standards Track [Page 7]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
If the ASN.1 type is an ASN.1 type reference then the component type
is taken to be the actual definition on the right hand side of the
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 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 [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
+ 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.
-
-
-Legg Expires 2 October 2003 [Page 7]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
If the ASN.1 type is a selection type other than one used in the list
of components for a SET or SEQUENCE type then the component type is
taken to be the selected alternative type from the named CHOICE.
- If the ASN.1 type is a TypeFromObject (Clause 15 of [13]) then the
- component type is taken to be the denoted type.
-
- If the ASN.1 type is a ValueSetFromObjects (Clause 15 of [13]) then
- the component type is taken to be the governing type of the denoted
- values.
+ 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.
-4.1.2 Referencing SET, SEQUENCE and CHOICE Components
+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
+ 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
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
+ 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.
+
+
+Legg Standards Track [Page 8]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ The COMPONENTS OF notation in Clause 24 of X.680 [13] augments the
+ defined list of components in a SET or SEQUENCE type by including all
+ the components of another defined SET or SEQUENCE type respectively.
These included components are referenced directly by identifier as
though they were defined in-line in the SET or SEQUENCE type
containing the COMPONENTS OF notation.
- The SelectionType (Clause 29 of [11]), when used in the list of
+ 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 [11].
-
-
-
-Legg Expires 2 October 2003 [Page 8]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
+ Clause 20.5 of X.680 [13].
The EMBEDDED PDV type is treated as though it is the SEQUENCE type
- defined in Clause 32.5 of [11].
+ 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 [16].
+ 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 39.5 of [11].
+ 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 [13].
+ defined in Annex C of X.681 [14].
The <identifier> form MUST NOT be used on any other ASN.1 type.
-
-4.1.3 Referencing SET OF and SEQUENCE OF Components
+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.
+ 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-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
+ The <from-end> form of ComponentId may be used to identify one
instance of the component type of the SET OF or SEQUENCE OF type,
where "-1" is the last instance, "-2" is the second last instance,
+
+
+
+
+Legg Standards Track [Page 9]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
and so on. If <from-end> references a lower numbered instance than
the first instance in a particular value of the SET OF or SEQUENCE OF
type then there is no corresponding component value.
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
+ The <all> form of ComponentId may be used to simultaneously identify
all instances of the component type of the SET OF or SEQUENCE OF
type. It is through the <all> form that a component reference can
identify more than one component value. However, if a particular
- value of the SET OF or SEQUENCE OF type is an empty list there are no
-
-
-
-Legg Expires 2 October 2003 [Page 9]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
- corresponding component values.
+ 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,
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
+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 [15] have been
+ the type is treated as though the DummyReferences [16] have been
substituted with the actual parameters.
-
-4.1.5 Component Referencing Example
+3.1.5. Component Referencing Example
Consider the following ASN.1 type definitions.
part3 [2] SET OF OBJECT IDENTIFIER,
part4 [3] ExampleChoice }
+
+
+
+
+Legg Standards Track [Page 10]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
ExampleSet ::= SET {
option PrintableString,
setting BOOLEAN }
ExampleType having the ASN.1 tagged type [0] INTEGER.
The component reference "part2" identifies a component of a value of
-
-
-
-Legg Expires 2 October 2003 [Page 10]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
ExampleType having the ASN.1 type of [1] ExampleSet
The component reference "part2.option" identifies a component of a
value of ExampleType having the ASN.1 type of OCTET STRING.
-4.1.6 Referencing Components of Open Types
+
+
+
+
+
+
+
+Legg Standards Track [Page 11]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+3.1.6. Referencing Components of Open Types
If a sequence of ComponentIds identifies an ObjectClassFieldType
- denoting an open type (e.g. ATTRIBUTE.&Type denotes an open type)
+ 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
+ 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
+ types. The <select> form of ComponentId may be used to identify one
of these permissible types in an open type. Subcomponents of that
type can then be identified with further ComponentIds.
The other components constraining the open type are termed the
- referenced components (using the terminology in [14]). The <select>
- form contains a list of one or more values which take the place of
- the value(s) of the referenced component(s) to uniquely identify one
- of the permissable types of the open type.
-
-
-
-Legg Expires 2 October 2003 [Page 11]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
+ 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
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]).
+ 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
+ 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
enclosing type then there are no corresponding component values for
the open type.
+3.1.6.1. Open Type Referencing Example
-4.1.6.1 Open Type Referencing Example
-
- The ASN.1 type AttributeTypeAndValue from [8] describes a single
+ The ASN.1 type AttributeTypeAndValue [10] describes a single
attribute value of a nominated attribute type.
+
+
+
+
+Legg Standards Track [Page 12]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
AttributeTypeAndValue ::= SEQUENCE {
type ATTRIBUTE.&id ({SupportedAttributes}),
value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
The component reference "value" on AttributeTypeAndValue refers to
the open type.
-
-
-
-Legg Expires 2 October 2003 [Page 12]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
One of the X.500 standard attributes is facsimileTelephoneNumber
- [10], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is
+ [12], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is
defined to have the following syntax.
FacsimileTelephoneNumber ::= SEQUENCE {
"value.(2.5.4.23).telephoneNumber".
-4.1.7 Referencing Contained Types
+
+
+
+
+
+
+
+Legg Standards Track [Page 13]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+3.1.7. Referencing Contained Types
Sometimes the contents of a BIT STRING or OCTET STRING value are
required to be the encodings of other ASN.1 values of specific ASN.1
types. For example, the extnValue component of the Extension type
- component in the Certificate type [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.
+ 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.
+ 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
+ some other component in an outer enclosing type (e.g., in a
certificate Extension, extnValue is constrained by the chosen
extnId). In these cases the next ComponentId, if any, MUST be of the
<select> form.
For the purpose of building component references, the content of the
-
-
-
-Legg Expires 2 October 2003 [Page 13]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
extnValue OCTET STRING in the Extension type is assumed to be an open
type having a notional component relation constraint with the extnId
- component as the single referenced component, i.e.
+ component as the single referenced component, i.e.,
EXTENSION.&ExtnType ({ExtensionSet}{@extnId})
having a notional component relation constraint with the
identification component as the single referenced component.
+3.1.7.1. Contained Type Referencing Example
-4.1.7.1 Contained Type Referencing Example
-
- The Extension ASN.1 type from [9] describes a single certificate
+ The Extension ASN.1 type [11] describes a single certificate
extension value of a nominated extension type.
+
+
+
+
+
+
+
+Legg Standards Track [Page 14]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
Extension ::= SEQUENCE {
extnId EXTENSION.&id ({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
"extnValue.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.
+ 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,
The component reference "extnValue.content.(2.5.29.19)" on Extension
specifies a BasicConstraintsSyntax extension value and the component
reference "extnValue.content.(2.5.29.19).cA" identifies the cA
-
-
-
-Legg Expires 2 October 2003 [Page 14]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
component of a BasicConstraintsSyntax extension value.
-
-4.2 Matching of Components
+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
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
+ 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
+
+
+
+
+Legg Standards Track [Page 15]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ Section 3.1.1 are performed as required to reduce the component type
to the same type as the attribute syntax expected by the matching
rule.
- If a matching rule applies to more than one attribute syntax (e.g.
- objectIdentifierFirstComponentMatch [10]) then the minimum number of
+ 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 7.2) then the
+ (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
+ (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.
+ 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:
+ The ComponentAssertion is Undefined if:
a) the matching rule in the ComponentAssertion is not known to the
evaluating procedure,
-
-
-Legg Expires 2 October 2003 [Page 15]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
- b) if the matching rule is not applicable to the referenced component
+ 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
e) the implementation does not support the particular combination of
component reference and matching rule.
- If the ComponentAssertion is not undefined then the
+ 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
+
+
+Legg Standards Track [Page 16]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+3.2.1. Applicability of Existing Matching Rules
+
+3.2.1.1. String Matching
ASN.1 has a number of built in restricted character string types with
different character sets and/or different character encodings. A
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
+ 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.
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
+ 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.
-
-
-
-Legg Expires 2 October 2003 [Page 16]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
The assertion syntax of the string matching rules is still
DirectoryString regardless of the string syntax of the component
being matched. Thus an implementation will be called upon to compare
corresponding characters are representable in both character sets.
Otherwise matching returns FALSE.
+3.2.1.2. Telephone Number Matching
-4.2.1.2 Telephone Number Matching
-
- Early editions of X.520 [10] gave the syntax of the telephoneNumber
+ Early editions of X.520 [12] gave the syntax of the telephoneNumber
attribute as a constrained PrintableString. The fourth edition of
X.520 equates the ASN.1 type name TelephoneNumber to the constrained
PrintableString and uses TelephoneNumber as the attribute and
assertion syntax. For the purposes of component matching,
+
+
+
+
+
+Legg Standards Track [Page 17]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted
to be applied to any PrintableString value, as well as to
TelephoneNumber values.
-
-4.2.1.3 Distinguished Name Matching
+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
distinguishedNameMatch is also permitted to be applied to values of
the RDNSequence type.
-
-4.2.2 Additional Useful Matching Rules
+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
+ in ComponentAssertions. These rules may also be used in
extensibleMatch search filters [3].
-
-4.2.2.1 The rdnMatch Matching Rule
+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 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.
+ 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:
-
-
-Legg Expires 2 October 2003 [Page 17]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
( 1.2.36.79672281.1.13.3 NAME 'rdnMatch'
SYNTAX 1.2.36.79672281.1.5.0 )
( 1.2.36.79672281.1.5.0 DESC 'RDN' )
The LDAP-specific encoding for a value of the RDN syntax is given by
- the <RelativeDistinguishedNameValue> rule in [7].
+ the <RelativeDistinguishedNameValue> rule [9].
The X.500-style definition for rdnMatch is:
assertion value are the same RDN, using the same RDN comparison
method as distinguishedNameMatch.
+
+
+
+
+
+Legg Standards Track [Page 18]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
When using rdnMatch to match components of DNs it is important to
note that the LDAP-specific encoding of a DN [5] reverses the order
- of the RDNs. So for the DN represented in LDAP as "cn=Steven
- Legg,o=Adacel,c=AU", the RDN "cn=Steven Legg" corresponds to the
- component reference "3", or alternatively, "-1".
-
+ 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
+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
( 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 <NullValue> rule [9].
The X.500-style definition for presentMatch is:
SYNTAX NULL
ID { 1 2 36 79672281 1 13 5 } }
-
-
-Legg Expires 2 October 2003 [Page 18]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
When used in a extensible match filter item, presentMatch behaves
like the "present" case of a regular search filter. In a
ComponentAssertion, presentMatch evaluates to TRUE if and only if the
component 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 Standards Track [Page 19]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+3.2.3. Summary of Useful Matching Rules
-Legg Expires 2 October 2003 [Page 19]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
+ 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 |
| octetStringMatch | OCTET STRING |
| octetStringOrderingMatch | |
| octetStringSubstringsMatch | |
+
+
+
+Legg Standards Track [Page 20]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+--------------------------------+------------------------------+
| presentMatch | any ASN.1 type |
+--------------------------------+------------------------------+
+--------------------------------+------------------------------+
| telephoneNumberMatch | PrintableString |
| telephoneNumberSubstringsMatch | TelephoneNumber |
-
-
-
-Legg Expires 2 October 2003 [Page 20]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
+--------------------------------+------------------------------+
| uTCTimeMatch | UTCTime |
| uTCTimeOrderingMatch | |
+--------------------------------+------------------------------+
- Note that the allComponentsMatch matching rule defined in Section 7.2
+ 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.
-
-5. ComponentFilter
+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
within an ASN.1 value.
The ComponentFilter assertion, an expression of ComponentAssertions,
- evaluates to either TRUE, FALSE or undefined for each tested ASN.1
+ evaluates to either TRUE, FALSE or Undefined for each tested ASN.1
value.
A ComponentFilter is described by the following ASN.1 type (assumed
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.
+ ComponentAssertion is FALSE, and evaluates to Undefined otherwise.
+
+
+
+
+
+
+
+Legg Standards Track [Page 21]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
The "and" of a sequence of component filters evaluates to TRUE if the
sequence is empty or if each component filter evaluates to TRUE,
evaluates to FALSE if at least one component filter is FALSE, and
- evaluates to undefined otherwise.
+ evaluates to Undefined otherwise.
The "or" of a sequence of component filters evaluates to FALSE if the
sequence is empty or if each component filter evaluates to FALSE,
evaluates to TRUE if at least one component filter is TRUE, and
- evaluates to undefined otherwise.
-
-
-
-Legg Expires 2 October 2003 [Page 21]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
+ 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.
+ and evaluates to Undefined otherwise.
-
-6. The componentFilterMatch Matching Rule
+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
( 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].
+ 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 [7], [7] is to be taken as definitive. The GSER
+ determined by GSER, GSER is to be taken as definitive. The GSER
encoding of a ComponentFilter is described by the following
equivalent ABNF:
or-filter = or-chosen SequenceOfComponentFilter
not-filter = not-chosen ComponentFilter
+
+
+
+Legg Standards Track [Page 22]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
item-chosen = %x69.74.65.6D.3A ; "item:"
and-chosen = %x61.6E.64.3A ; "and:"
or-chosen = %x6F.72.3A ; "or:"
*( "," sp ComponentFilter) ] sp "}"
ComponentAssertion = "{" [ sp component "," ]
-
-
-
-Legg Expires 2 October 2003 [Page 22]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
[ sp useDefaultValues "," ]
sp rule ","
sp assertion-value sp "}"
msp = 1*%x20 ; one or more space characters
The ABNF for <Value>, <StringValue>, <ObjectIdentifierValue> and
- <BooleanValue> is defined in [7].
+ <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 [7] provides a human readable text encoding for a
+ <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 [8] for componentFilterMatch is:
+ 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
+ componentFilterMatch, so componentFilterMatch may be nested. The
component references in a nested componentFilterMatch are relative to
+
+
+
+
+
+Legg Standards Track [Page 23]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
the component corresponding to the containing ComponentAssertion. In
- Section 8, an example search on the seeAlso attribute shows this
+ Section 7, an example search on the seeAlso attribute shows this
usage.
-
-7. Equality Matching of Complex Components
+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
+ syntax is the same as some purported (i.e., assertion) value by using
a complicated ComponentFilter that tests if corresponding components
are the same. However, it would be more convenient to be able to
-
-
-
-Legg Expires 2 October 2003 [Page 23]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
present a whole assertion value to a matching rule that could do the
component-wise comparison of an attribute value with the assertion
value for any arbitrary attribute syntax. Similarly, the ability to
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
+ 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 7.3.
+ matching semantics are described in Section 6.3.
- The directoryComponentsMatch defined in Section 7.4 is a derivation
+ 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
any matching rules derived from them are collectively called
component equality matching rules.
-
-7.1 The OpenAssertionType Syntax
+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
X.500 MATCHING-RULE information object. OpenAssertionType MUST NOT
be used as the attribute syntax in an attribute type definition.
+
+
+Legg Standards Track [Page 24]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
Unless explicitly varied by the description of a particular matching
rule, if an OpenAssertionType assertion value appears in a
ComponentAssertion its LDAP-specific encoding is described by the
- <Value> rule in [7], otherwise its LDAP-specific encoding is 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:
-
-
-Legg Expires 2 October 2003 [Page 24]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )
-
-7.2 The allComponentsMatch Matching Rule
+6.2. The allComponentsMatch Matching Rule
The LDAP-style definition for allComponentsMatch is:
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]
+Legg Standards Track [Page 25]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+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.
+ 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
values have the same number of arcs and corresponding arcs are the
same.
+
+
+Legg Standards Track [Page 26]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
l) Two OCTET STRING values are the same if and only if the values
have the same number of octets and corresponding octets are the
same.
same base and represent the same real number. The special values
for REAL are zero, PLUS-INFINITY and MINUS-INFINITY.
-
-
-Legg Expires 2 October 2003 [Page 26]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
- n) Two RELATIVE-OID [12] values are the same if and only if the
- values have the same number of arcs and corresponding arcs are the
- same. The respective starting nodes for the RELATIVE-OID values
- are disregarded in the comparison, i.e. they are assumed to be the
+ 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.
+ 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
+ The allComponentsMatch rule may be used as the defined equality
matching rule for an attribute.
-
-7.3 Deriving Component Equality Matching Rules
+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
|
|
+
+
+
+
+
+Legg Standards Track [Page 27]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
Usually, all component values of a particular ASN.1 type are to be
- matched the same way. An ASN.1 type reference (e.g.
- DistinguishedName) or an ASN.1 built-in type name (e.g. INTEGER) in
+ matched the same way. An ASN.1 type reference (e.g.,
+ DistinguishedName) or an ASN.1 built-in type name (e.g., INTEGER) in
the Component column of the table specifies that the nominated
equality matching rule is to be applied to all values of the named
type, regardless of context.
An ASN.1 type reference with a component reference appended
(separated by a ".") specifies that the nominated matching rule
applies only to the identified components of values of the named
-
-
-
-Legg Expires 2 October 2003 [Page 27]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
type. Other component values that happen to be of the same ASN.1
type are not selected.
- Additional type substitutions as described in Section 4.2 are assumed
+ 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.
the matching semantics of the derived rule. Notionally,
allComponentsMatch has an empty table.
- A row specifying values of an outer containing type (e.g.
+ 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
+ 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
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
+6.4. The directoryComponentsMatch Matching Rule
The directoryComponentsMatch matching rule is derived from the
allComponentsMatch matching rule.
+
+
+
+
+
+
+Legg Standards Track [Page 28]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
The LDAP-style definition for directoryComponentsMatch is:
( 1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch'
ID { 1 2 36 79672281 1 13 7 } }
The matching semantics of directoryComponentsMatch are described by
- the following table, using the convention described in Section 7.3.
-
-
-
-Legg Expires 2 October 2003 [Page 28]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
+ the following table, using the convention described in Section 6.3.
ASN.1 Type | Matching Rule
=========================================+========================
VideotexString | caseIgnoreMatch
VisibleString | caseIgnoreMatch
- Notes.
+ Notes:
1) The DistinguishedName type is defined by assignment to be the same
- as the RDNSequence type. Some types (e.g. Name and LocalName)
+ 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.
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.
+ ASN.1 type [12] is defined as a constrained PrintableString.
PrintableString component values that are part of a
FacsimileTelephoneNumber value can be identified separately from
+
+
+
+Legg Standards Track [Page 29]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
other components of PrintableString type by the specifier
FacsimileTelephoneNumber.telephoneNumber, so that
telephoneNumberMatch can be selectively applied. The fourth
the row for FacsimileTelephoneNumber.telephoneNumber components
redundant.
- The directoryComponentsMatch rule MAY be used as the defined equality
+ The directoryComponentsMatch rule may be used as the defined equality
matching rule for an attribute.
-
-8. Component Matching Examples
-
-
-
-Legg Expires 2 October 2003 [Page 29]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
+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 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 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 [8], and holds the definitions of
+ 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:
mandatories [3] SET OF ATTRIBUTE.&id OPTIONAL,
optionals [4] SET OF ATTRIBUTE.&id OPTIONAL }
+
+
+
+Legg Standards Track [Page 30]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
ObjectClassKind ::= ENUMERATED {
abstract (0),
structural (1),
object class identified by the OBJECT IDENTIFIER 2.5.6.18:
(objectClasses:componentFilterMatch:=
-
-
-
-Legg Expires 2 October 2003 [Page 30]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
- item:{ component "identifier",
- rule objectIdentifierMatch, value 2.5.6.18 })
+ 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
object class definitions that have descriptions, regardless of the
contents of the description string:
+
+
+
+
+Legg Standards Track [Page 31]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
(objectClasses:componentFilterMatch:=
item:{ component "description",
rule presentMatch, value NULL })
rule presentMatch, value NULL })
The following search filter finds object class definitions with the
-
-
-
-Legg Expires 2 October 2003 [Page 31]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
word "bogus" in the description:
(objectClasses:componentFilterMatch:=
rule caseIgnoreSubstringsMatch,
value { any:"bogus" } })
- The assertion value is of the SubstringAssertion syntax, i.e.
+ The assertion value is of the SubstringAssertion syntax, i.e.,
SubstringAssertion ::= SEQUENCE OF CHOICE {
initial [0] DirectoryString {ub-match},
The useDefaultValues flag in the ComponentAssertion defaults to TRUE
so the componentFilterMatch rule treats an absent "obsolete"
component as being present and set to FALSE. The following search
+
+
+
+Legg Standards Track [Page 32]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
filter finds only object class definitions where the "obsolete"
component has been explicitly set to FALSE, rather than implicitly
defaulting to FALSE:
The "information.kind" component of the ObjectClassDescription is an
ENUMERATED type. The allComponentsMatch matching rule can be used to
-
-
-
-Legg Expires 2 October 2003 [Page 32]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
match values of an ENUMERATED type. The following search filter
finds object class definitions for auxiliary object classes:
components because of the distinction between an absent list of
instances and a present, but empty, list of instances. The following
search filter finds object class definitions with less than three
+
+
+
+
+Legg Standards Track [Page 33]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
names, including object class definitions with a present but empty
list of names, but does not find object class definitions with an
absent list of names:
definitions with an absent list of names the following search filter
would be used:
-
-
-
-Legg Expires 2 October 2003 [Page 33]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
(objectClasses:componentFilterMatch:=or:{
not:item:{ component "name", rule presentMatch, value NULL },
item:{ component "name.0",
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
+
+
+
+Legg Standards Track [Page 34]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType ({SupportedAttributes}),
value AttributeValue ({SupportedAttributes}{@type}) }
The seeAlso attribute has the DistinguishedName syntax. The
following search filter finds seeAlso attribute values containing the
-
-
-
-Legg Expires 2 October 2003 [Page 34]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
RDN, "o=Adacel", anywhere in the DN:
(seeAlso:componentFilterMatch:=
item:{ component "*", rule rdnMatch, value "o=Adacel" })
The following search filter finds all seeAlso attribute values with
- "cn=Steven Legg" as the RDN of the named entry (i.e. the "first" RDN
+ "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:=
rule objectIdentifierMatch,
value telephoneNumber } } })
+
+
+Legg Standards Track [Page 35]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
The following search filter would find all seeAlso attribute values
containing the attribute types commonName and telephoneNumber, but
not necessarily in the same RDN:
attribute value in any AttributeTypeAndValue of any RDN:
(seeAlso:componentFilterMatch:=
-
-
-
-Legg Expires 2 October 2003 [Page 35]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
item:{ component "*.*.value.(2.5.4.11)",
rule caseIgnoreSubstringsMatch,
value { any:"Adacel" } })
not:item:{ rule integerOrderingMatch, value 3 },
item:{ rule integerOrderingMatch, value 8 } })
+
+
+
+
+Legg Standards Track [Page 36]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
An entry whose productCodes attribute contains only the values 1 and
10 will not match the above filter.
-
-9. Security Considerations
+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.
+ 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
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 Expires 2 October 2003 [Page 36]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- being a suitable matching rule. Such attribute types ought to be
- properly protected with appropriate access controls.
-10. Acknowledgements
- The author would like to thank Tom Gindin for private email
- discussions that clarified and refined the ideas presented in this
- document.
-11. Normative References
+
+
+Legg Standards Track [Page 37]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): rdnMatch
+ Object Identifier: 1.2.36.79672281.1.13.3
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: other (matching rule)
+ Specification: RFC 3687
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): presentMatch
+ Object Identifier: 1.2.36.79672281.1.13.5
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: other (matching rule)
+ Specification: RFC 3687
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): allComponentsMatch
+ Object Identifier: 1.2.36.79672281.1.13.6
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: other (matching rule)
+ Specification: RFC 3687
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): directoryComponentsMatch
+ Object Identifier: 1.2.36.79672281.1.13.7
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: other (matching rule)
+ Specification: RFC 3687
+ Author/Change Controller: IESG
+
+ The object identifiers have been assigned for use in this
+ specification by Adacel Technologies, under an arc assigned to Adacel
+ by Standards Australia.
+
+11. References
+
+11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
- [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+
+
+
+
+Legg Standards Track [Page 38]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3): 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.
+ [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
+ 63, RFC 3629, November 2003.
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ [7] 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] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol
+ (LDAP)", BCP 64, RFC 3383, September 2002.
- [8] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+ [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
- [9] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
+ [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
-
-Legg Expires 2 October 2003 [Page 37]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+ [14] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2:2002,
+ Information technology - Abstract Syntax Notation One (ASN.1):
+ Information object specification
- [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
+Legg Standards Track [Page 39]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
- [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):
+ [15] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3:2002,
+ 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):
+ [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
- [16] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
- Information Technology - ASN.1 encoding rules: Specification of
+ [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
-12. Informative References
-
- [17] Howes, T., "The String Representation of LDAP Search Filters",
+ [18] 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,
+ [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
-13. Copyright Notice
+ 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.
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ 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.
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
-Legg Expires 2 October 2003 [Page 38]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+Legg Standards Track [Page 40]
+\f
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
-14. Author's Address
+13. Author's Address
Steven Legg
Adacel Technologies Ltd.
AUSTRALIA
Phone: +61 3 8530 7710
- Fax: +61 3 8530 7888
+ Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
-Appendix A - Changes From Previous Drafts
-
-A.1 Changes in Draft 01
-
- Section 4.1.7 was added to enable component matching of values
- embedded in encoded form into BIT STRINGs or OCTET STRINGs. In
- particular, this is to allow component matching of values in
- Certificate extensions. The <content> rule was added in Section 4.1
- to allow the OCTET STRING contents to be treated as either raw octets
- or as an embedded value.
-
- References to a companion document summarizing the ASN.1 types of
- LDAP syntaxes were removed to avoid holding up this document.
-
- The OpenType syntax was renamed to OpenAssertionType.
-Legg Expires 2 October 2003 [Page 39]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- Object identifiers for the new syntax and matching rule definitions
- have been allocated from an arc belonging to Adacel Technologies Ltd.
-A.2 Changes in Draft 02
- The context specific tagging in the ComponentAssertion ASN.1 type was
- unnecessary and has been removed.
- The encoding of OpenAssertionType assertion values outside of
- ComponentAssertions has been clarified, and the description of
- OpenAssertionType has been promoted to its own section.
-A.3 Changes in Draft 03
- The default matching by allComponentsMatch of component values of BIT
- STRING types with named bit lists has been changed to ignore trailing
- zero bits.
- Typographical errors in the <SafeUTF8Character> rule have been fixed.
-A.4 Changes in Draft 04
- When the matching rule in a ComponentAssertion has a variable
- assertion syntax it is not possible to determine the syntax of the
- value component from the ComponentAssertion alone when the associated
- component reference has referenced through an open type. Deducing
- what that syntax should be from inspection of the other
- ComponentAssertions in a ComponentFilter is difficult to implement in
- any comprehensive way. The <select> form of ComponentId has been
- introduced so that the syntax can always be determined from the
- contents of the ComponentAssertion alone. This not only simplifies
- implementation but can lead to simpler ComponentFilters since there
- is no longer a requirement to test that the components constraining
- an open type have particular values. The open type referencing
- example has been changed accordingly. The contained type referencing
- example has also been changed because it is an example of a contained
- open type.
- The presentationAddressMatch rule is not commutative so it has been
- removed from the table defining directoryComponentsMatch. The default
- behaviour of allComponentsMatch is already a suitable commutative
- substitute for matching PresentationAddress values.
- The null character has been included in the range of legal characters
- for <SafeUTF8Character>.
- The ASN.1 type of the notional iteration count associated with SET OF
- and SEQUENCE OF values has been refined to INTEGER (0..MAX).
-Legg Expires 2 October 2003 [Page 40]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- The encoding rules in Section 8 (now draft-legg-ldap-gser-xx.txt)
- have been formally named the Generic String Encoding Rules (GSER) and
- a transfer syntax object identifier has been assigned.
- The term "LDAP string encoding" has been replaced by the term "native
- LDAP-specific encoding" to align with terminology anticipated to be
- used in the revision of RFC 2252.
-A.5 Changes in Draft 05
- Reformatted the draft to conform to recent and proposed RFC editorial
- policy.
- The use of the <oid> rule from RFC 2252 has been replaced by a local
- definition to specifically outlaw leading zero characters in OBJECT
- IDENTIFIER components.
- Provisions for the RELATIVE-OID ASN.1 type defined in Amendment 1 to
- X.680 have been added.
- The comparison of REAL values has been clarified and the GSER
- encoding of REAL values has been extended.
- Removed extraneous spaces from example DNs.
-A.6 Changes in Draft 06
- An ABNF syntax error in the <exponent> rule was fixed.
-A.7 Changes in Draft 07
- The term "native LDAP encoding" has been replaced by the term "LDAP-
- specific encoding" to align with terminology anticipated to be used
- in the revision of RFC 2252.
- Section 8 has been extracted to become a separate Internet draft,
- draft-legg-ldap-gser-00.txt. The specifications for ChoiceOfStrings
- types have also been moved to this new Internet draft. Various
- editorial changes have been made to this draft to accommodate this
- split.
-A.8 Changes in Draft 08
- The enumeratedMatch matching rule duplicates a subset of the
- functionality of allComponentsMatch so it has been removed. The
- enumeratedMatch rule has been replaced by allComponentsMatch in the
- examples. The description of the OpenAssertionType syntax has been
- moved into Section 7.
-Legg Expires 2 October 2003 [Page 41]
+Legg Standards Track [Page 41]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-
-
-A.9 Changes in Draft 09
-
- The associated type for the EXTERNAL type has been changed from the
- one defined in X.680 for ASN.1 value notation to the one defined in
- X.690 for BER.
-
-A.10 Changes in Draft 10
-
- The definition of ComponentAssertion has been changed to make the
- "component" field optional, and non-empty when present. This change
- allows the specification of search filters where all the assertions
- must match the same value of an attribute. Normally each assertion is
- free to match any of the values of a multi-valued attribute.
- Corresponding changes have been made to the ABNF in Section 6. An
- illustrative example has been added to Section 8.
-
- Conditions on whether a ComponentAssertion returns FALSE or undefined
- when some part of the component references identifies an open type
- have been removed from Section 4.2. The changes in draft 04 that
- introduced the <select> form of ComponentId made these conditions
- unnecessary and inappropriate.
-
-
-
+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 Expires 2 October 2003 [Page 42]
+Legg Standards Track [Page 42]
\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga, Ed.
+Request for Comments: 3698 OpenLDAP Foundation
+Updates: 2798 February 2004
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Additional Matching Rules
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document provides a collection of matching rules for use with
+ the Lightweight Directory Access Protocol (LDAP). As these matching
+ rules are simple adaptations of matching rules specified for use with
+ the X.500 Directory, most are already in wide use.
+
+Table of Contents
+
+ 1. Background and Intended Use. . . . . . . . . . . . . . . . . . 2
+ 2. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2.1. booleanMatch . . . . . . . . . . . . . . . . . . . . . . 2
+ 2.2. caseExactMatch . . . . . . . . . . . . . . . . . . . . . 2
+ 2.3. caseExactOrderingMatch . . . . . . . . . . . . . . . . . 3
+ 2.4. caseExactSubstringsMatch . . . . . . . . . . . . . . . . 3
+ 2.5. caseIgnoreListSubstringsMatch. . . . . . . . . . . . . . 3
+ 2.6. directoryStringFirstComponentMatch . . . . . . . . . . . 4
+ 2.7. integerOrderingMatch . . . . . . . . . . . . . . . . . . 4
+ 2.8. keywordMatch . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.9. numericStringOrderingMatch . . . . . . . . . . . . . . . 5
+ 2.10. octetStringOrderingMatch . . . . . . . . . . . . . . . . 5
+ 2.11. storedPrefixMatch. . . . . . . . . . . . . . . . . . . . 5
+ 2.12. wordMatch. . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
+ 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
+ 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
+ 6.2. Informative References . . . . . . . . . . . . . . . . . 7
+ 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9
+
+1. Background and Intended Use
+
+ This document adapts additional X.500 Directory [X.500] matching
+ rules [X.520] for use with the Lightweight Directory Access Protocol
+ (LDAP) [RFC3377]. Most of these rules are widely used today on the
+ Internet, such as in support of the inetOrgPerson [RFC2798] and
+ Policy Core Information Model [RFC3703] LDAP schemas. The rules are
+ applicable to many other applications.
+
+ This document supersedes the informational matching rules
+ descriptions provided in RFC 2798 that are now provided in this
+ document. Specifically, section 2 of this document replaces section
+ 9.3.3 of RFC 2798.
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+2. Matching Rules
+
+2.1. booleanMatch
+
+ The booleanMatch rule compares for equality a asserted Boolean value
+ with an attribute value of BOOLEAN syntax. The rule returns TRUE if
+ and only if the values are the same, i.e., both are TRUE or both are
+ FALSE. (Source: X.520)
+
+ ( 2.5.13.13 NAME 'booleanMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
+
+ The BOOLEAN (1.3.6.1.4.1.1466.115.121.1.7) syntax is described in
+ [RFC2252].
+
+2.2. caseExactMatch
+
+ The caseExactMatch rule compares for equality the asserted value with
+ an attribute value of DirectoryString syntax. The rule is identical
+ to the caseIgnoreMatch [RFC2252] rule except that case is not
+ ignored. (Source: X.520)
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ ( 2.5.13.5 NAME 'caseExactMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+2.3. caseExactOrderingMatch
+
+ The caseExactOrderingMatch rule compares the collation order of the
+ asserted string with an attribute value of DirectoryString syntax.
+ The rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule
+ except that letters are not folded. (Source: X.520)
+
+ ( 2.5.13.6 NAME 'caseExactOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+2.4. caseExactSubstringsMatch
+
+ The caseExactSubstringsMatch rule determines whether the asserted
+ value(s) are substrings of an attribute value of DirectoryString
+ syntax. The rule is identical to the caseIgnoreSubstringsMatch
+ [RFC2252] rule except that case is not ignored. (Source: X.520)
+
+ ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is
+ described in [RFC2252].
+
+2.5. caseIgnoreListSubstringsMatch
+
+ The caseIgnoreListSubstringMatch rule compares the asserted substring
+ with an attribute value which is a sequence of DirectoryStrings, but
+ where the case (upper or lower) is not significant for comparison
+ purposes. The asserted value matches a stored value if and only if
+ the asserted value matches the string formed by concatenating the
+ strings of the stored value. This matching is done according to the
+ caseIgnoreSubstringsMatch [RFC2252] rule; however, none of the
+ initial, any, or final values of the asserted value are considered to
+ match a substring of the concatenated string which spans more than
+ one of the strings of the stored value. (Source: X.520)
+
+ ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is
+ described in [RFC2252].
+
+2.6. directoryStringFirstComponentMatch
+
+ The directoryStringFirstComponentMatch rule compares for equality the
+ asserted DirectoryString value with an attribute value of type
+ SEQUENCE whose first component is mandatory and of type
+ DirectoryString. The rule returns TRUE if and only if the attribute
+ value has a first component whose value matches the asserted
+ DirectoryString using the rules of caseIgnoreMatch [RFC2252]. A
+ value of the assertion syntax is derived from a value of the
+ attribute syntax by using the value of the first component of the
+ SEQUENCE. (Source: X.520)
+
+ ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+2.7. integerOrderingMatch
+
+ The integerOrderingMatch rule compares the ordering of the asserted
+ integer with an attribute value of INTEGER syntax. The rule returns
+ True if the attribute value is less than the asserted value. (Source:
+ X.520)
+
+ ( 2.5.13.15 NAME 'integerOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is described in
+ [RFC2252].
+
+2.8. keywordMatch
+
+ The keywordMatch rule compares the asserted string with keywords in
+ an attribute value of DirectoryString syntax. The rule returns TRUE
+ if and only if the asserted value matches any keyword in the
+ attribute value. The identification of keywords in an attribute
+ value and of the exactness of match are both implementation specific.
+ (Source: X.520)
+
+ ( 2.5.13.33 NAME 'keywordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+2.9. numericStringOrderingMatch
+
+ The numericStringOrderingMatch rule compares the collation order of
+ the asserted string with an attribute value of NumericString syntax.
+ The rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule
+ except that all space characters are skipped during comparison (case
+ is irrelevant as characters are numeric). (Source: X.520)
+
+ ( 2.5.13.9 NAME 'numericStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ The NumericString (1.3.6.1.4.1.1466.115.121.1.36) syntax is described
+ in [RFC2252].
+
+2.10. octetStringOrderingMatch
+
+ The octetStringOrderingMatch rule compares the collation order of the
+ asserted octet string with an attribute value of OCTET STRING syntax.
+ The rule compares octet strings from first octet to last octet, and
+ from the most significant bit to the least significant bit within the
+ octet. The first occurrence of a different bit determines the
+ ordering of the strings. A zero bit precedes a one bit. If the
+ strings are identical but contain different numbers of octets, the
+ shorter string precedes the longer string. (Source: X.520)
+
+ ( 2.5.13.18 NAME 'octetStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ The OCTET STRING (1.3.6.1.4.1.1466.115.121.1.40) syntax is described
+ in [RFC2252].
+
+2.11. storedPrefixMatch
+
+ The storedPrefixMatch rule determines whether an attribute value,
+ whose syntax is DirectoryString is a prefix (i.e., initial substring)
+ of the asserted value, without regard to the case (upper or lower) of
+ the strings. The rule returns TRUE if and only if the attribute
+ value is an initial substring of the asserted value with
+ corresponding characters identical except possibly with regard to
+ case. (Source: X.520)
+
+ ( 2.5.13.41 NAME 'storedPrefixMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ Note: This rule can be used, for example, to compare values in the
+ Directory which are telephone area codes with a purported value
+ which is a telephone number.
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+2.12. wordMatch
+
+ The wordMatch rule compares the asserted string with words in an
+ attribute value of DirectoryString syntax. The rule returns TRUE if
+ and only if the asserted word matches any word in the attribute
+ value. Individual word matching is as for the caseIgnoreMatch
+ [RFC2252] matching rule. The precise definition of a "word" is
+ implementation specific. (Source: X.520)
+
+ ( 2.5.13.32 NAME 'wordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+3. Security Considerations
+
+ General LDAP security considerations [RFC3377] is applicable to the
+ use of this schema. Additional considerations are noted above where
+ appropriate.
+
+4. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry [RFC3383] as indicated in the following
+ template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comments
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: see comments
+ Specification: RFC 3698
+ Author/Change Controller: IESG
+ Comments:
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+\f
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ The following descriptors have been added:
+
+ NAME Type OID
+ ------------------------ ---- ---------
+ booleanMatch M 2.5.13.13
+ caseExactMatch M 2.5.13.5
+ caseExactOrderingMatch M 2.5.13.6
+ caseExactSubstringsMatch M 2.5.13.7
+ caseIgnoreListSubstringsMatch M 2.5.13.12
+ directoryStringFirstComponentMatch M 2.5.13.31
+ integerOrderingMatch M 2.5.13.15
+ keywordMatch M 2.5.13.33
+ numericStringOrderingMatch M 2.5.13.9
+ octetStringOrderingMatch M 2.5.13.18
+ storedPrefixMatch M 2.5.13.41
+ wordMatch M 2.5.13.32
+
+ where Type M is Matching Rule.
+
+ This document makes no new OID assignments. It only associates LDAP
+ matching rule descriptions with existing X.500 matching rules.
+
+5. Acknowledgments
+
+ This document borrows from [X.520], an ITU-T Recommendation.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+6.2. Informative References
+
+ [RFC2798] Smith, M., "The LDAP inetOrgPerson Object Class", RFC
+ 2798, April 2000.
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ RFC 3383, September 2002.
+
+ [RFC3703] Strassner, J., Moore, B., Moats, R. and E. Ellesson,
+ "Policy Core LDAP Schema", RFC 3703, February 2004.
+
+
+
+Zeilenga Standards Track [Page 7]
+\f
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1997).
+
+7. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+\f
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology
+ described in this document or the extent to which any license
+ under such rights might or might not be available; nor does it
+ represent that it has made any independent effort to identify any
+ such rights. Information on the procedures with respect to
+ rights in RFC documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention
+ any copyrights, patents or patent applications, or other
+ proprietary rights that may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group P. Fleming
+Request for Comments: 3712 IBM
+Category: Informational I. McDonald
+ High North
+ February 2004
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Schema for Printer Services
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document defines a schema, object classes and attributes, for
+ printers and printer services, for use with directories that support
+ Lightweight Directory Access Protocol v3 (LDAP-TS). This document is
+ based on the printer attributes listed in Appendix E of Internet
+ Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer
+ attributes are based on definitions in the Printer MIB (RFC 1759).
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Rationale for using DirectoryString Syntax . . . . . . . 3
+ 1.2. Rationale for using caseIgnoreMatch. . . . . . . . . . . 4
+ 1.3. Rationale for using caseIgnoreSubstringsMatch. . . . . . 5
+ 2. Terminology and Conventions. . . . . . . . . . . . . . . . . . 5
+ 3. Definition of Object Classes . . . . . . . . . . . . . . . . . 6
+ 3.1. slpServicePrinter. . . . . . . . . . . . . . . . . . . . 6
+ 3.2. printerAbstract. . . . . . . . . . . . . . . . . . . . . 7
+ 3.3. printerService . . . . . . . . . . . . . . . . . . . . . 8
+ 3.4. printerServiceAuxClass . . . . . . . . . . . . . . . . . 8
+ 3.5. printerIPP . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.6. printerLPR . . . . . . . . . . . . . . . . . . . . . . . 9
+ 4. Definition of Attribute Types. . . . . . . . . . . . . . . . . 9
+ 4.1. printer-uri. . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.2. printer-xri-supported. . . . . . . . . . . . . . . . . . 11
+ 4.3. printer-name . . . . . . . . . . . . . . . . . . . . . . 13
+ 4.4. printer-natural-language-configured. . . . . . . . . . . 13
+
+
+
+Fleming & McDonald Informational [Page 1]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ 4.5. printer-location . . . . . . . . . . . . . . . . . . . . 14
+ 4.6. printer-info . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.7. printer-more-info. . . . . . . . . . . . . . . . . . . . 14
+ 4.8. printer-make-and-model . . . . . . . . . . . . . . . . . 15
+ 4.9. printer-ipp-versions-supported . . . . . . . . . . . . . 15
+ 4.10. printer-multiple-document-jobs-supported . . . . . . . . 16
+ 4.11. printer-charset-configured . . . . . . . . . . . . . . . 16
+ 4.12. printer-charset-supported. . . . . . . . . . . . . . . . 16
+ 4.13. printer-generated-natural-language-supported . . . . . . 17
+ 4.14. printer-document-format-supported. . . . . . . . . . . . 17
+ 4.15. printer-color-supported. . . . . . . . . . . . . . . . . 18
+ 4.16. printer-compression-supported. . . . . . . . . . . . . . 18
+ 4.17. printer-pages-per-minute . . . . . . . . . . . . . . . . 18
+ 4.18. printer-pages-per-minute-color . . . . . . . . . . . . . 19
+ 4.19. printer-finishings-supported . . . . . . . . . . . . . . 19
+ 4.20. printer-number-up-supported. . . . . . . . . . . . . . . 19
+ 4.21. printer-sides-supported. . . . . . . . . . . . . . . . . 20
+ 4.22. printer-media-supported. . . . . . . . . . . . . . . . . 20
+ 4.23. printer-media-local-supported. . . . . . . . . . . . . . 20
+ 4.24. printer-resolution-supported . . . . . . . . . . . . . . 21
+ 4.25. printer-print-quality-supported. . . . . . . . . . . . . 22
+ 4.26. printer-job-priority-supported . . . . . . . . . . . . . 22
+ 4.27. printer-copies-supported . . . . . . . . . . . . . . . . 22
+ 4.28. printer-job-k-octets-supported . . . . . . . . . . . . . 23
+ 4.29. printer-current-operator . . . . . . . . . . . . . . . . 23
+ 4.30. printer-service-person . . . . . . . . . . . . . . . . . 24
+ 4.31. printer-delivery-orientation-supported . . . . . . . . . 24
+ 4.32. printer-stacking-order-supported . . . . . . . . . . . . 24
+ 4.33. printer-output-features-supported. . . . . . . . . . . . 25
+ 4.34. printer-aliases. . . . . . . . . . . . . . . . . . . . . 25
+ 5. Definition of Syntaxes . . . . . . . . . . . . . . . . . . . . 26
+ 6. Definition of Matching Rules . . . . . . . . . . . . . . . . . 26
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
+ 7.1. Registration of Object Classes . . . . . . . . . . . . . 26
+ 7.2. Registration of Attribute Types. . . . . . . . . . . . . 27
+ 8. Internationalization Considerations. . . . . . . . . . . . . . 28
+ 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 29
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 30
+ 11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 32
+ 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
+ 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 2]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+1. Introduction
+
+ This document defines several object classes to provide Lightweight
+ Directory Access Protocol v3 [LDAP-TS] applications with flexible
+ options in defining printer information using LDAP schema. Classes
+ are provided for defining directory entries with common printer
+ information as well as for extending existing directory entries with
+ SLPv2 [RFC2608], IPP/1.1 [RFC2911], and LPR [RFC1179] specific
+ information.
+
+ The schema defined in this document is based on the printer
+ attributes listed in Appendix E 'Generic Directory Schema' of
+ Internet Printing Protocol/1.1 (IPP) [RFC2911]. A few additional
+ printer attributes are based on definitions in the Printer MIB
+ [RFC1759].
+
+ The schema defined in this document is technically aligned with the
+ stable IANA-registered 'service:printer:' v2.0 template [SLP-PRT],
+ for compatibility with already deployed Service Location Protocol
+ (SLPv2) [RFC2608] service advertising and discovery infrastructure.
+ The attribute syntaxes are technically aligned with the
+ 'service:printer:' v2.0 template - therefore simpler types are
+ sometimes used (for example, 'DirectoryString' [RFC2252] rather than
+ 'labeledURI' [RFC2079] for the 'printer-uri' attribute).
+
+ Please send comments directly to the authors at the addresses listed
+ in Section 13 "Authors' Addresses".
+
+1.1. Rationale for using DirectoryString Syntax
+
+ The attribute syntax 'DirectoryString' (UTF-8 [RFC2279]) defined in
+ [RFC2252] is specified for several groups of string attributes that
+ are defined in this document:
+
+ 1) URI
+ - printer-uri, printer-xri-supported, printer-more-info
+
+ The UTF-8 encoding is forward compatible with any future
+ deployment of (UTF-8 based) IRI (Internationalized Resource
+ Identifiers) [W3C-IRI] currently being developed by the W3C
+ Internationalization Working Group.
+
+ 2) Description
+ - printer-name, printer-location, printer-info,
+ printer-make-and-model
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 3]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ The UTF-8 encoding supports descriptions in any language,
+ conformant with the "IETF Policy on Character Sets and Languages"
+ [RFC2277].
+
+ Note: The printer-natural-language-configured attribute contains
+ a language tag [RFC3066] for these description attributes (for
+ example, to support text-to-speech conversions).
+
+ 3) Keyword
+ - printer-compression-supported, printer-finishings-supported,
+ printer-media-supported, printer-media-local-supported,
+ printer-print-quality-supported
+
+ The UTF-8 encoding is compatible with the current IPP/1.1
+ [RFC2911] definition of the equivalent attributes, most of which
+ have the IPP/1.1 union syntax 'keyword or name'. The keyword
+ attributes defined in this document are extensible by
+ site-specific or vendor-specific 'names' which behave like new
+ 'keywords'
+
+ Note: In IPP/1.1, each value is strongly typed over-the-wire as
+ either 'keyword' or 'name'. This union selector is not preserved
+ in the definitions of these equivalent LDAP attributes.
+
+1.2. Rationale for using caseIgnoreMatch
+
+ The EQUALITY matching rule 'caseIgnoreMatch' defined in [RFC2252] is
+ specified for several groups of string attributes that are defined in
+ this document:
+
+ 1) URI
+
+ These URI attributes specify EQUALITY matching with
+ 'caseIgnoreMatch' (rather than with 'caseExactMatch') in order to
+ conform to the spirit of [RFC2396], which requires case
+ insensitive matching on the host part of a URI versus case
+ sensitive matching on the remainder of a URI.
+
+ These URI attributes follow existing practice of supporting case
+ insensitive equality matching for host names in the
+ associatedDomain attribute defined in [RFC1274].
+
+ Either equality matching rule choice would be a compromise:
+ a) case sensitive whole URI matching may lead to false negative
+ matches and has been shown to be fragile (given deployed client
+ applications that 'pretty up' host names displayed and
+ transferred in URI);
+
+
+
+
+Fleming & McDonald Informational [Page 4]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ b) case insensitive whole URI matching may lead to false positive
+ matches, although it is a dangerous practice to publish URI that
+ differ only by case (for example, in the path elements).
+
+ 2) Description
+
+ Case insensitive equality matching is more user-friendly for
+ description attributes.
+
+ 3) Keyword
+
+ Case insensitive equality matching is more user-friendly for
+ keyword attributes.
+
+1.3. Rationale for using caseIgnoreSubstringsMatch
+
+ The SUBSTR matching rule 'caseIgnoreSubstringsMatch' defined in
+ [RFC2252] is specified for several groups of string attributes that
+ are defined in this document:
+
+ 1) URI
+
+ These URI attributes follow existing practice of supporting case
+ insensitive equality matching for host names in the
+ associatedDomain attribute defined in [RFC1274].
+
+ 2) Description
+
+ Support for case insensitive substring matching is more
+ user-friendly for description attributes.
+
+ 3) Keyword
+
+ Support for case insensitive substring matching is more
+ user-friendly for keyword attributes.
+
+2. Terminology and Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Schema definitions are provided using LDAPv3 [LDAP-TS] description
+ formats. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 5]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+3. Definition of Object Classes
+
+ We define the following LDAP object classes for use with both generic
+ printer related information and services specific to SLPv2 [RFC2608],
+ IPP/1.1 [RFC2911], and LPR [RFC1179].
+
+ slpServicePrinter - auxiliary class for SLP registered printers
+ printerAbstract - abstract class for all printer classes
+ printerService - structural class for printers
+ printerServiceAuxClass - auxiliary class for printers
+ printerIPP - auxiliary class for IPP printers
+ printerLPR - auxiliary class for LPR printers
+
+ The following are some examples of how applications may choose to use
+ these classes when creating directory entries:
+
+ 1) Use printerService for directory entries containing common
+ printer information.
+
+ 2) Use both printerService and slpServicePrinter for directory
+ entries containing common printer information for SLP registered
+ printers.
+
+ 3) Use printerService, printerLPR and printerIPP for directory
+ entries containing common printer information for printers that
+ support both LPR and IPP.
+
+ 4) Use printerServiceAuxClass and object classes not defined by this
+ document for directory entries containing common printer
+ information. In this example, printerServiceAuxClass is used for
+ extending other structural classes defining printer information
+ with common printer information defined in this document.
+
+ Refer to Section 4 for definition of attribute types referenced by
+ these object classes. We use attribute names instead of OIDs in
+ object class definitions for clarity. Some attribute names described
+ in [RFC2911] have been prefixed with 'printer-' as recommended in
+ [RFC2926] and [SLP-PRT].
+
+3.1. slpServicePrinter
+
+ ( 1.3.18.0.2.6.254
+ NAME 'slpServicePrinter'
+ DESC 'Service Location Protocol (SLP) information.'
+ AUXILIARY
+ SUP slpService
+ )
+
+
+
+
+Fleming & McDonald Informational [Page 6]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ This auxiliary class defines Service Location Protocol (SLPv2)
+ [RFC2608] specific information. It should be used with a structural
+ class such as printerService. It may be used to create new or extend
+ existing directory entries with SLP 'service:printer' abstract
+ service type information as defined in [SLP-PRT]. This object class
+ is derived from 'slpService', the parent class for all SLP services,
+ defined in [RFC2926].
+
+3.2. printerAbstract
+
+ ( 1.3.18.0.2.6.258
+ NAME 'printerAbstract'
+ DESC 'Printer related information.'
+ ABSTRACT
+ SUP top
+ MAY ( printer-name $
+ printer-natural-language-configured $
+ printer-location $ printer-info $ printer-more-info $
+ printer-make-and-model $
+ printer-multiple-document-jobs-supported $
+ printer-charset-configured $ printer-charset-supported $
+ printer-generated-natural-language-supported $
+ printer-document-format-supported $ printer-color-supported $
+ printer-compression-supported $ printer-pages-per-minute $
+ printer-pages-per-minute-color $
+ printer-finishings-supported $ printer-number-up-supported $
+ printer-sides-supported $ printer-media-supported $
+ printer-media-local-supported $
+ printer-resolution-supported $
+ printer-print-quality-supported $
+ printer-job-priority-supported $ printer-copies-supported $
+ printer-job-k-octets-supported $ printer-current-operator $
+ printer-service-person $
+ printer-delivery-orientation-supported $
+ printer-stacking-order-supported $
+ printer-output-features-supported )
+ )
+
+ This abstract class defines printer information. It is a base class
+ for deriving other printer related classes, such as, but not limited
+ to, classes defined in this document. It defines a common set of
+ printer attributes that are not specific to any one type of service,
+ protocol or operating system.
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 7]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+3.3. printerService
+
+ ( 1.3.18.0.2.6.255
+ NAME 'printerService'
+ DESC 'Printer information.'
+ STRUCTURAL
+ SUP printerAbstract
+ MAY ( printer-uri $ printer-xri-supported )
+ )
+
+ This structural class defines printer information. It is derived
+ from class printerAbstract and thus inherits common printer
+ attributes. This class can be used with or without auxiliary classes
+ to define printer information. Auxiliary classes can be used to
+ extend the common printer information with protocol, service or
+ operating system specific information.
+
+ Note: When extending other structural classes with auxiliary
+ classes, printerService should not be used.
+
+3.4. printerServiceAuxClass
+
+ ( 1.3.18.0.2.6.257
+ NAME 'printerServiceAuxClass'
+ DESC 'Printer information.'
+ AUXILIARY
+ SUP printerAbstract
+ MAY ( printer-uri $ printer-xri-supported )
+ )
+
+ This auxiliary class defines printer information. It is derived from
+ class printerAbstract and thus inherits common printer attributes.
+ This class should be used with a structural class.
+
+3.5. printerIPP
+
+ ( 1.3.18.0.2.6.256
+ NAME 'printerIPP'
+ DESC 'Internet Printing Protocol (IPP) information.'
+ AUXILIARY
+ SUP top
+ MAY ( printer-ipp-versions-supported $
+ printer-multiple-document-jobs-supported )
+ )
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 8]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ This auxiliary class defines Internet Printing Protocol (IPP/1.1)
+ [RFC2911] information. It should be used with a structural class
+ such as printerService. It is used to extend structural classes with
+ IPP specific printer information.
+
+3.6. printerLPR
+
+ ( 1.3.18.0.2.6.253
+ NAME 'printerLPR'
+ DESC 'LPR information.'
+ AUXILIARY
+ SUP top
+ MUST ( printer-name )
+ MAY ( printer-aliases)
+ )
+
+ This auxiliary class defines LPR [RFC1179] information. It should be
+ used with a structural class such as printerService. It is used to
+ identify directory entries that support LPR.
+
+4. Definition of Attribute Types
+
+ The following attribute types are referenced by the object classes
+ defined in Section 3.
+
+ The following attribute types reference syntax OIDs defined in
+ Section 6 of [RFC2252] (see Section 5 'Definition of Syntaxes'
+ below).
+
+ The following attribute types reference matching rule names (instead
+ of OIDs) for clarity (see Section 6 below). For optional attributes,
+ if the printer information is not known, the attribute value should
+ not be set. In the following definitions, referenced matching rules
+ are defined in Section 8 of [RFC2252] and/or Section 2 of [RFC3698]
+ (see Section 6 'Definition of Matching Rules' below).
+
+ The following table is a summary of the attribute names defined by
+ this document and their corresponding names from [RFC2911]. Some
+ attribute names described in [RFC2911] have been prefixed with
+ 'printer-' as recommended in [RFC2926], to address the flat namespace
+ for LDAP identifiers.
+
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 9]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ LDAP & SLP Printer Schema IPP Model [RFC2911]
+ ------------------------------ -------------------------------------
+ printer-uri
+ printer-xri-supported
+ [IPP printer-uri-supported]
+ [IPP uri-authentication-supported]
+ [IPP uri-security-supported]
+ printer-name printer-name
+ printer-natural-language-configured
+ natural-language-configured
+ printer-location printer-location
+ printer-info printer-info
+ printer-more-info printer-more-info
+ printer-make-and-model printer-make-and-model
+ printer-ipp-versions-supported ipp-versions-supported
+ printer-multiple-document-jobs-supported
+ multiple-document-jobs-supported
+ printer-charset-configured charset-configured
+ printer-charset-supported charset-supported
+ printer-generated-natural-language-supported
+ generated-natural-language-supported
+ printer-document-format-supported
+ document-format-supported
+ printer-color-supported color-supported
+ printer-compression-supported compression-supported
+ printer-pages-per-minute pages-per-minute
+ printer-pages-per-minute-color pages-per-minute-color
+ printer-finishings-supported finishings-supported
+ printer-number-up-supported number-up-supported
+ printer-sides-supported sides-supported
+ printer-media-supported media-supported
+ printer-media-local-supported [site names from IPP media-supported]
+ printer-resolution-supported printer-resolution-supported
+ printer-print-quality-supported print-quality-supported
+ printer-job-priority-supported job-priority-supported
+ printer-copies-supported copies-supported
+ printer-job-k-octets-supported job-k-octets-supported
+ printer-current-operator
+ printer-service-person
+ printer-delivery-orientation-supported
+ printer-stacking-order-supported
+ printer-output-features-supported
+ printer-aliases
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 10]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.1. printer-uri
+
+ ( 1.3.18.0.2.4.1140
+ NAME 'printer-uri'
+ DESC 'A URI supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ If the printer-xri-supported LDAP attribute is implemented, then this
+ printer-uri value should be listed in printer-xri-supported.
+
+ Values of URI should conform to [RFC2396], although URI schemes may
+ be defined which do not conform to [RFC2396] (see [RFC2717] and
+ [RFC2718]).
+
+ Note: LDAP application clients should not attempt to use malformed
+ URI values read from this attribute. LDAP administrative clients
+ should not write malformed URI values into this attribute.
+
+ Note: For SLP registered printers, the LDAP printer-uri attribute
+ should be set to the value of the SLP-registered URL of the printer,
+ for interworking with SLPv2 [RFC2608] service discovery.
+
+ Note: See Sections 1.1, 1.2, and 1.3 for rationale for design
+ choices.
+
+4.2. printer-xri-supported
+
+ ( 1.3.18.0.2.4.1107
+ NAME 'printer-xri-supported'
+ DESC 'The unordered list of XRI (extended resource identifiers)
+ supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ A list of XRI (extended resource identifiers) supported by this
+ printer. Each value of this list should consist of a URI (uniform
+ resource identifier) followed by (optional) authentication and
+ security fields.
+
+ Values of URI should conform to [RFC2396], although URI schemes may
+ be defined which do not conform to [RFC2396] (see [RFC2717] and
+ [RFC2718]).
+
+
+
+Fleming & McDonald Informational [Page 11]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Note: LDAP application clients should not attempt to use malformed
+ URI values read from this attribute. LDAP administrative clients
+ should not write malformed URI values into this attribute.
+
+ Note: This attribute is based on 'printer-uri-supported', 'uri-
+ authentication-supported', and `'uri-security-supported' (called the
+ 'Three Musketeers' because they are parallel ordered attributes)
+ defined in IPP/1.1 [RFC2911]. This attribute unfolds those IPP/1.1
+ attributes and thus avoids the ordering (and same number of values)
+ constraints of the IPP/1.1 separate attributes.
+
+ Defined keywords for fields include:
+
+ 'uri' (IPP 'printer-uri-supported')
+ 'auth' (IPP 'uri-authentication-supported')
+ 'sec' (IPP 'uri-security-supported')
+
+ A missing 'auth' field should be interpreted to mean 'none'. Per
+ IPP/1.1 [RFC2911], defined values of the 'auth' field include:
+
+ 'none' (no authentication for this URI)
+ 'requesting-user-name' (from operation request)
+ 'basic' (HTTP/1.1 Basic [RFC2617])
+ 'digest' (HTTP/1.1 Basic, [RFC2617])
+ 'certificate' (from certificate)
+
+ A missing 'sec' field should be interpreted to mean 'none'. Per
+ IPP/1.1 [RFC2911], defined values of the 'sec' field include:
+
+ 'none' (no security for this URI)
+ 'ssl3' (Netscape SSL3)
+ 'tls' (IETF TLS/1.0, [RFC2246])
+
+ Each XRI field should be delimited by '<'. For example:
+
+ 'uri=ipp://foo.com< auth=digest< sec=tls<'
+ 'uri=lpr://bar.com< auth=none< sec=none<'
+ 'uri=mailto:printer@foobar.com< auth=none< sec=none<'
+
+ Note: The syntax and delimiter for this attribute are aligned with
+ the equivalent attribute in the 'service:printer:' v2.0 template
+ [SLP-PRT]. Whitespace is permitted after (but not before) the
+ delimiter '<'. Note that this delimiter differs from printer-
+ resolution-supported.
+
+ Note: See Sections 1.1, 1.2, and 1.3 for rationale for design
+ choices.
+
+
+
+
+Fleming & McDonald Informational [Page 12]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.3. printer-name
+
+ ( 1.3.18.0.2.4.1135
+ NAME 'printer-name'
+ DESC 'The site-specific administrative name of this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ Values of this attribute should be specified in the language
+ specified in printer-natural-language-configured (for example, to
+ support text-to-speech conversions), although the printer's name may
+ be specified in any language. This name may be the last part of the
+ printer's URI or it may be completely unrelated. This name may
+ contain characters that are not allowed in a conventional URI (see
+ [RFC2396]).
+
+4.4. printer-natural-language-configured
+
+ ( 1.3.18.0.2.4.1119
+ NAME 'printer-natural-language-configured'
+ DESC 'The configured natural language in which error and status
+ messages will be generated (by default) by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ Also, a possible natural language for printer string attributes set
+ by operator, system administrator, or manufacturer. Also, the
+ (declared) natural language of the printer-name, printer-location,
+ printer-info, and printer-make-and-model attributes of this printer.
+
+ Values of language tags should conform to "Tags for the
+ Identification of Languages" [RFC3066]. For example:
+
+ 'en-us' (English as spoken in the US)
+ 'fr-fr' (French as spoken in France)
+
+ For consistency with IPP/1.1 [RFC2911], language tags in this
+ attribute should be lowercase normalized.
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 13]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.5. printer-location
+
+ ( 1.3.18.0.2.4.1136
+ NAME 'printer-location'
+ DESC 'The physical location of this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ For example:
+
+ 'Room 123A'
+ 'Second floor of building XYZ'
+
+4.6. printer-info
+
+ ( 1.3.18.0.2.4.1139
+ NAME 'printer-info'
+ DESC 'Descriptive information about this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ For example:
+
+ 'This printer can be used for printing color transparencies for
+ HR presentations'
+ 'Out of courtesy for others, please print only small (1-5 page)
+ jobs at this printer'
+ 'This printer is going away on July 1, 1997, please find a new
+ printer'
+
+4.7. printer-more-info
+
+ ( 1.3.18.0.2.4.1134
+ NAME 'printer-more-info'
+ DESC 'A URI for more information about this specific printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+Fleming & McDonald Informational [Page 14]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ For example, this could be an HTTP type URI referencing an HTML page
+ accessible to a Web Browser. The information obtained from this URI
+ is intended for end user consumption.
+
+ Values of URI should conform to [RFC2396], although URI schemes may
+ be defined which do not conform to [RFC2396] (see [RFC2717] and
+ [RFC2718]).
+
+ Note: LDAP application clients should not attempt to use malformed
+ URI values read from this attribute. LDAP administrative clients
+ should not write malformed URI values into this attribute.
+
+ Note: See Sections 1.1, 1.2, and 1.3 for rationale for design
+ choices.
+
+4.8. printer-make-and-model
+
+ ( 1.3.18.0.2.4.1138
+ NAME 'printer-make-and-model'
+ DESC 'Make and model of this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ Note: The printer manufacturer may initially populate this
+ attribute.
+
+4.9. printer-ipp-versions-supported
+
+ ( 1.3.18.0.2.4.1133
+ NAME 'printer-ipp-versions-supported'
+ DESC 'IPP protocol version(s) that this printer supports.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ The IPP protocol version(s) should include major and minor versions,
+ i.e., the exact version numbers for which this Printer implementation
+ meets the IPP version-specific conformance requirements.
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 15]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.10. printer-multiple-document-jobs-supported
+
+ ( 1.3.18.0.2.4.1132
+ NAME 'printer-multiple-document-jobs-supported'
+ DESC 'Indicates whether or not this printer supports more than one
+ document per job.'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+4.11. printer-charset-configured
+
+ ( 1.3.18.0.2.4.1109
+ NAME 'printer-charset-configured'
+ DESC 'The configured charset in which error and status messages will
+ be generated (by default) by this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{63}
+ SINGLE-VALUE
+ )
+
+ Also, a possible charset for printer string attributes set by
+ operator, system administrator, or manufacturer. For example:
+
+ 'utf-8' (ISO 10646/Unicode in UTF-8 transform [RFC2279])
+ 'iso-8859-1' (Latin1)
+
+ Values of charset tags should be defined in the IANA Registry of
+ Coded Character Sets [IANA-CHAR] (see also [RFC2978]) and the
+ '(preferred MIME name)' should be used as the charset tag in this
+ attribute.
+
+ For consistency with IPP/1.1 [RFC2911], charset tags in this
+ attribute should be lowercase normalized.
+
+4.12. printer-charset-supported
+
+ ( 1.3.18.0.2.4.1131
+ NAME 'printer-charset-supported'
+ DESC 'Set of charsets supported for the attribute values of syntax
+ DirectoryString for this directory entry.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{63}
+ )
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 16]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ For example:
+
+ 'utf-8' (ISO 10646/Unicode in UTF-8 transform [RFC2279])
+ 'iso-8859-1' (Latin1)
+
+ Values of charset tags should be defined in the IANA Registry of
+ Coded Character Sets [IANA-CHAR] (see also [RFC2978]) and the
+ '(preferred MIME name)' should be used as the charset tag in this
+ attribute.
+
+ For consistency with IPP/1.1 [RFC2911], charset tags in this
+ attribute should be lowercase normalized.
+
+4.13. printer-generated-natural-language-supported
+
+ ( 1.3.18.0.2.4.1137
+ NAME 'printer-generated-natural-language-supported'
+ DESC 'Natural language(s) supported for this directory entry.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{63}
+ )
+
+ Values of language tags should conform to "Tags for the
+ Identification of Languages" [RFC3066]. For example:
+
+ 'en-us' (English as spoken in the US)
+ 'fr-fr' (French as spoken in France)
+
+ For consistency with IPP/1.1 [RFC2911], language tags in this
+ attribute should be lowercase normalized.
+
+4.14. printer-document-format-supported
+
+ ( 1.3.18.0.2.4.1130
+ NAME 'printer-document-format-supported'
+ DESC 'The possible source document formats which may be interpreted
+ and printed by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values of document formats should be MIME media types defined in the
+ IANA Registry of MIME Media Types [IANA-MIME] (see also [RFC2048]).
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 17]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.15. printer-color-supported
+
+ ( 1.3.18.0.2.4.1129
+ NAME 'printer-color-supported'
+ DESC 'Indicates whether this printer is capable of any type of color
+ printing at all, including highlight color.'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+4.16. printer-compression-supported
+
+ ( 1.3.18.0.2.4.1128
+ NAME 'printer-compression-supported'
+ DESC 'Compression algorithms supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
+ )
+
+ Values defined in IPP/1.1 [RFC2911] include:
+
+ 'none' (no compression is used)
+ 'deflate' (public domain ZIP described in [RFC1951])
+ 'gzip' (GNU ZIP described in [RFC1952])
+ 'compress' (UNIX compression described in [RFC1977])
+
+4.17. printer-pages-per-minute
+
+ ( 1.3.18.0.2.4.1127
+ NAME 'printer-pages-per-minute'
+ DESC 'The nominal number of pages per minute which may be output by
+ this printer.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ This attribute is informative, not a service guarantee. Typically,
+ it is the value used in marketing literature to describe this
+ printer. For example, the value for a simplex or black-and-white
+ print mode.
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 18]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.18. printer-pages-per-minute-color
+
+ ( 1.3.18.0.2.4.1126
+ NAME 'printer-pages-per-minute-color'
+ DESC 'The nominal number of color pages per minute which may be
+ output by this printer.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ This attribute is informative, not a service guarantee. Typically,
+ it is the value used in marketing literature to describe this
+ printer.
+
+
+4.19. printer-finishings-supported
+
+ ( 1.3.18.0.2.4.1125
+ NAME 'printer-finishings-supported'
+ DESC 'The possible finishing operations supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
+ )
+
+ Values defined in IPP/1.1 [RFC2911] include: 'none', 'staple',
+ 'punch', 'cover', 'bind', 'saddle-stitch', 'edge-stitch',
+ 'staple-top-left', 'staple-bottom-left', 'staple-top-right',
+ 'staple-bottom-right', 'edge-stitch-left', 'edge-stitch-top',
+ 'edge-stitch-right', 'edge-stitch-bottom', 'staple-dual-left',
+ 'staple-dual-top', 'staple-dual-right', 'staple-dual-bottom'.
+
+ Note: Implementations may support other values.
+
+4.20. printer-number-up-supported
+
+ ( 1.3.18.0.2.4.1124
+ NAME 'printer-number-up-supported'
+ DESC 'The possible numbers of print-stream pages to impose upon a
+ single side of an instance of a selected medium.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ )
+
+
+
+
+
+Fleming & McDonald Informational [Page 19]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Values defined in IPP/1.1 [RFC2911] include: '1', '2', and '4'.
+
+ Note: Implementations may support other values.
+
+4.21. printer-sides-supported
+
+ ( 1.3.18.0.2.4.1123
+ NAME 'printer-sides-supported'
+ DESC 'The number of impression sides (one or two) and the two-sided
+ impression rotations supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values defined in IPP/1.1 [RFC2911] include: 'one-sided', 'two-
+ sided-long-edge', 'two-sided-short-edge'.'
+
+4.22. printer-media-supported
+
+ ( 1.3.18.0.2.4.1122
+ NAME 'printer-media-supported'
+ DESC 'The standard names/types/sizes (and optional color suffixes) of
+ the media supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
+ )
+
+ Values are defined in IPP/1.1 [RFC2911] or any IANA registered
+ extensions. For example:
+
+ 'iso-a4'
+ 'envelope'
+ 'na-letter-white'
+
+4.23. printer-media-local-supported
+
+ ( 1.3.18.0.2.4.1117
+ NAME 'printer-media-local-supported'
+ DESC 'Site-specific names of media supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
+ )
+
+ Values should be in the natural language specified by printer-
+ natural-language-configured.
+
+
+
+
+Fleming & McDonald Informational [Page 20]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ For example:
+
+ 'purchasing-form' (site-specific name)
+
+ as opposed to 'na-letter' (standard keyword from IPP/1.1 [RFC2911])
+ in the printer-media-supported attribute.
+
+4.24. printer-resolution-supported
+
+ ( 1.3.18.0.2.4.1121
+ NAME 'printer-resolution-supported'
+ DESC 'List of resolutions supported for printing documents by this
+ printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
+ )
+
+ Each resolution value should be a string containing 3 fields:
+ 1) Cross feed direction resolution (positive integer);
+ 2) Feed direction resolution (positive integer);
+ 3) Unit - 'dpi' (dots per inch) or 'dpcm' (dots per centimeter).
+
+ Each resolution field should be delimited by '>'. For example:
+
+ '300> 300> dpi>'
+ '600> 600> dpi>'
+
+ Note: This attribute is based on 'printer-resolution-supported'
+ defined in IPP/1.1 [RFC2911] (which has a binary complex encoding)
+ derived from 'prtMarkerAddressabilityFeedDir',
+ 'prtMarkerAddressabilityXFeedDir', and 'prtMarkerAddressabilityUnit'
+ defined in the Printer MIB [RFC1759] (which have integer encodings).
+
+ Note: The syntax and delimiter for this attribute are aligned with
+ the equivalent attribute in the 'service:printer:' v2.0 template
+ [SLP-PRT]. Whitespace is permitted after (but not before) the
+ delimiter '>'. Note that this delimiter differs from printer-xri-
+ supported.
+
+
+
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 21]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.25. printer-print-quality-supported
+
+ ( 1.3.18.0.2.4.1120
+ NAME 'printer-print-quality-supported'
+ DESC 'List of print qualities supported for printing documents on
+ this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values defined in IPP/1.1 [RFC2911] include:
+
+ 'unknown'
+ 'draft'
+ 'normal'
+ 'high'
+
+4.26. printer-job-priority-supported
+
+ ( 1.3.18.0.2.4.1110
+ NAME 'printer-job-priority-supported'
+ DESC 'Indicates the number of job priority levels supported by this
+ printer.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ An IPP/1.1 [RFC2911] conformant Printer, which supports job priority,
+ always supports a full range of priorities from '1' to '100' (to
+ ensure consistent behavior), therefore this attribute describes the
+ 'granularity' of priority supported. Values of this attribute are
+ from '1' to '100'.
+
+4.27. printer-copies-supported
+
+ ( 1.3.18.0.2.4.1118
+ NAME 'printer-copies-supported'
+ DESC 'The maximum number of copies of a document that may be printed
+ as a single job on this printer.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+
+
+
+
+Fleming & McDonald Informational [Page 22]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ A positive value indicates the maximum supported copies. A value of
+ '0' indicates no maximum limit. A value of '-1' indicates 'unknown'.
+
+ Note: The syntax and values for this attribute are aligned with the
+ equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+ PRT].
+
+4.28. printer-job-k-octets-supported
+
+ ( 1.3.18.0.2.4.1111
+ NAME 'printer-job-k-octets-supported'
+ DESC 'The maximum size in kilobytes (1,024 octets actually) incoming
+ print job that this printer will accept.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ A positive value indicates the maximum supported job size. A value
+ of '0' indicates no maximum limit. A value of '-1' indicates
+ 'unknown'.
+
+ Note: The syntax and values for this attribute are aligned with the
+ equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+ PRT].
+
+4.29. printer-current-operator
+
+ ( 1.3.18.0.2.4.1112
+ NAME 'printer-current-operator'
+ DESC 'The identity of the current human operator responsible for
+ operating this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ The value of this attribute should include information that would
+ enable other humans to reach the operator, such as a telephone
+ number.
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 23]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.30. printer-service-person
+
+ ( 1.3.18.0.2.4.1113
+ NAME 'printer-service-person'
+ DESC 'The identity of the current human service person responsible
+ for servicing this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ The value of this attribute should include information that would
+ enable other humans to reach the service person, such as a telephone
+ number.
+
+4.31. printer-delivery-orientation-supported
+
+ ( 1.3.18.0.2.4.1114
+ NAME 'printer-delivery-orientation-supported'
+ DESC 'The possible delivery orientations of pages as they are printed
+ and ejected from this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values defined include:
+
+ 'unknown'
+ 'face-up'
+ 'face-down'
+
+ Note: The syntax and values for this attribute are aligned with the
+ equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+ PRT].
+
+4.32. printer-stacking-order-supported
+
+ ( 1.3.18.0.2.4.1115
+ NAME 'printer-stacking-order-supported'
+ DESC 'The possible stacking order of pages as they are printed and
+ ejected from this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 24]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Values defined include:
+
+ 'unknown'
+ 'first-to-last'
+ 'last-to-first'
+
+ Note: The syntax and values for this attribute are aligned with the
+ equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+ PRT].
+
+4.33. printer-output-features-supported
+
+ ( 1.3.18.0.2.4.1116
+ NAME 'printer-output-features-supported'
+ DESC 'The possible output features supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values defined include:
+
+ 'unknown'
+ 'bursting'
+ 'decollating'
+ 'page-collating'
+ 'offset-stacking'
+
+ Note: The syntax and values for this attribute are aligned with the
+ equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+ PRT].
+
+ Note: Implementations may support other values.
+
+4.34. printer-aliases
+
+ ( 1.3.18.0.2.4.1108
+ NAME 'printer-aliases'
+ DESC 'List of site-specific administrative names of this printer in
+ addition to the value specified for printer-name.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values of this attribute should be specified in the language
+ specified in printer-natural-language-configured (for example, to
+ support text-to-speech conversions), although the printer's alias may
+ be specified in any language.
+
+
+
+Fleming & McDonald Informational [Page 25]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+5. Definition of Syntaxes
+
+ No new attribute syntaxes are defined by this document.
+
+ The attribute types defined in Section 4 of this document reference
+ syntax OIDs defined in Section 6 of [RFC2252], which are summarized
+ below:
+
+ Syntax OID Syntax Description
+ ------------------------------ ------------------
+ 1.3.6.1.4.1.1466.115.121.1.7 Boolean
+ 1.3.6.1.4.1.1466.115.121.1.15 DirectoryString (UTF-8 [RFC2279])
+ 1.3.6.1.4.1.1466.115.121.1.27 Integer
+
+6. Definition of Matching Rules
+
+ No new matching rules are defined by this document.
+
+ The attribute types defined in Section 4 of this document reference
+ matching rules defined in Section 8 of [RFC2252] and/or Section 2 of
+ [RFC3698], which are summarized below:
+
+ Matching Rule OID Matching Rule Name Usage
+ ------------------------------ ------------------ -----
+ 2.5.13.13 booleanMatch EQUALITY
+ 2.5.13.2 caseIgnoreMatch EQUALITY
+ 2.5.13.14 integerMatch EQUALITY
+ 2.5.13.15 integerOrderingMatch ORDERING
+ 2.5.13.4 caseIgnoreSubstringsMatch SUBSTR
+
+7. IANA Considerations
+
+ This document does not define any new syntaxes or matching rules.
+
+ This document does define the following Object Identifier
+ Descriptors. They have been registered by the IANA:
+
+7.1. Registration of Object Classes
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): see table below
+
+ Object Identifier: see table below
+
+ Person & email address to contact for further information: see below
+
+ Usage: object class
+
+
+
+Fleming & McDonald Informational [Page 26]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Specification: RFC3712
+
+ Author/Change Controller:
+
+ Pat Fleming
+ IBM
+ Highway 52 N
+ Rochester, MN 55901
+ USA
+ Phone: +1 507-253-7583
+ EMail: flemingp@us.ibm.com
+
+ Comments:
+
+ Object Class OID
+ ------------------------------------ ---------------------
+ slpServicePrinter 1.3.18.0.2.6.254
+ printerAbstract 1.3.18.0.2.6.258
+ printerService 1.3.18.0.2.6.255
+ printerServiceAuxClass 1.3.18.0.2.6.257
+ printerIPP 1.3.18.0.2.6.256
+ printerLPR 1.3.18.0.2.6.253
+
+7.2. Registration of Attribute Types
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): see table below
+
+ Object Identifier: see table below
+
+ Person & email address to contact for further information: see below
+
+ Usage: attribute type
+
+ Specification: RFC3712
+
+ Author/Change Controller:
+
+ Pat Fleming
+ IBM
+ Highway 52 N
+ Rochester, MN 55901
+ USA
+ Phone: +1 507-253-7583
+ EMail: flemingp@us.ibm.com
+
+
+
+
+
+Fleming & McDonald Informational [Page 27]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Comments:
+
+ Attribute Type OID
+ ------------------------------------ ---------------------
+ printer-uri 1.3.18.0.2.4.1140
+ printer-xri-supported 1.3.18.0.2.4.1107
+ printer-name 1.3.18.0.2.4.1135
+ printer-natural-language-configured 1.3.18.0.2.4.1119
+ printer-location 1.3.18.0.2.4.1136
+ printer-info 1.3.18.0.2.4.1139
+ printer-more-info 1.3.18.0.2.4.1134
+ printer-make-and-model 1.3.18.0.2.4.1138
+ printer-ipp-versions-supported 1.3.18.0.2.4.1133
+ printer-multiple-document-jobs-supported 1.3.18.0.2.4.1132
+ printer-charset-configured 1.3.18.0.2.4.1109
+ printer-charset-supported 1.3.18.0.2.4.1131
+ printer-generated-natural-language-supported 1.3.18.0.2.4.1137
+ printer-document-format-supported 1.3.18.0.2.4.1130
+ printer-color-supported 1.3.18.0.2.4.1129
+ printer-compression-supported 1.3.18.0.2.4.1128
+ printer-pages-per-minute 1.3.18.0.2.4.1127
+ printer-pages-per-minute-color 1.3.18.0.2.4.1126
+ printer-finishings-supported 1.3.18.0.2.4.1125
+ printer-number-up-supported 1.3.18.0.2.4.1124
+ printer-sides-supported 1.3.18.0.2.4.1123
+ printer-media-supported 1.3.18.0.2.4.1122
+ printer-media-local-supported 1.3.18.0.2.4.1117
+ printer-resolution-supported 1.3.18.0.2.4.1121
+ printer-print-quality-supported 1.3.18.0.2.4.1120
+ printer-job-priority-supported 1.3.18.0.2.4.1110
+ printer-copies-supported 1.3.18.0.2.4.1118
+ printer-job-k-octets-supported 1.3.18.0.2.4.1111
+ printer-current-operator 1.3.18.0.2.4.1112
+ printer-service-person 1.3.18.0.2.4.1113
+ printer-delivery-orientation-supported 1.3.18.0.2.4.1114
+ printer-stacking-order-supported 1.3.18.0.2.4.1115
+ printer-output-features-supported 1.3.18.0.2.4.1116
+ printer-aliases 1.3.18.0.2.4.1108
+
+8. Internationalization Considerations
+
+ All text string attributes defined in this document of syntax
+ [RFC2279], as required by [RFC2252].
+
+ A language tag [RFC3066] for all of the text string attributes
+ defined in this document is contained in the printer-natural-
+ language-configured attribute.
+
+
+
+
+Fleming & McDonald Informational [Page 28]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Therefore, all object classes defined in this document conform to the
+ "IETF Policy on Character Sets and Languages" [RFC2277].
+
+9. Security Considerations
+
+ See [RFC2829] for detailed guidance on authentication methods for
+ LDAP. See [RFC2830] for detailed guidance of using TLS/1.0 [RFC2246]
+ to supply connection confidentiality and data integrity for LDAP
+ sessions.
+
+ As with any LDAP schema, it is important to protect specific entries
+ and attributes with the appropriate access control. It is
+ particularly important that only administrators can modify entries
+ defined in this LDAP printer schema. Otherwise, an LDAP client might
+ be fooled into diverting print service requests from the original
+ printer (or spooler) to a malicious intruder's host system, thus
+ exposing the information in printed documents.
+
+ For additional security considerations of deploying printers in an
+ IPP environment, see Section 8 of [RFC2911].
+
+10. References
+
+10.1. Normative References
+
+ [IANA-CHAR] IANA Registry of Character Sets
+ http://www.iana.org/assignments/charset-reg/...
+
+ [IANA-MIME] IANA Registry of MIME Media Types
+ http://www.iana.org/assignments/media-types/...
+
+ [LDAP-TS] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991.
+
+ [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
+ Gyllenskog, "Printer MIB", RFC 1759, March 1995.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, T., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+
+
+
+Fleming & McDonald Informational [Page 29]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ [RFC2396] Berners-Lee. T., Fielding, R. and L. Masinter, "URI
+ Generic Syntax", RFC 2396, August 1998.
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
+
+ [RFC2911] Hastings, T., Ed.., Herrito, R., deBry, R., Isaacson, S.
+ and P. Powell, "Internet Printing Protocol/1.1: Model and
+ Semantics", RFC 2911, September 2000.
+
+ [RFC2926] Kempf, J., Moats, R. and P. St. Pierre, "Conversion of
+ LDAP Schemas to and from SLP Templates", RFC 2926,
+ September 2000.
+
+ [RFC3066] Alvestrand, H., "Tags for the Identification of
+ Languages", BCP 47, RFC 3066, January 2001.
+
+ [RFC3698] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Additional Matching Rules", RFC 3698, February
+ 2004.
+
+10.2. Informative References
+
+ [IANA-SLPT] IANA Registry of SLP Templates
+ http://www.iana.org/assignments/svrloc-templates/...
+
+ [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179,
+ August 1990.
+
+ [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
+ Specification Version 1.3", RFC 1951, May 1996.
+
+ [RFC1952] Deutsch, P., "GZIP File Format Specification Version
+ 4.3", RFC 1952, May 1996.
+
+ [RFC1977] Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
+ August 1996.
+
+ [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
+ Internet Mail Extensions (MIME) Part Four: Registration
+ Procedures", BCP 13, RFC 2048, November 1996.
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 30]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
+ Object Class to Hold Uniform Resource Identifiers
+ (URIs)", RFC 2079, January 1997.
+
+ [RFC2246] Dierks, T. and C. Allen, "TLS Protocol Version 1.0", RFC
+ 2246, January 1999.
+
+ [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", RFC 2277, January 1998.
+
+ [RFC2279] Yergeau, F., "UTF-8, a Transformation Format of ISO
+ 10646", RFC 2279, January 1998.
+
+ [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day,
+ "Service Location Protocol v2", RFC 2608, June 1999.
+
+ [RFC2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates
+ and Service: Schemes", RFC 2609, June 1999.
+
+ [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
+ S., Leach, P., Luotonen, A. and L. Stewart, "HTTP
+ Authentication: Basic and Digest Access Authentication",
+ RFC 2617, June 1999.
+
+ [RFC2717] Petke, R. and I. King, "Registration Procedures for URL
+ Scheme Names", RFC 2717, November 1999.
+
+ [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
+ "Guidelines for new URL Schemes", BCP 19, RFC 2718,
+ November 1999.
+
+ [RFC2978] Freed, N. and J.Postel, "IANA Charset Registration
+ Procedures", RFC2978, October 2000.
+
+ [SLP-PRT] St. Pierre, Isaacson, McDonald. Definition of the
+ Printer Abstract Service Type v2.0, <durable URL below>,
+ May 2000. Reviewed and approved by IETF SLP Designated
+ Expert, according to Section 5 'IANA Considerations' in
+ [RFC2609].
+
+ Archived in the IANA Registry of SLP Templates [IANA-
+ SLPT] at: http://www.iana.org/assignments/svrloc-
+ templates/printer.2.0.en
+
+ [W3C-IRI] Duerst, Suignard, "Internationalized Resource Identifiers
+ (IRI), Work in Progress.
+
+
+
+
+
+Fleming & McDonald Informational [Page 31]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+11. Acknowledgments
+
+ The editors wish to acknowledge the very significant contributions of
+ Ken Jones (Bytemobile) and Harry Lewis (IBM) during the development
+ of this document.
+
+ Thanks to Patrik Faltstrom (Cisco), Ryan Moats (Lemur Networks),
+ Robert Moore (IBM), Lee Rafalow (IBM), Kimberly Reger (IBM), Kurt
+ Zeilenga (OpenLDAP), and the members of the IETF IPP Working Group,
+ for review comments and help in preparing this document.
+
+12. Authors' Addresses
+
+ Please send comments to the authors at the addresses listed below.
+
+ Pat Fleming
+ IBM
+ Highway 52 N
+ Rochester, MN 55901
+ USA
+
+ Phone: +1 507-253-7583
+ EMail: flemingp@us.ibm.com
+
+
+ Ira McDonald
+ High North Inc
+ 221 Ridge Ave
+ Grand Marais, MI 49839
+ USA
+
+ Phone: +1 906-494-2434
+ Email: imcdonald@sharplabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 32]
+\f
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology
+ described in this document or the extent to which any license
+ under such rights might or might not be available; nor does it
+ represent that it has made any independent effort to identify any
+ such rights. Information on the procedures with respect to
+ rights in RFC documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention
+ any copyrights, patents or patent applications, or other
+ proprietary rights that may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 33]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group S. Legg
+Request for Comments: 3727 Adacel Technologies
+Category: Standards Track February 2004
+
+
+ ASN.1 Module Definition for the
+ LDAP and X.500 Component Matching Rules
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document updates the specification of the component matching
+ rules for Lightweight Directory Access Protocol (LDAP) and X.500
+ directories (RFC3687) by collecting the Abstract Syntax Notation One
+ (ASN.1) definitions of the component matching rules into an
+ appropriately identified ASN.1 module so that other specifications
+ may reference the component matching rule definitions from within
+ their own ASN.1 modules.
+
+1. Introduction
+
+ The structure or data type of data held in an attribute of a
+ Lightweight Directory Access Protocol (LDAP) [LDAP] or X.500 [X500]
+ directory is described by the attribute's syntax. Attribute syntaxes
+ range from simple data types, such as text string, integer, or
+ boolean, to complex data types, for example, the syntaxes of the
+ directory schema operational attributes. RFC 3687 [CMR] defines a
+ generic way of matching user selected components in a directory
+ attribute value of any arbitrarily complex attribute syntax.
+
+ This document updates RFC 3687 by collecting the Abstract Syntax
+ Notation One (ASN.1) [ASN1] definitions of RFC 3687 into an
+ appropriately identified ASN.1 module so that other specifications
+ may reference these definitions from within their own ASN.1 modules.
+
+
+
+
+
+
+Legg Standards Track [Page 1]
+\f
+RFC 3727 Module for Component Matching February 2004
+
+
+2. Module Definition for Component Matching
+
+ ComponentMatching
+ {iso(1) 2 36 79672281 xed(3) module(0) component-matching(4)}
+
+ -- Copyright (C) The Internet Society (2004). This version of
+ -- this ASN.1 module is part of RFC 3727; see the RFC itself
+ -- for full legal notices.
+
+ DEFINITIONS
+ EXPLICIT TAGS
+ EXTENSIBILITY IMPLIED ::= BEGIN
+
+ IMPORTS
+ MATCHING-RULE,
+ RelativeDistinguishedName
+ FROM InformationFramework
+ {joint-iso-itu-t ds(5) module(1)
+ informationFramework(1) 4} ;
+
+ ComponentAssertion ::= SEQUENCE {
+ component ComponentReference (SIZE(1..MAX)) OPTIONAL,
+ useDefaultValues BOOLEAN DEFAULT TRUE,
+ rule MATCHING-RULE.&id,
+ value MATCHING-RULE.&AssertionType }
+
+ ComponentReference ::= UTF8String
+
+ ComponentFilter ::= CHOICE {
+ item [0] ComponentAssertion,
+ and [1] SEQUENCE OF ComponentFilter,
+ or [2] SEQUENCE OF ComponentFilter,
+ not [3] ComponentFilter }
+
+ componentFilterMatch MATCHING-RULE ::= {
+ SYNTAX ComponentFilter
+ ID { 1 2 36 79672281 1 13 2 } }
+
+ allComponentsMatch MATCHING-RULE ::= {
+ ID { 1 2 36 79672281 1 13 6 } }
+
+ directoryComponentsMatch MATCHING-RULE ::= {
+ ID { 1 2 36 79672281 1 13 7 } }
+
+
+ -- Additional Useful Matching Rules --
+
+ rdnMatch MATCHING-RULE ::= {
+
+
+
+Legg Standards Track [Page 2]
+\f
+RFC 3727 Module for Component Matching February 2004
+
+
+ SYNTAX RelativeDistinguishedName
+ ID { 1 2 36 79672281 1 13 3 } }
+
+ presentMatch MATCHING-RULE ::= {
+ SYNTAX NULL
+ ID { 1 2 36 79672281 1 13 5 } }
+
+ END
+
+ The InformationFramework ASN.1 module from which the MATCHING-RULE
+ and RelativeDistinguishedName definitions are imported is defined in
+ X.501 [X501].
+
+ The object identifiers used in this document have been assigned for
+ use in specifying the component matching rules by Adacel
+ Technologies, under an arc assigned to Adacel by Standards Australia.
+
+3. Security Considerations
+
+ This document collects together the ASN.1 definitions of the
+ component matching rules into an ASN.1 module, but does not modify
+ those definitions in any way. See RFC 3687 [CMR] for the security
+ considerations of using the component matching rules.
+
+4. References
+
+4.1. Normative References
+
+ [CMR] Legg, S., "Lightweight Directory Access Protocol (LDAP) and
+ X.500 Component Matching Rules", RFC 3687, February 2004.
+
+ [X501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Models
+
+ [ASN1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation
+
+4.2. Informative References
+
+ [LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377, September
+ 2002.
+
+ [X500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Overview of concepts, models and services
+
+
+
+Legg Standards Track [Page 3]
+\f
+RFC 3727 Module for Component Matching February 2004
+
+
+5. Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: steven.legg@adacel.com.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 4]
+\f
+RFC 3727 Module for Component Matching February 2004
+
+
+6. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology
+ described in this document or the extent to which any license
+ under such rights might or might not be available; nor does it
+ represent that it has made any independent effort to identify any
+ such rights. Information on the procedures with respect to
+ rights in RFC documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention
+ any copyrights, patents or patent applications, or other
+ proprietary rights that may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 5]
+\f
projects / thirdparty / openldap.git / commitdiff
