draft-ietf-ldapbis-user-schema-08.txt   draft-ietf-ldapbis-user-schema-09.txt 
INTERNET-DRAFT K. Dally, Editor INTERNET-DRAFT Editor: A. Sciberras
Intended Category: Standard Track The MITRE Corp. Intended Category: Standard Track eB2Bcom
Expires: January 2005 July 2004 Updates: RFC 2247, RFC 2798, RFC 2377 April 4, 2005
Updates: RFC 2247, RFC 2798
Obsoletes: RFC 2256 Obsoletes: RFC 2256
LDAP: Schema for User Applications LDAP: Schema for User Applications
<draft-ietf-ldapbis-user-schema-08> draft-ietf-ldapbis-user-schema-09.txt
Copyright (C) The Internet Society (2005). All Rights Reserved.
Status of this Memo Status of this Memo
This document is intended to be, after appropriate review and This document is an Internet-Draft and is subject to all provisions
revision, submitted to the RFC Editor as a Standard Track document. of Section 3 of RFC 3978. By submitting this Internet-Draft, each
Distribution of this memo is unlimited. Technical discussion of author represents that any applicable patent or other IPR claims of
this document will take place on the IETF LDAP Revision Working which he or she is aware have been or will be disclosed, and any of
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please which he or she become aware will be disclosed, in accordance with
send editorial comments directly to the author <kdally@mitre.org>. RFC 3979.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.html. http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
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 editor
<andrew.sciberras@eb2bcom.com>.
This Internet-Draft expires on 4 October 2005.
Copyright Notice Copyright Notice
Copyright 2004, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society 2005. All Rights Reserved.
Abstract Abstract
This document is a integral part of the Lightweight Directory Access This document is an integral part of the Lightweight Directory Access
Protocol (LDAP) technical specification [ROADMAP]. It provides a Protocol (LDAP) technical specification [Roadmap]. It provides a
technical specification of attribute types and object classes technical specification of attribute types and object classes
intended for use by LDAP directory clients for many directory intended for use by LDAP directory clients for many directory
services, such as, White Pages. These objects are widely used as a services, such as, White Pages. These objects are widely used as a
basis for the schema in many LDAP directories. This document does basis for the schema in many LDAP directories. This document does
not cover attributes used for the administration of directory not cover attributes used for the administration of directory
servers, nor does it include directory objects defined for specific servers, nor does it include directory objects defined for specific
uses in other documents. uses in other documents.
Table of Contents Table of Contents
Status of this Memo 1 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1
Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . . . 1
Copyright Notice 1 Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 3
Abstract 1 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Relationship with other specifications . . . . . . . . . 5
Table of Contents 2 1.2 Conventions. . . . . . . . . . . . . . . . . . . . . . . 5
1.3 General Issues . . . . . . . . . . . . . . . . . . . . . 5
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 6
2.3 cn 6
2.4 dc 6
2.5 description 7
2.6 destinationIndicator 7
2.7 distinguishedName 7
2.8 dnQualifier 8
2.9 enhancedSearchGuide 8
2.10 facsimileTelephoneNumber 8
2.11 generationQualifier 8
2.12 givenName 9
2.13 houseIdentifier 9
2.14 initials 9
2.15 internationalISDNNumber 9
2.16 l 10
2.17 member 10
2.18 name 10
2.19 o 10
2.20 ou 11
2.21 owner 11
2.22 physicalDeliveryOfficeName 11
2.23 postalAddress 11
2.24 postalCode 12
2.25 postOfficeBox 12
2.26 preferredDeliveryMethod 12
2.27 registeredAddress 13
2.28 roleOccupant 13
2.29 searchGuide 13
2.30 seeAlso 13
2.31 serialNumber 14
2.32 sn 14
2.33 st 14
2.34 street 14
2.35 telephoneNumber 15
2.36 teletexTerminalIdentifier 15
2.37 telexNumber 15
2.38 title 15
2.39 uid 15
2.40 uniqueMember 16
2.41 userPassword 16
2.42 x121Address 17
2.43 x500UniqueIdentifier 17
3. Object Classes 18 2. Attribute Types . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 applicationProcess 18 2.1 'businessCategory' . . . . . . . . . . . . . . . . . . . 6
3.2 country 18 2.2 'c'. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 device 18 2.3 'cn' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 groupOfNames 19 2.4 'dc' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 groupOfUniqueNames 19 2.5 'description'. . . . . . . . . . . . . . . . . . . . . . 8
3.6 locality 19 2.6 'destinationIndicator' . . . . . . . . . . . . . . . . . 8
3.7 organization 20 2.7 'distinguishedName'. . . . . . . . . . . . . . . . . . . 8
3.8 organizationalPerson 20 2.8 'dnQualifier'. . . . . . . . . . . . . . . . . . . . . . 9
3.9 organizationalRole 20 2.9 'enhancedSearchGuide'. . . . . . . . . . . . . . . . . . 9
3.10 organizationalUnit 21 2.10 'facsimileTelephoneNumber' . . . . . . . . . . . . . . . 10
3.11 person 21 2.11 'generationQualifier'. . . . . . . . . . . . . . . . . . 10
3.12 residentialPerson 21 2.12 'givenName'. . . . . . . . . . . . . . . . . . . . . . . 10
2.13 'houseIdentifier'. . . . . . . . . . . . . . . . . . . . 11
2.14 'initials' . . . . . . . . . . . . . . . . . . . . . . . 11
2.15 'internationalISDNNumber'. . . . . . . . . . . . . . . . 11
2.16 'l'. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.17 'member' . . . . . . . . . . . . . . . . . . . . . . . . 12
2.18 'name' . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.19 'o'. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.20 'ou' . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.21 'owner'. . . . . . . . . . . . . . . . . . . . . . . . . 13
2.22 'physicalDeliveryOfficeName' . . . . . . . . . . . . . . 13
2.23 'postalAddress'. . . . . . . . . . . . . . . . . . . . . 14
2.24 'postalCode' . . . . . . . . . . . . . . . . . . . . . . 14
2.25 'postOfficeBox'. . . . . . . . . . . . . . . . . . . . . 14
2.26 'preferredDeliveryMethod'. . . . . . . . . . . . . . . . 15
2.27 'registeredAddress'. . . . . . . . . . . . . . . . . . . 15
2.28 'roleOccupant' . . . . . . . . . . . . . . . . . . . . . 16
2.29 'searchGuide'. . . . . . . . . . . . . . . . . . . . . . 16
2.30 'seeAlso'. . . . . . . . . . . . . . . . . . . . . . . . 16
2.31 'serialNumber' . . . . . . . . . . . . . . . . . . . . . 17
2.32 'sn' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.33 'st' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.34 'street' . . . . . . . . . . . . . . . . . . . . . . . . 18
2.35 'telephoneNumber'. . . . . . . . . . . . . . . . . . . . 18
2.36 'teletexTerminalIdentifier'. . . . . . . . . . . . . . . 18
2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . . 19
2.38 'title'. . . . . . . . . . . . . . . . . . . . . . . . . 19
2.39 'uid'. . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.40 'uniqueMember' . . . . . . . . . . . . . . . . . . . . . 19
2.41 'userPassword' . . . . . . . . . . . . . . . . . . . . . 20
2.42 'x121Address'. . . . . . . . . . . . . . . . . . . . . . 21
2.43 'x500UniqueIdentifier' . . . . . . . . . . . . . . . . . 21
4. IANA Considerations 22 3. Object Classes. . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 'applicationProcess' . . . . . . . . . . . . . . . . . . 22
3.2 'country'. . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 'dcObject' . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 'device' . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 'groupOfNames' . . . . . . . . . . . . . . . . . . . . . 23
3.6 'groupOfUniqueNames' . . . . . . . . . . . . . . . . . . 23
3.7 'locality' . . . . . . . . . . . . . . . . . . . . . . . 24
3.8 'organization' . . . . . . . . . . . . . . . . . . . . . 24
3.9 'organizationalPerson' . . . . . . . . . . . . . . . . . 24
3.10 'organizationalRole' . . . . . . . . . . . . . . . . . . 25
3.11 'organizationalUnit' . . . . . . . . . . . . . . . . . . 25
3.12 'person' . . . . . . . . . . . . . . . . . . . . . . . . 26
3.13 'residentialPerson'. . . . . . . . . . . . . . . . . . . 26
3.14 'uidObject'. . . . . . . . . . . . . . . . . . . . . . . 26
5. Security Considerations 23 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Acknowledgements 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. References 24 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 29
7.1 Normative 24
7.2 Informative 25
8. Author's Address 26 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1 Normative. . . . . . . . . . . . . . . . . . . . . . . . 30
7.2 Informative. . . . . . . . . . . . . . . . . . . . . . . 31
9. Intellectual Property Rights (IPR) Disclosure 26 8. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 31
10. IPR Notice 26 9. Intellectual Property Statement . . . . . . . . . . . . . . . 32
11. Copyright Notice and Disclaimer 27 10. Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This document provides an overview of attribute types and object This document provides an overview of attribute types and object
classes intended for use by Lightweight Directory Access Protocol classes intended for use by Lightweight Directory Access Protocol
directory clients for many directory services, such as, White Pages. (LDAP) directory clients for many directory services, such as, White
Originally specified in the X.500 [X.500] documents, these objects Pages. Originally specified in the X.500 [X.500] documents, these
are widely used as a basis for the schema in many LDAP directories. objects are widely used as a basis for the schema in many LDAP
This document does not cover attributes used for the administration directories. This document does not cover attributes used for the
of directory servers, nor does it include directory objects defined administration of directory servers, nor does it include directory
for specific uses in other documents. objects defined for specific uses in other documents.
1.1 Situation 1.1 Relationship with other specifications
This document is a integral part of the LDAP technical specification This document is an integral part of the LDAP technical specification
[ROADMAP] which obsoletes the previously defined LDAP technical [Roadmap] which obsoletes the previously defined LDAP technical
specification [RFC3377] in its entirety. In terms of RFC 2256, specification, RFC 3377, in its entirety. In terms of RFC 2256,
Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes]. Sections 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 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 2.4 of remainder of RFC 2256 is obsoleted by this document. Section 2.4 of
this document supercedes the technical specification for the 'dc' this document supersedes the technical specification for the 'dc'
attribute type found in RFC 2247. The remainder of RFC 2247 remains attribute type and 'dcObject' object class found in RFC 2247. The
in force. remainder of RFC 2247 remains in force.
This document updates RFC 2798 by replacing the informative This document updates RFC 2798 by replacing the informative
description of the 'uid' attribute type, with the definitive description of the 'uid' attribute type, with the definitive
description provided in Section 2.39 of this document. description provided in Section 2.39 of this document.
A number of schema elements which were included in the previous A number of schema elements which were included in the previous
revision of the LDAP Technical Specification are not included in this revision of the LDAP Technical Specification are not included in this
revision of LDAP. PKI-related schema elements are now specified in revision of LDAP. PKI-related schema elements are now specified in
[LDAP-CERT] and [LDAP-CRL]. Unless reintroduced in future technical [LDAP-PKI]. Unless reintroduced in future technical specifications,
specifications, the remainder are to be considered Historic. the remainder are to be considered Historic.
The descriptions in this document SHALL be considered definitive for
use in LDAP.
1.2 Conventions 1.2 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.3 General Issues 1.3 General Issues
This document references Syntaxes given in Section 3 of [Syntaxes] This document references Syntaxes defined in Section 3 of [Syntaxes]
and Matching Rules specified in Section 4 of [Syntaxes]. and Matching Rules defined in Section 4 of [Syntaxes].
The definitions of Attribute Types and Object Classes are written The definitions of Attribute Types and Object Classes are written
using the ABNF form of AttributeTypeDescription and using the Augmented Backus-Naur Form (ABNF) [RFC2234] of
ObjectClassDescription given in [Models]. Lines have been folded AttributeTypeDescription and ObjectClassDescription given in
for readability. [Models]. Lines have been folded for readability. When such values
are transferred as attribute values in the LDAP Protocol the values
1.4 Source will not contain line breaks.
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 2. Attribute Types
The Attribute Types contained in this section hold user information. The Attribute Types contained in this section hold user information.
There is no requirement that servers implement the following There is no requirement that servers implement the 'searchGuide' and
attribute types: 'teletexTerminalIdentifier' attribute types. In fact, their use is
greatly discouraged.
searchGuide
teletexTerminalIdentifier
In fact, their use is greatly discouraged.
An LDAP server implementation SHOULD recognize the rest of the An LDAP server implementation SHOULD recognize the rest of the
attribute types described in this section. attribute types described in this section.
2.1 businessCategory 2.1 'businessCategory'
The businessCategory attribute type describes the kinds of business The 'businessCategory' attribute type describes the kinds of business
performed by an organization (e.g., "banking", "transportation"). performed by an organization. Each kind is one value of this
Each kind is one value of this multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.15 NAME 'businessCategory' ( 2.5.4.15 NAME 'businessCategory'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 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 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
syntax [Syntaxes]. [Syntaxes].
2.2 c Examples: "banking", "transportation" and "real estate".
The c (countryName) attribute type contains a two-letter ISO 3166 2.2 'c'
[ISO3166] country code (e.g., "DE"). (Source: X.520)
The 'c' ('countryName' in X.500) attribute type contains a two-letter
ISO 3166 [ISO3166] country code.
(Source: X.520 [X.520])
( 2.5.4.6 NAME 'c' ( 2.5.4.6 NAME 'c'
SUP name SUP name
SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
SINGLE-VALUE ) SINGLE-VALUE )
2.3 cn 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
[Syntaxes].
The cn (commonName) attribute type contains names of an object Examples: "DE", "AU" and "FR".
(e.g., "Martin K Smith", "Marty Smith", "printer12"). Each name is
one value of this multi-valued attribute. If the object corresponds 2.3 'cn'
to a person, it is typically the person's full name.
(Source: X.520) The 'cn' ('commonName' in X.500) attribute type contains names of an
object. 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 [X.520])
( 2.5.4.3 NAME 'cn' ( 2.5.4.3 NAME 'cn'
SUP name ) SUP name )
2.4 dc Examples: "Martin K Smith", "Marty Smith" and "printer12".
The dc (short for domainComponent) attribute type is a string 2.4 'dc'
holding one component, a <label> [RFC1034}, of a DNS domain name
(e.g., "example" or "com", but not "example.com"). The encoding of The 'dc' ('domainComponent' in RFC 2247) attribute type is a string
IA5String for use in LDAP is simply the characters of the string holding one component, a <label> [RFC1034], of a DNS domain name.
itself. The equality matching rule is case insensitive, as is The encoding of IA5String for use in LDAP is simply the characters of
today's DNS. the string itself. The equality matching rule is case insensitive,
as is today's DNS.
(Source: RFC 2247 [RFC2247])
( 0.9.2342.19200300.100.1.25 NAME 'dc' ( 0.9.2342.19200300.100.1.25 NAME 'dc'
EQUALITY caseIgnoreIA5Match EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE ) SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
syntax [Syntaxes]. [Syntaxes].
Examples: Valid values include "example" and "com". The value
"example.com" is invalid, because it contains two <label>
components.
It is noted that the directory will not ensure that values of this It is noted that the directory will not ensure that values of this
attribute conform to the label production [RFC1034]. It is the attribute conform to the label production [RFC1034]. It is the
application responsibility to ensure domains it stores in this application's responsibility to ensure domains it stores in this
attribute are appropriately represented. attribute are appropriately represented.
It is also noted that applications supporting Internationalized It is also noted that applications supporting Internationalized
Domain Names SHALL use the ToASCII method [RFC3490] to produce Domain Names SHALL use the ToASCII method [RFC3490] to produce
<label> components of the <domain> production. <label> components of the <domain> [RFC1034] production. The special
considerations discussed in section 4 of RFC 3490 [RFC3490] should be
taken, depending on whether the domain component is used for "stored"
or "query" purposes.
2.5 description 2.5 'description'
The description attribute type contains human-readable descriptive The 'description' attribute type contains human-readable descriptive
phrases about the object (e.g., "a color printer", "Maintenance is phrases about the object. Each description is one value of this
done every Monday, at 1pm."). Each description is one value of this
multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.13 NAME 'description' ( 2.5.4.13 NAME 'description'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 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 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
syntax [Syntaxes]. [Syntaxes].
2.6 destinationIndicator Examples: "a color printer", "Maintenance is done every Monday, at
1pm." and "distribution list for all technical staff".
The destinationIndicator attribute type contains country and city 2.6 'destinationIndicator'
The 'destinationIndicator' attribute type contains country and city
strings, associated with the object (the addressee), needed to strings, associated with the object (the addressee), needed to
provide the Public Telegram Service. Each string is one value of provide the Public Telegram Service. The strings are composed in
this multi-valued attribute. The strings are composed in accordance accordance with CCITT Recommendations F.1 [F.1] and F.31 [F.31].
with CCITT Recommendations F.1 [F.1] and F.31 [F.31]. Each string is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.27 NAME 'destinationIndicator' ( 2.5.4.27 NAME 'destinationIndicator'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) 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 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
syntax [Syntaxes]. [Syntaxes].
2.7 distinguishedName Examples: "AASD" as a destination indicator for Sydney, Australia.
"GBLD" as a destination indicator for London, United
Kingdom.
The distinguishedName attribute type is the attribute supertype from It is noted that the directory will not ensure that values of this
which attribute types with DN syntax inherit, instead of containing attribute conform to the F.1 and F.30 CCITT Recommendations. It is
values which name the object itself. The attribute type is the application's responsibility to ensure destination indicators
multi-valued. that it stores in this attribute are appropriately constructed.
2.7 'distinguishedName'
The 'distinguishedName' attribute type is not used as the name of the
object itself, but it is instead a base type from which some user
attribute types with a DN syntax can inherit.
It is unlikely that values of this type itself will occur in an It is unlikely that values of this type itself will occur in an
entry. LDAP server implementations which do not support attribute entry. LDAP server implementations which do not support attribute
subtyping need not recognize this attribute in requests. Client subtyping need not recognize this attribute in requests. Client
implementations MUST NOT assume that LDAP servers are capable of implementations MUST NOT assume that LDAP servers are capable of
performing attribute subtyping. performing attribute subtyping.
(Source: X.520 [X.520])
( 2.5.4.49 NAME 'distinguishedName' ( 2.5.4.49 NAME 'distinguishedName'
EQUALITY distinguishedNameMatch EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 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]. 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [Syntaxes].
2.8 dnQualifier 2.8 'dnQualifier'
The dnQualifier attribute type contains disambiguating information The 'dnQualifier' attribute type contains disambiguating information
strings to add to the relative distinguished name of an entry. The strings to add to the relative distinguished name of an entry. The
information is intended for use when merging data from multiple information is intended for use when merging data from multiple
sources in order to prevent conflicts between entries which would sources in order to prevent conflicts between entries which would
otherwise have the same name. Each string is one value of this otherwise have the same name. Each string is one value of this
multi-valued attribute. It is recommended that a value of the multi-valued attribute. It is recommended that a value of the
dnQualifier attribute be the same for all entries from a 'dnQualifier' attribute be the same for all entries from a particular
particular source. source.
(Source: X.520 [X.520])
( 2.5.4.46 NAME 'dnQualifier' ( 2.5.4.46 NAME 'dnQualifier'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) 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 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
syntax [Syntaxes]. [Syntaxes].
2.9 enhancedSearchGuide Examples: "20050322123345Z" - timestamps can be used to disambiguate
information.
"123456A" - serial numbers can be used to disambiguate
information.
The enhancedSearchGuide attribute type contains sets of information 2.9 'enhancedSearchGuide'
The 'enhancedSearchGuide' attribute type contains sets of information
for use by directory clients in constructing search filters. Each for use by directory clients in constructing search filters. Each
set is one value of this multi-valued attribute. set is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.47 NAME 'enhancedSearchGuide' ( 2.5.4.47 NAME 'enhancedSearchGuide'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 ) 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 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
syntax [Syntaxes]. [Syntaxes].
2.10 facsimileTelephoneNumber Examples: "person#(sn$APPROX)#wholeSubtree"
"organizationalUnit#(ou$SUBSTR)#oneLevel"
The facsimileTelephoneNumber attribute type contains telephone 2.10 'facsimileTelephoneNumber'
The 'facsimileTelephoneNumber' attribute type contains telephone
numbers (and, optionally, the parameters) for facsimile terminals. numbers (and, optionally, the parameters) for facsimile terminals.
Each telephone number is one value of this multi-valued attribute. Each telephone number is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.23 NAME 'facsimileTelephoneNumber' ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) 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 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
Number syntax [Syntaxes]. Number syntax [Syntaxes].
2.11 generationQualifier Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution"
The generationQualifier attribute type contains name strings that 2.11 'generationQualifier'
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 The 'generationQualifier' attribute type contains name strings that
attribute. are the part of a person's name which typically is the suffix. Each
string is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.44 NAME 'generationQualifier' ( 2.5.4.44 NAME 'generationQualifier'
SUP name ) SUP name )
2.12 givenName Examples: "III", "3rd" and "Jr.".
The givenName attribute type contains name strings that are the part 2.12 'givenName'
of a person's name which is not their surname. Each string is one
value of this multi-valued attribute. 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.
(Source: X.520 [X.520])
( 2.5.4.42 NAME 'givenName' ( 2.5.4.42 NAME 'givenName'
SUP name ) SUP name )
2.13 houseIdentifier Examples: "Andrew", "Charles" and "Joanne"
The houseIdentifier attribute type contains identifiers for a 2.13 'houseIdentifier'
The 'houseIdentifier' attribute type contains identifiers for a
building within a location. Each identifier is one value of this building within a location. Each identifier is one value of this
multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.51 NAME 'houseIdentifier' ( 2.5.4.51 NAME 'houseIdentifier'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 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 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
syntax [Syntaxes]. [Syntaxes].
2.14 initials Examples: "20" to represent a the house number 20.
The initials attribute type contains strings of initials of some or 2.14 'initials'
all of an individual's names, except the surname(s)
(e.g., "K. A.", "K"). Each string is one value of this multi-valued The 'initials' attribute type contains strings of initials of some or
attribute. all of an individual's names, except the surname(s). Each string is
one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.43 NAME 'initials' ( 2.5.4.43 NAME 'initials'
SUP name ) SUP name )
2.15 internationalISDNNumber Examples: "K. A." and "K".
The internationalISDNNumber attribute type contains ISDN addresses, 2.15 'internationalISDNNumber'
as defined in ITU Recommendation E.164 [E.164]. Each address is one
value of this multi-valued attribute. The 'internationalISDNNumber' attribute type contains Integrated
Services Digital Network (ISDN) addresses, as defined in the
International Telecommunication Union (ITU) Recommendation E.164
[E.164]. Each address is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.25 NAME 'internationalISDNNumber' ( 2.5.4.25 NAME 'internationalISDNNumber'
EQUALITY numericStringMatch EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch SUBSTR numericStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 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 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
syntax [Syntaxes]. [Syntaxes].
2.16 l Example: "0198 333 333"
The l (localityName) attribute type contains names of a locality or 2.16 'l'
place, such as a city, county or other geographic region (e.g.,
"Geneva"). Each name is one value of this multi-valued attribute. The 'l' ('localityName' in X.500) attribute type contains names of a
(Source: X.520) locality or place, such as a city, county or other geographic region.
Each name is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.7 NAME 'l' ( 2.5.4.7 NAME 'l'
SUP name ) SUP name )
2.17 member Examples: "Geneva", "Paris" and "Edinburgh".
The member attribute type contains the Distinguished Names of 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 objects that are on a list or in a group. Each name is one value of
this multi-valued attribute. this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.31 NAME 'member' ( 2.5.4.31 NAME 'member'
SUP distinguishedName ) SUP distinguishedName )
2.18 name Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
"cn=John Xerri,ou=Finance,o=Widget\, Inc" may
be two members of the financial team (group) at Widget,
Inc. In which case, both of these distinguished names would
be present as individual values of the member attribute.
The name attribute type is the attribute supertype from which 2.18 'name'
attributes with the name syntax inherit. Such attributes are
typically used for naming. The attribute type is multi-valued. The 'name' attribute type is the attribute supertype from which user
attribute types with the name syntax inherit. Such attribute types
are typically used for naming. The attribute type is multi-valued.
It is unlikely that values of this type itself will occur in an It is unlikely that values of this type itself will occur in an
entry. LDAP server implementations which do not support attribute entry. LDAP server implementations which do not support attribute
subtyping need not recognize this attribute in requests. Client subtyping need not recognize this attribute in requests. Client
implementations MUST NOT assume that LDAP servers are capable of implementations MUST NOT assume that LDAP servers are capable of
performing attribute subtyping. performing attribute subtyping.
(Source: X.520 [X.520])
( 2.5.4.41 NAME 'name' ( 2.5.4.41 NAME 'name'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 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 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
syntax [Syntaxes]. [Syntaxes].
2.19 o 2.19 'o'
The o (organizationName) attribute type contains the names of an The 'o' ('organizationName' in X.500) attribute type contains the
organization (e.g., "IETF", "Internet Engineering Task Force"). names of an organization. Each name is one value of this
Each name is one value of this multi-valued attribute. multi-valued attribute.
(Source: X.520) (Source: X.520 [X.520])
( 2.5.4.10 NAME 'o' ( 2.5.4.10 NAME 'o'
SUP name ) SUP name )
2.20 ou Examples: "Widget", "Widget, Inc." and "Widget, Incorporated.".
The ou (organizationalUnitName) attribute type contains the names of 2.20 'ou'
an organizational unit (e.g., "Application Area", "LDAPbis WG").
Each name is one value of this multi-valued attribute. The 'ou' ('organizationalUnitName' in X.500) attribute type contains
(Source: X.520) the names of an organizational unit. Each name is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.11 NAME 'ou' ( 2.5.4.11 NAME 'ou'
SUP name ) SUP name )
2.21 owner Examples: "Finance", "Human Resources" and "Research and
Development".
The owner attribute type contains the Distinguished Names of objects 2.21 'owner'
that have an ownership responsibility for the object that is owned.
Each owner's name is one value of this multi-valued attribute. The 'owner' attribute type contains the Distinguished Names of
(e.g., The list object which has DN: "cn=All Employees, objects that have an ownership responsibility for the object that is
ou=Mailing List,o=Widget\, Inc.", is owned by the Human Resources owned. Each owner's name is one value of this multi-valued
Director. Therefore, the DN of the director (role) would be a value attribute.
of the owner attribute: "cn=Human Resources Director, (Source: X.520 [X.520])
ou=employee,o=Widget\, Inc.")
( 2.5.4.32 NAME 'owner' ( 2.5.4.32 NAME 'owner'
SUP distinguishedName ) SUP distinguishedName )
2.22 physicalDeliveryOfficeName Example: The mailing list object, whose DN is "cn=All Employees,
ou=Mailing List,o=Widget\, Inc.", is owned by the Human
Resources Director.
Therefore, the value of the owner attribute within the
mailing list object, would be the DN of the director (role):
"cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
The physicalDeliveryOfficeName attribute type contains names that a 2.22 'physicalDeliveryOfficeName'
Postal Service uses to identify a post office (e.g., "Bremerhaven,
Main", "Bremerhaven, Bonnstrasse").
The 'physicalDeliveryOfficeName' attribute type contains names that a
Postal Service uses to identify a post office.
(Source: X.520 [X.520])
( 2.5.4.19 NAME 'physicalDeliveryOfficeName' ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 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 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
syntax [Syntaxes]. [Syntaxes].
2.23 postalAddress Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
The postalAddress attribute type contains addresses used by a Postal 2.23 'postalAddress'
Service to perform services for the object. Each address is one
value of this multi-valued attribute.(e.g., one value is "15 Main The 'postalAddress' attribute type contains addresses used by a
St.$Ottawa$Canada"). Postal Service to perform services for the object. Each address is
one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.16 NAME 'postalAddress' ( 2.5.4.16 NAME 'postalAddress'
EQUALITY caseIgnoreListMatch EQUALITY caseIgnoreListMatch
SUBSTR caseIgnoreListSubstringsMatch SUBSTR caseIgnoreListSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 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 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
[Syntaxes].
The postalCode attribute type contains codes used by a Postal Example: "15 Main St.$Ottawa$Canada".
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 2.24 'postalCode'
multi-valued attribute.
The 'postalCode' attribute type contains codes used by a Postal
Service to identify postal service zones. Each code is one value of
this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.17 NAME 'postalCode' ( 2.5.4.17 NAME 'postalCode'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 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 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
syntax [Syntaxes]. [Syntaxes].
2.25 postOfficeBox Example: "22180", to identify Vienna, VA in the USA.
The postOfficeBox attribute type contains numbers that a Postal 2.25 'postOfficeBox'
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 The 'postOfficeBox' attribute type contains postal box identifiers
value of this multi-valued attribute. that a Postal Service uses when a customer arranges to receive mail
at a box on premises of the Postal Service. Each postal box
identifier is a single value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.18 NAME 'postOfficeBox' ( 2.5.4.18 NAME 'postOfficeBox'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 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 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
syntax [Syntaxes]. [Syntaxes].
2.26 preferredDeliveryMethod Example: "Box 45".
The preferredDeliveryMethod attribute type contains an indication of 2.26 'preferredDeliveryMethod'
the preferred method of getting a message to the object. For
example, if mhs-delivery is preferred over telephone-delivery, which The 'preferredDeliveryMethod' attribute type contains an indication
is preferred over all other methods, the value would be: of the preferred method of getting a message to the object.
mhs $ telephone (Source: X.520 [X.520])
( 2.5.4.28 NAME 'preferredDeliveryMethod' ( 2.5.4.28 NAME 'preferredDeliveryMethod'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
SINGLE-VALUE ) SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
syntax [Syntaxes]. [Syntaxes].
2.27 registeredAddress Example: If the mhs-delivery Delivery Method is preferred over
telephone-delivery, which is preferred over all other
methods, the value would be: "mhs $ telephone"
The registeredAddress attribute type contains postal addresses 2.27 'registeredAddress'
The 'registeredAddress' attribute type contains postal addresses
suitable for reception of telegrams or expedited documents, where it suitable for reception of telegrams or expedited documents, where it
is necessary to have the recipient accept delivery. Each address is is necessary to have the recipient accept delivery. Each address is
one value of this multi-valued attribute. (e.g., one value is one value of this multi-valued attribute.
"Receptionist\, Widget Inc.\, 15 Main St.\, Ottawa\, Canada") (Source: X.520 [X.520])
( 2.5.4.26 NAME 'registeredAddress' ( 2.5.4.26 NAME 'registeredAddress'
SUP postalAddress SUP postalAddress
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 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 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
syntax [Syntaxes]. [Syntaxes].
2.28 roleOccupant Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
The roleOccupant attribute type contains the Distinguished Names of 2.28 'roleOccupant'
objects (normally people) that fulfill the responsibilities of a
role object. For example, the role object, "cn=Human Resources The 'roleOccupant' attribute type contains the Distinguished Names of
Director,ou=Position,o=Widget\, Inc.", is fulfilled by two people objects (normally people) that fulfill the responsibilities of a role
whose object names are "cn=Mary Smith,ou=employee,o=Widget\, Inc." object. Each distinguished name is one value of this multi-valued
and "cn=James Brown,ou=employee,o=Widget\, Inc." The roleOccupant attribute.
attribute would have two values, one for each occupant. (Source: X.520 [X.520])
( 2.5.4.33 NAME 'roleOccupant' ( 2.5.4.33 NAME 'roleOccupant'
SUP distinguishedName ) SUP distinguishedName )
2.29 searchGuide 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.". The 'roleOccupant'
attribute will contain both of these distinguished names,
since they are the occupants of this role.
The searchGuide attribute type contains sets of information for use 2.29 'searchGuide'
The 'searchGuide' attribute type contains sets of information for use
by clients in constructing search filters. It is superseded by by clients in constructing search filters. It is superseded by
enhancedSearchGuide, described above in section 2.9. 'enhancedSearchGuide', described above in section 2.9. Each set is
one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.14 NAME 'searchGuide' ( 2.5.4.14 NAME 'searchGuide'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) 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]. 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [Syntaxes].
2.30 seeAlso Example: "person#sn$EQ"
The seeAlso attribute type contains Distinguished Names of objects 2.30 'seeAlso'
that are related to the subject object. For example, the person
object, "cn=James Brown,ou=employee,o=Widget Inc." is related to The 'seeAlso' attribute type contains Distinguished Names of objects
the role objects, "cn=Football Team Captain,ou=sponsored activities, that are related to the subject object. Each related object name is
o=Widget Inc." and "cn=Chess Team,ou=sponsored activities,o=Widget one value of this multi-valued attribute.
Inc.". Each related object name is one value of this multi-valued
attribute. (Source: X.520 [X.520])
( 2.5.4.34 NAME 'seeAlso' ( 2.5.4.34 NAME 'seeAlso'
SUP distinguishedName ) SUP distinguishedName )
2.31 serialNumber 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.".
Since the role objects are related to the person object, the
'seeAlso' attribute will contain the distinguished name of
each role object as separate values.
The serialNumber attribute type contains the serial numbers of 2.31 'serialNumber'
devices (e.g., "WI-3005". Each number is one value of this
multi-valued attribute. The 'serialNumber' attribute type contains the serial numbers of
devices. Each serial number is one value of this multi-valued
attribute.
(Source: X.520 [X.520])
( 2.5.4.5 NAME 'serialNumber' ( 2.5.4.5 NAME 'serialNumber'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) 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 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
syntax [Syntaxes]. [Syntaxes].
2.32 sn Examples: "WI-3005" and "XF551426".
The sn (surname)attribute type contains name strings for the family 2.32 'sn'
names of a person (e.g., "Smith"). Each string is one value of this
multi-valued attribute. (Source: X.520) The 'sn' ('surname' in X.500) attribute type contains name strings
for the family names of a person. Each string is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.4 NAME 'sn' ( 2.5.4.4 NAME 'sn'
SUP name ) SUP name )
2.33 st Example: "Smith"
The st (stateOrProvinceName) attribute type contains the full names 2.33 'st'
of states or provinces, (e.g. "California"). Each name is one value
of this multi-valued attribute. The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
full names of states or provinces. Each name is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.8 NAME 'st' ( 2.5.4.8 NAME 'st'
SUP name ) SUP name )
2.34 street Example: "California".
The street (streetAddress) attribute type contains physical 2.34 'street'
addresses of the object to which the entry corresponds, such as an
address for package delivery. Each address is one value of this The 'street' ('streetAddress' in X.500) attribute type contains site
information from a postal address (i.e., the street name, place,
avenue, and the house number.). Each street is one value of this
multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.9 NAME 'street' ( 2.5.4.9 NAME 'street'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 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 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
syntax [Syntaxes]. [Syntaxes].
2.35 telephoneNumber Example: "15 Main St."
The telephoneNumber attribute type contains telephone numbers 2.35 'telephoneNumber'
complying with ITU Recommendation E.123 [E.123] (e.g.,
+1 234 567 8901) Each number is one value of this multi-valued The 'telephoneNumber' attribute type contains telephone numbers that
attribute. comply with the ITU Recommendation E.123 [E.123]. Each number is one
value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.20 NAME 'telephoneNumber' ( 2.5.4.20 NAME 'telephoneNumber'
EQUALITY telephoneNumberMatch EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 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 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
syntax [Syntaxes]. [Syntaxes].
2.36 teletexTerminalIdentifier Example: "+1 234 567 8901".
2.36 'teletexTerminalIdentifier'
The withdrawal of Rec. F.200 has resulted in the withdrawal of this The withdrawal of Rec. F.200 has resulted in the withdrawal of this
attribute. attribute.
(Source: X.520 [X.520])
( 2.5.4.22 NAME 'teletexTerminalIdentifier' ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
2.37 telexNumber 1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
Identifier syntax [Syntaxes].
The telexNumber attribute type contains sets of strings which are a 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. telex number, country code, and answerback code of a telex terminal.
Each set is one value of this multi-valued attribute. Each set is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.21 NAME 'telexNumber' ( 2.5.4.21 NAME 'telexNumber'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) 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 1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
syntax [Syntaxes]. [Syntaxes].
2.38 title Example: "12345$023$ABCDE"
This attribute contains the title, such as "Vice President", of a 2.38 'title'
person in their organizational context.
The 'title' attribute type contains the title of a person in their
organizational context. Each title is one value of this multi-valued
attribute.
(Source: X.520 [X.520])
( 2.5.4.12 NAME 'title' ( 2.5.4.12 NAME 'title'
SUP name ) SUP name )
2.39 uid Examples: "Vice President", "Software Engineer" and "CEO".
The uid attribute type contains computer system login names 2.39 'uid'
associated with the object. (Source: RFC 1274). Each name is one
The 'uid' ('userid' in RFC 1274) attribute type contains computer
system login names associated with the object. Each name is one
value of this multi-valued attribute. value of this multi-valued attribute.
(Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])
( 0.9.2342.19200300.100.1.1 ( 0.9.2342.19200300.100.1.1 NAME 'uid'
NAME 'uid'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 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 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes].
syntax [Syntaxes]. Examples: "s9709015", "admin" and "Administrator".
2.40 uniqueMember 2.40 'uniqueMember'
The uniqueMember attribute type contains the Distinguished Names of The 'uniqueMember' attribute type contains the Distinguished Names of
an object that is on a list or in a group, where the Relative an object that is on a list or in a group, where the Relative
Distinguished Names of the object include a value that distinguishes Distinguished Names of the object include a value that distinguishes
between objects when a distinguished name has been reused. For between objects when a distinguished name has been reused. Each
example, if "ou=1st Battalion,o=Defense,c=US" is a battalion that distinguished name is one value of this multi-valued attribute.
was disbanded, establishing a new battalion with the "same" name (Source: X.520 [X.520])
would have a uid value added, resulting in "ou=1st Battalion,
o=Defense,c=US#'010101'B".
( 2.5.4.50 NAME 'uniqueMember' ( 2.5.4.50 NAME 'uniqueMember'
EQUALITY uniqueMemberMatch EQUALITY uniqueMemberMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID 1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
syntax [Syntaxes]. syntax [Syntaxes].
2.41 userPassword 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 unique identifier value added, resulting in
"ou=1st Battalion, o=Defense,c=US#'010101'B".
The userPassword attribute contains octet strings that are known 2.41 'userPassword'
The 'userPassword' attribute contains octet strings that are known
only to the user and the system to which the user has access. Each only to the user and the system to which the user has access. Each
string is one value of this multi-valued attribute. string is one value of this multi-valued attribute.
The application SHOULD prepare textual strings used as passwords by The application SHOULD prepare textual strings used as passwords by
transcoding them to Unicode, applying SASLprep [SASLprep], and transcoding them to Unicode, applying SASLprep [SASLprep], and
encoding as UTF-8. encoding as UTF-8. The determination of whether a password is
textual is a local client matter.
(Source: X.509 [X.509])
( 2.5.4.35 NAME 'userPassword' ( 2.5.4.35 NAME 'userPassword'
EQUALITY octetStringMatch EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 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 1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
syntax [Syntaxes]. [Syntaxes].
Passwords are stored using an Octet String syntax and are not Passwords are stored using an Octet String syntax and are not
encrypted. Transfer of cleartext passwords is strongly discouraged encrypted. Transfer of cleartext passwords is strongly discouraged
where the underlying transport service cannot guarantee where the underlying transport service cannot guarantee
confidentiality and may result in disclosure of the password to confidentiality and may result in disclosure of the password to
unauthorized parties. unauthorized parties.
An example of a need for multiple values in the userPassword An example of a need for multiple values in the 'userPassword'
attribute is an environment where every month the user was expected attribute is an environment where every month the user was expected
to use a different password generated by some automated system. to use a different password generated by some automated system.
During transitional periods, like say the last and first day of the During transitional periods, like the last and first day of the
periods, it may be necessary to allow two passwords for the two periods, it may be necessary to allow two passwords for the two
consecutive periods to be valid in the system. consecutive periods to be valid in the system.
2.42 x121Address 2.42 'x121Address'
The x121Address attribute type contains data network addresses The 'x121Address' attribute type contains data network addresses as
(e.g., 36111222333444555) as defined by ITU Recommendation X.121 defined by ITU Recommendation X.121 [X.121]. Each address is one
[X.121]. Each address is one value of this multi-valued attribute. value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.24 NAME 'x121Address' ( 2.5.4.24 NAME 'x121Address'
EQUALITY numericStringMatch EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch SUBSTR numericStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 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 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
syntax [Syntaxes]. [Syntaxes].
2.43 x500UniqueIdentifier Example: "36111222333444555".
The x500UniqueIdentifier attribute type contains binary strings that 2.43 'x500UniqueIdentifier'
are used to distinguish between objects when a distinguished name
has been reused. Each string is one value of this multi-valued The 'x500UniqueIdentifier' attribute type contains binary strings
attribute. In X.520 [X.520], this attribute type is called that are used to distinguish between objects when a distinguished
uniqueIdentifier. This is a different attribute type from both the name has been reused. Each string is one value of this multi-valued
"uid" and "uniqueIdentifier" LDAP attribute types. The attribute.
uniqueIdentifier attribute type is defined in [RFC1274]. In X.520 [X.520], this attribute type is called 'uniqueIdentifier'.
This is a different attribute type from both the 'uid' and
'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier'
attribute type is defined in [RFC1274].
(Source: X.520 [X.520])
( 2.5.4.45 NAME 'x500UniqueIdentifier' ( 2.5.4.45 NAME 'x500UniqueIdentifier'
EQUALITY bitStringMatch EQUALITY bitStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 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 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
syntax [Syntaxes]. [Syntaxes].
3. Object Classes 3. Object Classes
LDAP servers SHOULD recognize all the Object Classes listed here as LDAP servers SHOULD recognize all the Object Classes listed here as
values of the objectClass attribute (see [Models]). values of the 'objectClass' attribute (see [Models]).
3.1 applicationProcess 3.1 'applicationProcess'
The applicationProcess object class definition is the basis of an The 'applicationProcess' object class definition is the basis of an
entry which represents an application executing in a computer system. entry which represents an application executing in a computer system.
(Source: X.521 [X.521])
( 2.5.6.11 NAME 'applicationProcess' ( 2.5.6.11 NAME 'applicationProcess'
SUP top SUP top
STRUCTURAL STRUCTURAL
MUST cn MUST cn
MAY ( seeAlso $ MAY ( seeAlso $
ou $ ou $
l $ l $
description ) ) description ) )
3.2 country 3.2 'country'
The country object class definition is the basis of an entry which The 'country' object class definition is the basis of an entry which
represents a country. represents a country.
(Source: X.521 [X.521])
( 2.5.6.2 NAME 'country' ( 2.5.6.2 NAME 'country'
SUP top SUP top
STRUCTURAL STRUCTURAL
MUST c MUST c
MAY ( searchGuide $ MAY ( searchGuide $
description ) ) description ) )
3.3 device 3.3 'dcObject'
The device object class is the basis of an entry which represents an The 'dcObject' object class permits an entry to contains domain
appliance or computer or network element. component information. This object class is defined as auxiliary,
because it will be used in conjunction with an existing structural
object class.
(Source: RFC 2247 [RFC2247])
( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
SUP top
AUXILIARY
MUST dc )
3.4 'device'
The 'device' object class is the basis of an entry which represents
an appliance, computer or network element.
(Source: X.521 [X.521])
( 2.5.6.14 NAME 'device' ( 2.5.6.14 NAME 'device'
SUP top SUP top
STRUCTURAL STRUCTURAL
MUST cn MUST cn
MAY ( serialNumber $ MAY ( serialNumber $
seeAlso $ seeAlso $
owner $ owner $
ou $ ou $
o $ o $
l $ l $
description ) ) description ) )
3.4 groupOfNames 3.5 'groupOfNames'
The groupOfNames object class is the basis of an entry which The 'groupOfNames' object class is the basis of an entry which
represents a set of named objects including information related to represents a set of named objects including information related to
the purpose or maintenance of the set. the purpose or maintenance of the set.
(Source: X.521 [X.521])
( 2.5.6.9 NAME 'groupOfNames' ( 2.5.6.9 NAME 'groupOfNames'
SUP top SUP top
STRUCTURAL STRUCTURAL
MUST ( member $ MUST ( member $
cn ) cn )
MAY ( businessCategory $ MAY ( businessCategory $
seeAlso $ seeAlso $
owner $ owner $
ou $ ou $
o $ o $
description ) ) description ) )
3.5 groupOfUniqueNames 3.6 'groupOfUniqueNames'
The groupOfUniqueNames object class is the same as the groupOfNames The 'groupOfUniqueNames' object class is the same as the
object class except that the object names are not repeated or 'groupOfNames' object class except that the object names are not
reassigned within a set scope. repeated or reassigned within a set scope.
(Source: X.521 [X.521])
( 2.5.6.17 NAME 'groupOfUniqueNames' ( 2.5.6.17 NAME 'groupOfUniqueNames'
SUP top SUP top
STRUCTURAL STRUCTURAL
MUST ( uniqueMember $ MUST ( uniqueMember $
cn ) cn )
MAY ( businessCategory $ MAY ( businessCategory $
seeAlso $ seeAlso $
owner $ owner $
ou $ ou $
o $ o $
description ) ) description ) )
3.6 locality 3.7 'locality'
The locality object class is the basis of an entry which represents The 'locality' object class is the basis of an entry which represents
a place in the physical world. a place in the physical world.
(Source: X.521 [X.521])
( 2.5.6.3 NAME 'locality' ( 2.5.6.3 NAME 'locality'
SUP top SUP top
STRUCTURAL STRUCTURAL
MAY ( street $ MAY ( street $
seeAlso $ seeAlso $
searchGuide $ searchGuide $
st $ st $
l $ l $
description ) ) description ) )
3.7 organization 3.8 'organization'
The organization object class is the basis of an entry which The 'organization' object class is the basis of an entry which
represents a structured group of people. represents a structured group of people.
(Source: X.521 [X.521])
( 2.5.6.4 NAME 'organization' ( 2.5.6.4 NAME 'organization'
SUP top SUP top
STRUCTURAL STRUCTURAL
MUST o MUST o
MAY ( userPassword $ searchGuide $ seeAlso $ MAY ( userPassword $ searchGuide $ seeAlso $
businessCategory $ x121Address $ registeredAddress $ businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $ destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ telexNumber $ teletexTerminalIdentifier $
internationaliSDNNumber $ facsimileTelephoneNumber $ telephoneNumber $ internationaliSDNNumber $
street $ postOfficeBox $ postalCode $ facsimileTelephoneNumber $ street $ postOfficeBox $
postalAddress $ physicalDeliveryOfficeName $ st $ postalCode $ postalAddress $ physicalDeliveryOfficeName $
l $ description ) ) st $ l $ description ) )
3.8 organizationalPerson
The organizationalPerson object class is the basis of an entry which 3.9 'organizationalPerson'
represents a person in relation to an organization.
The 'organizationalPerson' object class is the basis of an entry
which represents a person in relation to an organization.
(Source: X.521 [X.521])
( 2.5.6.7 NAME 'organizationalPerson' ( 2.5.6.7 NAME 'organizationalPerson'
SUP person SUP person
STRUCTURAL STRUCTURAL
MAY ( title $ x121Address $ registeredAddress $ MAY ( title $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $ destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ telexNumber $ teletexTerminalIdentifier $
internationaliSDNNumber $ facsimileTelephoneNumber $ telephoneNumber $ internationaliSDNNumber $
street $ postOfficeBox $ postalCode $ postalAddress $ facsimileTelephoneNumber $ street $ postOfficeBox $
physicalDeliveryOfficeName $ ou $ st $ l ) ) postalCode $ postalAddress $ physicalDeliveryOfficeName $
ou $ st $ l ) )
3.9 organizationalRole 3.10 'organizationalRole'
The organizationalRole object class is the basis of an entry which The 'organizationalRole' object class is the basis of an entry which
represents a job or function or position in an organization. represents a job, function or position in an organization.
(Source: X.521 [X.521])
( 2.5.6.8 NAME 'organizationalRole' ( 2.5.6.8 NAME 'organizationalRole'
SUP top SUP top
STRUCTURAL STRUCTURAL
MUST cn MUST cn
MAY ( x121Address $ registeredAddress $ destinationIndicator $ MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $ teletexTerminalIdentifier $ telephoneNumber $
internationaliSDNNumber $ facsimileTelephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
seeAlso $ roleOccupant $ preferredDeliveryMethod $ seeAlso $ roleOccupant $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $ street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l $ description ) ) physicalDeliveryOfficeName $ ou $ st $ l $
description ) )
3.10 organizationalUnit 3.11 'organizationalUnit'
The organizationalUnit object class is the basis of an entry which The 'organizationalUnit' object class is the basis of an entry which
represents a piece of an organization. represents a piece of an organization.
(Source: X.521 [X.521])
( 2.5.6.5 NAME 'organizationalUnit' ( 2.5.6.5 NAME 'organizationalUnit'
SUP top SUP top
STRUCTURAL STRUCTURAL
MUST ou MUST ou
MAY ( businessCategory $ description $ destinationIndicator $ MAY ( businessCategory $ description $ destinationIndicator $
facsimileTelephoneNumber $ internationaliSDNNumber $ l $ facsimileTelephoneNumber $ internationaliSDNNumber $ l $
physicalDeliveryOfficeName $ postalAddress $ postalCode $ physicalDeliveryOfficeName $ postalAddress $ postalCode $
postOfficeBox $ preferredDeliveryMethod $ postOfficeBox $ preferredDeliveryMethod $
registeredAddress $ searchGuide $ seeAlso $ st $ street $ registeredAddress $ searchGuide $ seeAlso $ st $ street $
telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ telephoneNumber $ teletexTerminalIdentifier $
userPassword $ x121Address ) ) telexNumber $ userPassword $ x121Address ) )
3.11 person 3.12 'person'
The person object class is the basis of an entry which represents a The 'person' object class is the basis of an entry which represents a
human being. human being.
(Source: X.521 [X.521])
( 2.5.6.6 NAME 'person' ( 2.5.6.6 NAME 'person'
SUP top SUP top
STRUCTURAL STRUCTURAL
MUST ( sn $ MUST ( sn $
cn ) cn )
MAY ( userPassword $ MAY ( userPassword $
telephoneNumber $ telephoneNumber $
seeAlso $ description ) ) seeAlso $ description ) )
3.12 residentialPerson 3.13 'residentialPerson'
The residentialPerson object class is the basis of an entry which The 'residentialPerson' object class is the basis of an entry which
includes a person's residence in the representation of the person. includes a person's residence in the representation of the person.
(Source: X.521 [X.521])
( 2.5.6.10 NAME 'residentialPerson' ( 2.5.6.10 NAME 'residentialPerson'
SUP person SUP person
STRUCTURAL STRUCTURAL
MUST l MUST l
MAY ( businessCategory $ x121Address $ registeredAddress $ MAY ( businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $ destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ telexNumber $ teletexTerminalIdentifier $
internationaliSDNNumber $ facsimileTelephoneNumber $ telephoneNumber $ internationaliSDNNumber $
preferredDeliveryMethod $ street $ postOfficeBox $ facsimileTelephoneNumber $ preferredDeliveryMethod $
postalCode $ postalAddress $ physicalDeliveryOfficeName $ street $ postOfficeBox $ postalCode $ postalAddress $
st $ l ) ) physicalDeliveryOfficeName $ st $ l ) )
3.14 'uidObject'
The 'uidObject' object class permits an entry to contains user
identification information. This object class is defined as
auxiliary, because it will be used in conjunction with an existing
structural object class.
(Source: RFC 2377 [RFC2377])
( 1.3.6.1.1.3.1 NAME 'uidObject'
SUP top
AUXILIARY
MUST uid )
4. IANA Considerations 4. IANA Considerations
It is requested that the Internet Assigned Numbers Authority (IANA) It is requested that the Internet Assigned Numbers Authority (IANA)
update the LDAP descriptors registry as indicated in the following update the LDAP descriptors registry as indicated in the following
template: template:
Subject: Request for LDAP Descriptor Registration Update Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment Descriptor (short name): see comment
Object Identifier: see comment Object Identifier: see comment
Person & email address to contact for further information: Person & email address to contact for further information:
Kathy Dally <kdally@mitre.org> Andrew Sciberras <andrew.sciberras@eb2bcom.com>
Usage: (A = attribute type, O = Object Class) see comment Usage: (A = attribute type, O = Object Class) see comment
Specification: RFC XXXX [editor's note: The RFC number will be Specification: RFC XXXX [editor's note: The RFC number will be
the one assigned to this document.] the one assigned to this document.]
Author/Change Controller: IESG Author/Change Controller: IESG
Comments Comments
In the LDAP descriptors registry, the following descriptors (short In the LDAP descriptors registry, the following descriptors (short
names) should be updated to refer to RFC XXXX [editor's note: This names) should be updated to refer to RFC XXXX [editor's note: This
document]. document]. Names that need to be reserved, rather than assigned to
an Object Identifier, will contain an Object Identifier value of
RESERVED.
NAME Type OID NAME Type OID
------------------------ ---- ---------------------------- ------------------------ ---- ----------------------------
applicationProcess O 2.5.6.11 applicationProcess O 2.5.6.11
businessCategory A 2.5.4.15 businessCategory A 2.5.4.15
c A 2.5.4.6 c A 2.5.4.6
cn A 2.5.4.3 cn A 2.5.4.3
commonName A 2.5.4.3
country O 2.5.6.2 country O 2.5.6.2
dc A 0.9.2342.19200300.100.1.25 countryName A 2.5.4.6
DC A 0.9.2342.19200300.100.1.25
dcObject O 1.3.6.1.4.1.1466.344
description A 2.5.4.13 description A 2.5.4.13
destinationIndicator A 2.5.4.27 destinationIndicator A 2.5.4.27
device O 2.5.6.14 device O 2.5.6.14
distinguishedName A 2.5.4.49 distinguishedName A 2.5.4.49
dnQualifier A 2.5.4.46 dnQualifier A 2.5.4.46
domainComponent A 0.9.2342.19200300.100.1.25
enhancedSearchGuide A 2.5.4.47 enhancedSearchGuide A 2.5.4.47
facsimileTelephoneNumber A 2.5.4.23 facsimileTelephoneNumber A 2.5.4.23
generationQualifier A 2.5.4.44 generationQualifier A 2.5.4.44
givenName A 2.5.4.42 givenName A 2.5.4.42
GN A RESERVED
groupOfNames O 2.5.6.9 groupOfNames O 2.5.6.9
groupOfUniqueNames O 2.5.6.17 groupOfUniqueNames O 2.5.6.17
houseIdentifier A 2.5.4.51 houseIdentifier A 2.5.4.51
initials A 2.5.4.43 initials A 2.5.4.43
internationalISDNNumber A 2.5.4.25 internationalISDNNumber A 2.5.4.25
l A 2.5.4.7 L A 2.5.4.7
locality O 2.5.6.3 locality O 2.5.6.3
localityName A 2.5.4.7
member A 2.5.4.31 member A 2.5.4.31
name A 2.5.4.41 name A 2.5.4.41
o A 2.5.4.10 o A 2.5.4.10
organization O 2.5.6.4 organization O 2.5.6.4
organizationName A 2.5.4.10
organizationalPerson O 2.5.6.7 organizationalPerson O 2.5.6.7
organizationalRole O 2.5.6.8 organizationalRole O 2.5.6.8
organizationalUnit O 2.5.6.5 organizationalUnit O 2.5.6.5
organizationalUnitName A 2.5.4.11
ou A 2.5.4.11 ou A 2.5.4.11
owner A 2.5.4.32 owner A 2.5.4.32
person O 2.5.6.6 person O 2.5.6.6
physicalDeliveryOfficeName A 2.5.4.19 physicalDeliveryOfficeName A 2.5.4.19
postalAddress A 2.5.4.16 postalAddress A 2.5.4.16
postalCode A 2.5.4.17 postalCode A 2.5.4.17
postOfficeBox A 2.5.4.18 postOfficeBox A 2.5.4.18
preferredDeliveryMethod A 2.5.4.28 preferredDeliveryMethod A 2.5.4.28
registeredAddress A 2.5.4.26 registeredAddress A 2.5.4.26
residentialPerson O 2.5.6.10 residentialPerson O 2.5.6.10
roleOccupant A 2.5.4.33 roleOccupant A 2.5.4.33
searchGuide A 2.5.4.14 searchGuide A 2.5.4.14
seeAlso A 2.5.4.34 seeAlso A 2.5.4.34
serialNumber A 2.5.4.5 serialNumber A 2.5.4.5
sn A 2.5.4.4 sn A 2.5.4.4
st A 2.5.4.8 st A 2.5.4.8
street A 2.5.4.9 street A 2.5.4.9
skipping to change at page 23, line 24 skipping to change at page 28, line 36
preferredDeliveryMethod A 2.5.4.28 preferredDeliveryMethod A 2.5.4.28
registeredAddress A 2.5.4.26 registeredAddress A 2.5.4.26
residentialPerson O 2.5.6.10 residentialPerson O 2.5.6.10
roleOccupant A 2.5.4.33 roleOccupant A 2.5.4.33
searchGuide A 2.5.4.14 searchGuide A 2.5.4.14
seeAlso A 2.5.4.34 seeAlso A 2.5.4.34
serialNumber A 2.5.4.5 serialNumber A 2.5.4.5
sn A 2.5.4.4 sn A 2.5.4.4
st A 2.5.4.8 st A 2.5.4.8
street A 2.5.4.9 street A 2.5.4.9
surname A 2.5.4.4
telephoneNumber A 2.5.4.20 telephoneNumber A 2.5.4.20
teletexTerminalIdentifier A 2.5.4.22 teletexTerminalIdentifier A 2.5.4.22
telexNumber A 2.5.4.21 telexNumber A 2.5.4.21
title A 2.5.4.12 title A 2.5.4.12
uid A 0.9.2342.19200300.100.1.1 uid A 0.9.2342.19200300.100.1.1
uidObject O 1.3.6.1.1.3.1
uniqueMember A 2.5.4.50 uniqueMember A 2.5.4.50
userId A 0.9.2342.19200300.100.1.1
userPassword A 2.5.4.35 userPassword A 2.5.4.35
x121Address A 2.5.4.24 x121Address A 2.5.4.24
x500UniqueIdentifier A 2.5.4.45 x500UniqueIdentifier A 2.5.4.45
5. Security Considerations 5. Security Considerations
Attributes of directory entries are used to provide descriptive Attributes of directory entries are used to provide descriptive
information about the real-world objects they represent, which can be information about the real-world objects they represent, which can be
people, organizations or devices. Most countries have privacy laws people, organizations or devices. Most countries have privacy laws
regarding the publication of information about people. regarding the publication of information about people.
Transfer of cleartext passwords is strongly discouraged where the Transfer of cleartext passwords is strongly discouraged where the
underlying transport service cannot guarantee confidentiality and may underlying transport service cannot guarantee confidentiality and may
result in disclosure of the password to unauthorized parties. result in disclosure of the password to unauthorized parties.
Multiple attribute values for the userPassword needs to be used with Multiple attribute values for the 'userPassword' needs to be used
care. Especially reset/deletion of a password by an admin without with care. Especially reset/deletion of a password by an admin
knowing the old user password gets tricky or impossible if multiple without knowing the old user password gets tricky or impossible if
values for different applications are present. multiple values for different applications are present.
Certainly, applications which intend to replace the userPassword Certainly, applications which intend to replace the 'userPassword'
value(s) with new value(s) should use modify/replaceValues (or value(s) with new value(s) should use modify/replaceValues (or
modify/deleteAttribute+addAttribute). Additionally, server modify/deleteAttribute+addAttribute). Additionally, server
implementations are encouraged to provide administrative controls implementations are encouraged to provide administrative controls
which, if enabled, restrict the userPassword attributer to one value. which, if enabled, restrict the 'userPassword' attributer to one
value.
Note that when used for authentication purposes [AuthMeth], the user Note that when used for authentication purposes [AuthMeth], the user
need only prove knowledge of one of the values, not all of need only prove knowledge of one of the values, not all of the
the values. values.
6. Acknowledgements 6. Acknowledgements
The definitions, on which this document is based, have been developed The definitions, on which this document is based, have been developed
by committees for telecommunications and international standards. by committees for telecommunications and international standards.
This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a
product of the IETF ASID Working Group. product of the IETF ASID Working Group.
The dc attribute type definition in this document supercedes the The 'dc' attribute type definition and the 'dcObject' object class
specification in RFC 2247 by S. Kille, M. Wahl, A. Grimstad, definition in this document supersede the specification in RFC 2247
R. Huber, and S. Sataluri. by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.
The uid attribute type definition in this document supercedes the The 'uid' attribute type definition in this document supersedes the
specification of the userid in RFC 1274 by P. Barker and S. Kille specification of the 'userid' in RFC 1274 by P. Barker and S. Kille
and of the uid in RFC 2798 by M. Smith. and of the uid in RFC 2798 by M. Smith.
The 'uidObject' object class definition in this document supersedes
the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
Huber, S, Sataluri and M. Smith.
This document is based upon input of the IETF LDAPBIS working group. This document is based upon input of the IETF LDAPBIS working group.
The author wishes to thank S. Legg and K. Zeilenga for their The author wishes to thank S. Legg and K. Zeilenga for their
significant contribution to this update. significant contribution to this update. The author would also like
to thank Kathy Dally who edited early drafts of this document.
7. References 7. References
7.1 Normative 7.1 Normative
[E.123] Notation for national and international telephone numbers, [E.123] Notation for national and international telephone
ITU-T Recommendation E.123, 1988 numbers, ITU-T Recommendation E.123, 1988
[E.164] The international public telecommunication numbering plan, [E.164] The international public telecommunication numbering
ITU-T Recommendation E.164, 1997 plan, ITU-T Recommendation E.164, 1997
[F.1] Operational Provisions For The International Public
Telegram Service Transmission System, CCITT
Recommendation F.1, 1992
[F.31] Telegram Retransmission System, CCITT Recommendation
F.31, 1988
[ISO3166] ISO 3166, "Codes for the representation of names of [ISO3166] ISO 3166, "Codes for the representation of names of
countries". countries".
[Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis- [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
models-xx (a work in progress) models-xx (a work in progress)
[RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
FACILITIES", RFC 1034, January 1987 FACILITIES", RFC 1034, January 1987
skipping to change at page 25, line 4 skipping to change at page 30, line 33
countries". countries".
[Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis- [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
models-xx (a work in progress) models-xx (a work in progress)
[RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
FACILITIES", RFC 1034, January 1987 FACILITIES", RFC 1034, January 1987
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997 Requirement Levels", RFC 2119, March 1997
[RFC2234] Crocker, D., Overell P., "Augmented BNF for Syntax [RFC2234] Crocker, D., Overell P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997 Specifications: ABNF", RFC 2234, November 1997
[RFC3490] Faltstrom P., Hoffman P., Costello A., [RFC3490] Faltstrom P., Hoffman P., Costello A.,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications
RFC 3490, March 2003 (IDNA)", RFC 3490, March 2003
[ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map", [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road
draft-ietf-ldapbis-roadmap-xx (a work in progress) Map", draft-ietf-ldapbis-roadmap-xx (a work in
progress)
[SASLprep] Zeilenga K., "SASLprep: Stringprep profile for user
names and passwords", draft-ietf-sasl-saslprep-xx (a
work in progress)
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis- [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
syntaxes-xx (a work in progress) syntaxes-xx (a work in progress)
[X.121] International numbering plan for public data networks, [X.121] International numbering plan for public data networks,
ITU-T Recommendation X.121, 1996 ITU-T Recommendation X.121, 1996
[X.509] The Directory: Authentication Framework, ITU-T [X.509] The Directory: Authentication Framework, ITU-T
Recommendation X.509, 1993 Recommendation X.509, 1993
[X.520] The Directory: Selected Attribute Types, ITU-T [X.520] The Directory: Selected Attribute Types, ITU-T
Recommendation X.520, 1993 Recommendation X.520, 1993
[X.521] The Directory: Selected Object Classes. ITU-T [X.521] The Directory: Selected Object Classes. ITU-T
Recommendation X.521, 1993 Recommendation X.521, 1993
7.2 Informative 7.2 Informative
[AUTHMETH] Harrison R., "LDAP: Authentication Methods and [AuthMeth] Harrison R., "LDAP: Authentication Methods and
Connection Level Security Mechanisms", draft-ietf- Connection Level Security Mechanisms", draft-ietf-
ldapbis-authmeth-xx (a work in progress) ldapbis-authmeth-xx (a work in progress)
[F.1] Operational Provisions For The International Public Telegram [LDAP-PKI] Zeilenga, K., "Lightweight Directory Access Protocol
Service Transmission System, CCITT Recommmendation F.1, 1992 (LDAP) schema definitions for X.509 Certificates",
draft-zeilenga-ldap-x509-xx (a work in progress)
[F.31] Telegram Retransmission System, CCITT Recommendation
F.31, 1988
[LDAP-CERT] Klasen, N., Gietz, P. "An LDAPv3 Schema for X.509
Certificates", Internet Draft draft-klasen-ldap-
x509certificate-schema-xx (a work in progress)
[LDAP-CRL] Chadwick, D. W. and M. V. Sahalayev, "Internet X.509
Public Key Infrastructure - LDAP Schema for X.509 CRLs",
Internet Draft draft-ietf-pkix-ldap-crl-schema-xx (a
work in progress)
[RFC1274] Barker, P, Kille, S.,"The COSINE and Internet X.500 [RFC1274] Barker, P., Kille, S.,"The COSINE and Internet X.500
Schema", RFC 1274, November 1991 Schema", RFC 1274, November 1991
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and
Sataluri, S., "Using Domains in LDAP/X.500 Distinguished Sataluri, S., "Using Domains in LDAP/X.500
Names", RFC 2247, January 1998 Distinguished Names", RFC 2247, January 1998
[RFC2377] Grimstad, A., Huber, R., Sataluri, S., and Wahl, M.,
"Naming Plan for Internet-Enabled Applications", RFC
2377, September 1998.
[RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
Class", RFC 2798, April 2000 Class", RFC 2798, April 2000
[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 [X.500] The Directory, ITU-T Recommendations X.501-X.525, 1993
8. Author's Address 8. Author's Address
Kathy Dally Andrew Sciberras
The MITRE Corp. eB2Bcom
7515 Colshire Dr., H300 Suite 3, Woodhouse Corporate Centre,
McLean VA 22102 935 Station Street,
USA Box Hill North, Victoria 3129
AUSTRALIA
Phone: +1 703 883 6058
Email: kdally@mitre.org
9. Intellectual Property Rights (IPR) Disclosure
By submitting this Internet-Draft, I certify that any applicable Phone: +61 3 9896 7833
patent or other IPR claims of which I am aware have been disclosed, Email: andrew.sciberras@eb2bcom.com
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
10. IPR Notice 9. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology pertain to the implementation or use of the technology described in
described in this document or the extent to which any license this document or the extent to which any license under such rights
under such rights might or might not be available; nor does it might or might not be available; nor does it represent that it has
represent that it has made any independent effort to identify any made any independent effort to identify any such rights. Information
such rights. Information on the procedures with respect to rights on the procedures with respect to rights in RFC documents can be
in RFC documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or otherproprietary copyrights, patents or patent applications, or otherproprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at: this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
11. Copyright Notice and Disclaimer 10. Disclaimer of Validity
Copyright (C) The Internet Society (2004). This document is This document and the information contained herein are provided on an
subject to the rights, licenses and restrictions contained in BCP "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
78, and except as set forth therein, the authors retain all their OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
rights. 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.
This document and the information contained herein are provided on Copyright Statement Copyright (C) The Internet Society (2005). This
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE document is subject to the rights, licenses and restrictions
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND contained in BCP 78, and except as set forth therein, the authors
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, retain all their rights.
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.
Appendix A Changes Made Since RFC 2256 Appendix A Changes Made Since RFC 2256
This appendix lists the changes that have been made from RFC 2256 to This appendix lists the changes that have been made from RFC 2256 to
this I-D. this I-D.
This appendix is not a normative part of this specification, which
has been provided for informational purposes only.
1. Replaced the document title. 1. Replaced the document title.
2. Removed the IESG Note. 2. Removed the IESG Note.
3. Dependencies on RFC 1274 have been eliminated. 3. Dependencies on RFC 1274 have been eliminated.
4. Added a Security Considerations section and an IANA 4. Added a Security Considerations section and an IANA
considerations section. considerations section.
5. Deleted the conformance requirement for subschema object 5. Deleted the conformance requirement for subschema object
classes in favor of a statement in [Syntaxes]. classes in favor of a statement in [Syntaxes].
6. Added explanation to attribute types and to each object class. 6. Added explanation to attribute types and to each object class.
7. Removed Section 4, Syntaxes, and Section 6, Matching Rules, 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
(moved to [Syntaxes]). (moved to [Syntaxes]).
8. Removed the certificate-related attribute types: 8. Removed the certificate-related attribute types:
authorityRevocationList, authorityRevocationList, cACertificate,
cACertificate, certificateRevocationList, crossCertificatePair,
certificateRevocationList, deltaRevocationList, supportedAlgorithms, and userCertificate.
crossCertificatePair,
deltaRevocationList,
supportedAlgorithms, and
userCertificate.
Removed the certificate-related Object Classes: Removed the certificate-related Object Classes:
certificationAuthority, certificationAuthority, certificationAuthority-V2,
certificationAuthority-V2, cRLDistributionPoint, strongAuthenticationUser, and
cRLDistributionPoint,
strongAuthenticationUser, and
userSecurityInformation userSecurityInformation
LDAP PKI is now discussed in [LDAP-CRL] and {LDAP-CERT]. LDAP PKI is now discussed in [LDAP-CRL] and [LDAP-CERT].
9. Removed the dmdName, knowledgeInformation, 9. Removed the dmdName, knowledgeInformation,
presentationAddress, protocolInformation, and presentationAddress, protocolInformation, and
supportedApplicationContext attribute types and the dmd, supportedApplicationContext attribute types and the dmd,
applicationEntity, and dSA object classes. applicationEntity, and dSA object classes.
10. Deleted the aliasedObjectName and objectClass attribute 10. Deleted the aliasedObjectName and objectClass attribute type
type definitions. Deleted the alias and top object class definitions. Deleted the alias and top object class
definitions. They are included in [Models]. definitions. They are included in [Models].
11. Added the 'dc' attribute type from RFC 2247. 11. Added the 'dc' attribute type from RFC 2247.
12. Numerous edititorial changes. 12. Numerous edititorial changes.
13. Removed upper bound after the SYNTAX oid in all attribute 13. Removed upper bound after the SYNTAX oid in all attribute
definitions where it appeared. definitions where it appeared.
14. Added text about Unicode, SASLprep and UTF-8 for userPassword. 14. Added text about Unicode, SASLprep and UTF-8 for userPassword.
skipping to change at line 1365 skipping to change at page 34, line 29
17. Added RFC 2234 to normative references. 17. Added RFC 2234 to normative references.
18. Added RFC 1274 and RFC 2798 to informative references. 18. Added RFC 1274 and RFC 2798 to informative references.
19. Removed the statement about RFC 2026 conformance. 19. Removed the statement about RFC 2026 conformance.
20. Added the IPR Disclosure and Notice 20. Added the IPR Disclosure and Notice
21. Updated the Copyright text. 21. Updated the Copyright text.
changes since 08:
22. Included RFC 2377 into Updates header and Informative
References
23. Changed Editor information to Andrew Sciberras.
24. Updated I-D Template information.
25. References made consistent with other LDAPbis ID's. [ROADMAP]
-> [RoadMap] and [AUTHMETH] -> [AuthMeth].
26. Changed Introduction to include an (LDAP) acronym after the
first usage.
27. Renamed section 1.1 to "Relationship with other
specifications" from "Situation".
28. Included definitions, comments and references for 'dcObject'
and 'uidObject'.
29. Replaced PKI schema references to use draft-zeilenga-ldap-
x509-xx
30. Spelt out and referenced ABNF on first usage.
31. Removed Section 2.4 (Source). Replaced the source table with
explicit references for each definition.
32. All references to an attribute type or object class are
enclosed in single quotes.
33. The layout of attribute type definitions has been changed to
provide consistency throughout the document:
> Section Heading
> Description of Attribute type
> Multivalued description
> Source Information
> Definition
> Example
> Additional Comments
Adding this consistent output included the addition of
examples to some definitions.
34. References to alternate names for attributes types are
provided with a reference to where they were originally
specified.
35. Clarification of the description of 'distinguishedName' and
'name', in regards to these attribute types being supertypes.
36. Spelt out ISDN on first usage.
37. Inserted a reference to [Syntaxes] for the
'teletexTerminalIdentifier' definition's SYNTAX OID.
38. Additional names were added to the IANA Considerations. Names
include 'commonName', 'dcObject', 'domainComponent', 'GN',
'localityName', 'organizationName', 'organizationUnitName',
'surname', 'uidObject' and 'userid'.
39. Renamed all instances of supercede to supersede.
40. Moved [F.1], [F.30] and [SASLprep] from informative to
normative references.
41. Changed the 'c' definition to be consistent with X.500.
42. Added text to 'dc', making the distinction between 'stored'
and 'query' values when preparing IDN strings.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/