draft-ietf-ldapbis-user-schema-11.txt   rfc4519.txt 
INTERNET-DRAFT Editor: A. Sciberras Network Working Group A. Sciberras, Ed.
Intended Category: Standard Track eB2Bcom Request for Comments: 4519 eB2Bcom
Updates: RFC 2247, RFC 2798, RFC 2377 January 30, 2006 Obsoletes: 2256 June 2006
Obsoletes: RFC 2256 Updates: 2247, 2798, 2377
Category: Standards Track
LDAP: Schema for User Applications
draft-ietf-ldapbis-user-schema-11.txt
Copyright (C) The Internet Society (2006). All Rights Reserved.
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, I accept the provisions of Section
3 of BCP 78.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Lightweight Directory Access Protocol (LDAP):
and may be updated, replaced, or obsoleted by other documents at any Schema for User Applications
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at Status of This Memo
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
This document is intended to be, after appropriate review and Copyright Notice
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this document is unlimited. Technical discussion of
this document should 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 30 July 2006. Copyright (C) The Internet Society (2006).
Abstract Abstract
This document is an 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. It provides a technical
technical specification of attribute types and object classes specification of attribute types and object classes intended for use
intended for use by LDAP directory clients for many directory by LDAP directory clients for many directory services, such as White
services, such as, White Pages. These objects are widely used as a Pages. These objects are widely used as a basis for the schema in
basis for the schema in many LDAP directories. This document does many LDAP directories. This document does not cover attributes used
not cover attributes used for the administration of directory for the administration of directory servers, nor does it include
servers, nor does it include directory objects defined for specific directory objects defined for specific uses in other documents.
uses in other documents.
Table of Contents Table of Contents
Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction ....................................................3
Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1. Relationship with Other Specifications .....................3
Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Conventions ................................................4
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. General Issues .............................................4
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Attribute Types .................................................4
1.1 Relationship with other specifications . . . . . . . . . 5 2.1. 'businessCategory' .........................................5
1.2 Conventions. . . . . . . . . . . . . . . . . . . . . . . 5 2.2. 'c' ........................................................5
1.3 General Issues . . . . . . . . . . . . . . . . . . . . . 5 2.3. 'cn' .......................................................5
2.4. 'dc' .......................................................6
2. Attribute Types . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. 'description' ..............................................6
2.1 'businessCategory' . . . . . . . . . . . . . . . . . . . 6 2.6. 'destinationIndicator' .....................................7
2.2 'c'. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.7. 'distinguishedName' ........................................7
2.3 'cn' . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.8. 'dnQualifier' ..............................................8
2.4 'dc' . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.9. 'enhancedSearchGuide' ......................................8
2.5 'description'. . . . . . . . . . . . . . . . . . . . . . 8 2.10. 'facsimileTelephoneNumber' ................................9
2.6 'destinationIndicator' . . . . . . . . . . . . . . . . . 8 2.11. 'generationQualifier' .....................................9
2.7 'distinguishedName'. . . . . . . . . . . . . . . . . . . 8 2.12. 'givenName' ...............................................9
2.8 'dnQualifier'. . . . . . . . . . . . . . . . . . . . . . 9 2.13. 'houseIdentifier' .........................................9
2.9 'enhancedSearchGuide'. . . . . . . . . . . . . . . . . . 9 2.14. 'initials' ...............................................10
2.10 'facsimileTelephoneNumber' . . . . . . . . . . . . . . . 10 2.15. 'internationalISDNNumber' ................................10
2.11 'generationQualifier'. . . . . . . . . . . . . . . . . . 10 2.16. 'l' ......................................................10
2.12 'givenName'. . . . . . . . . . . . . . . . . . . . . . . 10 2.17. 'member' .................................................11
2.13 'houseIdentifier'. . . . . . . . . . . . . . . . . . . . 11 2.18. 'name' ...................................................11
2.14 'initials' . . . . . . . . . . . . . . . . . . . . . . . 11 2.19. 'o' ......................................................11
2.15 'internationalISDNNumber'. . . . . . . . . . . . . . . . 11 2.20. 'ou' .....................................................12
2.16 'l'. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.21. 'owner' ..................................................12
2.17 'member' . . . . . . . . . . . . . . . . . . . . . . . . 12 2.22. 'physicalDeliveryOfficeName' .............................12
2.18 'name' . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.23. 'postalAddress' ..........................................13
2.19 'o'. . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.24. 'postalCode' .............................................13
2.20 'ou' . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.25. 'postOfficeBox' ..........................................14
2.21 'owner'. . . . . . . . . . . . . . . . . . . . . . . . . 13 2.26. 'preferredDeliveryMethod' ................................14
2.22 'physicalDeliveryOfficeName' . . . . . . . . . . . . . . 13 2.27. 'registeredAddress' ......................................14
2.23 'postalAddress'. . . . . . . . . . . . . . . . . . . . . 14 2.28. 'roleOccupant' ...........................................15
2.24 'postalCode' . . . . . . . . . . . . . . . . . . . . . . 14 2.29. 'searchGuide' ............................................15
2.25 'postOfficeBox'. . . . . . . . . . . . . . . . . . . . . 14 2.30. 'seeAlso' ................................................15
2.26 'preferredDeliveryMethod'. . . . . . . . . . . . . . . . 15 2.31. 'serialNumber' ...........................................16
2.27 'registeredAddress'. . . . . . . . . . . . . . . . . . . 15 2.32. 'sn' .....................................................16
2.28 'roleOccupant' . . . . . . . . . . . . . . . . . . . . . 16 2.33. 'st' .....................................................16
2.29 'searchGuide'. . . . . . . . . . . . . . . . . . . . . . 16 2.34. 'street' .................................................17
2.30 'seeAlso'. . . . . . . . . . . . . . . . . . . . . . . . 16 2.35. 'telephoneNumber' ........................................17
2.31 'serialNumber' . . . . . . . . . . . . . . . . . . . . . 17 2.36. 'teletexTerminalIdentifier' ..............................17
2.32 'sn' . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.37. 'telexNumber' ............................................18
2.33 'st' . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.38. 'title' ..................................................18
2.34 'street' . . . . . . . . . . . . . . . . . . . . . . . . 18 2.39. 'uid' ....................................................18
2.35 'telephoneNumber'. . . . . . . . . . . . . . . . . . . . 18 2.40. 'uniqueMember' ...........................................19
2.36 'teletexTerminalIdentifier'. . . . . . . . . . . . . . . 18 2.41. 'userPassword' ...........................................19
2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . . 19 2.42. 'x121Address' ............................................20
2.38 'title'. . . . . . . . . . . . . . . . . . . . . . . . . 19 2.43. 'x500UniqueIdentifier' ...................................20
2.39 'uid'. . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Object Classes .................................................20
2.40 'uniqueMember' . . . . . . . . . . . . . . . . . . . . . 19 3.1. 'applicationProcess' ......................................21
2.41 'userPassword' . . . . . . . . . . . . . . . . . . . . . 20 3.2. 'country' .................................................21
2.42 'x121Address'. . . . . . . . . . . . . . . . . . . . . . 21 3.3. 'dcObject' ................................................21
2.43 'x500UniqueIdentifier' . . . . . . . . . . . . . . . . . 21 3.4. 'device' ..................................................21
3.5. 'groupOfNames' ............................................22
3. Object Classes. . . . . . . . . . . . . . . . . . . . . . . . 22 3.6. 'groupOfUniqueNames' ......................................22
3.1 'applicationProcess' . . . . . . . . . . . . . . . . . . 22 3.7. 'locality' ................................................23
3.2 'country'. . . . . . . . . . . . . . . . . . . . . . . . 22 3.8. 'organization' ............................................23
3.3 'dcObject' . . . . . . . . . . . . . . . . . . . . . . . 22 3.9. 'organizationalPerson' ....................................24
3.4 'device' . . . . . . . . . . . . . . . . . . . . . . . . 23 3.10. 'organizationalRole' .....................................24
3.5 'groupOfNames' . . . . . . . . . . . . . . . . . . . . . 23 3.11. 'organizationalUnit' .....................................24
3.6 'groupOfUniqueNames' . . . . . . . . . . . . . . . . . . 23 3.12. 'person' .................................................25
3.7 'locality' . . . . . . . . . . . . . . . . . . . . . . . 24 3.13. 'residentialPerson' ......................................25
3.8 'organization' . . . . . . . . . . . . . . . . . . . . . 24 3.14. 'uidObject' ..............................................26
3.9 'organizationalPerson' . . . . . . . . . . . . . . . . . 24 4. IANA Considerations ............................................26
3.10 'organizationalRole' . . . . . . . . . . . . . . . . . . 25 5. Security Considerations ........................................28
3.11 'organizationalUnit' . . . . . . . . . . . . . . . . . . 25 6. Acknowledgements ...............................................28
3.12 'person' . . . . . . . . . . . . . . . . . . . . . . . . 26 7. References .....................................................29
3.13 'residentialPerson'. . . . . . . . . . . . . . . . . . . 26 7.1. Normative References ......................................29
3.14 'uidObject'. . . . . . . . . . . . . . . . . . . . . . . 26 7.2. Informative References ....................................30
Appendix A Changes Made Since RFC 2256 ...........................32
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 29
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1 Normative. . . . . . . . . . . . . . . . . . . . . . . . 30
7.2 Informative. . . . . . . . . . . . . . . . . . . . . . . 31
8. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 31
9. Intellectual Property Statement . . . . . . . . . . . . . . . 32
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 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
(LDAP) directory clients for many directory services, such as, White (LDAP) directory clients for many directory services, such as White
Pages. Originally specified in the X.500 [X.500] documents, these Pages. Originally specified in the X.500 [X.500] documents, these
objects are widely used as a basis for the schema in many LDAP objects are widely used as a basis for the schema in many LDAP
directories. This document does not cover attributes used for the directories. This document does not cover attributes used for the
administration of directory servers, nor does it include directory administration of directory servers, nor does it include directory
objects defined for specific uses in other documents. objects defined for specific uses in other documents.
1.1 Relationship with other specifications 1.1. Relationship with Other Specifications
This document is an 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 [RFC4510], which obsoletes the previously defined LDAP technical
specification, RFC 3377, 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 [RFC4517]. 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 [RFC4512]. The
remainder of RFC 2256 is obsoleted by this document. Section 2.4 of remainder of RFC 2256 is obsoleted by this document. The technical
this document supersedes the technical specification for the 'dc' specification for the 'dc' attribute type and 'dcObject' object class
attribute type and 'dcObject' object class found in RFC 2247. The found in RFC 2247 are superseded by sections 2.4 and 3.3 of this
remainder of RFC 2247 remains in force. document. The 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 This document updates RFC 2377 by replacing the informative
description of the 'uidObject' object class with the definitive
description provided in Section 3.14 of this document.
A number of schema elements that 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-PKI]. Unless reintroduced in future technical specifications, [RFC4523]. Unless reintroduced in future technical 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 The descriptions in this document SHALL be considered definitive for
use in LDAP. 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 defined in Section 3 of [Syntaxes] This document references Syntaxes defined in Section 3 of [RFC4517]
and Matching Rules defined in Section 4 of [Syntaxes]. and Matching Rules defined in Section 4 of [RFC4517].
The definitions of Attribute Types and Object Classes are written The definitions of Attribute Types and Object Classes are written
using the Augmented Backus-Naur Form (ABNF) [RFC4234] of using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
AttributeTypeDescription and ObjectClassDescription given in AttributeTypeDescription and ObjectClassDescription given in
[Models]. Lines have been folded for readability. When such values [RFC4512]. Lines have been folded for readability. When such values
are transferred as attribute values in the LDAP Protocol the values are transferred as attribute values in the LDAP Protocol, the values
will not contain line breaks. will not contain line breaks.
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 'searchGuide' and There is no requirement that servers implement the 'searchGuide' and
'teletexTerminalIdentifier' attribute types. In fact, their use is 'teletexTerminalIdentifier' attribute types. In fact, their use is
greatly discouraged. 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. Each kind is one value of this performed by an organization. Each kind is one value of this
multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes]. [RFC4517].
Examples: "banking", "transportation" and "real estate". Examples: "banking", "transportation", and "real estate".
2.2 'c' 2.2. 'c'
The 'c' ('countryName' in X.500) attribute type contains a two-letter The 'c' ('countryName' in X.500) attribute type contains a two-letter
ISO 3166 [ISO3166] country code. ISO 3166 [ISO3166] country code.
(Source: X.520 [X.520]) (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 SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
SINGLE-VALUE ) SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
[Syntaxes]. [RFC4517].
Examples: "DE", "AU" and "FR". Examples: "DE", "AU" and "FR".
2.3 'cn' 2.3. 'cn'
The 'cn' ('commonName' in X.500) attribute type contains names of an The 'cn' ('commonName' in X.500) attribute type contains names of an
object. Each name is one value of this multi-valued attribute. If 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 the object corresponds to a person, it is typically the person's full
name. name.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.3 NAME 'cn' ( 2.5.4.3 NAME 'cn'
SUP name ) SUP name )
Examples: "Martin K Smith", "Marty Smith" and "printer12". Examples: "Martin K Smith", "Marty Smith" and "printer12".
2.4 'dc' 2.4. 'dc'
The 'dc' ('domainComponent' in RFC 2247) attribute type is a string The 'dc' ('domainComponent' in RFC 1274) attribute type is a string
holding one component, a label, of a DNS domain name [RFC1034]. The holding one component, a label, of a DNS domain name
encoding of IA5String for use in LDAP is simply the characters of the [RFC1034][RFC2181] naming a host [RFC1123]. That is, a value of this
ASCII label. The equality matching rule is case insensitive, as is attribute is a string of ASCII characters adhering to the following
today's DNS. ABNF [RFC4234]:
(Source: RFC 2247 [RFC2247])
label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30-39 ; "0"-"9"
HYPHEN = %x2D ; hyphen ("-")
The encoding of IA5String for use in LDAP is simply the characters of
the ASCII label. The equality matching rule is case insensitive, as
is today's DNS. (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274])
( 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 syntax 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
[Syntaxes]. [RFC4517].
Examples: Valid values include "example" and "com". The value Examples: Valid values include "example" and "com" but not
"example.com" is invalid, because it contains two label "example.com". The latter is invalid as it contains multiple domain
components. components.
It is noted that the directory service will not ensure that values of
this attribute conform to the host label restrictions [RFC1123]
illustrated by the <label> production provided above. It is the
directory client's responsibility to ensure that the labels it stores
in this attribute are appropriately restricted.
Directory applications supporting International Domain Names SHALL Directory applications supporting International Domain Names SHALL
use the ToASCII method [RFC3490] to produce the domain name component use the ToASCII method [RFC3490] to produce the domain component
label. The special considerations discussed in section 4 of RFC 3490 label. The special considerations discussed in Section 4 of RFC 3490
[RFC3490] should be taken, depending on whether the domain component [RFC3490] should be taken, depending on whether the domain component
is used for "stored" or "query" purposes. 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. Each description is one value of this phrases about the object. Each description is one value of this
multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes]. [RFC4517].
Examples: "a color printer", "Maintenance is done every Monday, at Examples: "a color printer", "Maintenance is done every Monday, at
1pm." and "distribution list for all technical staff". 1pm.", and "distribution list for all technical staff".
2.6 'destinationIndicator' 2.6. 'destinationIndicator'
The 'destinationIndicator' attribute type contains country and city 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
provide the Public Telegram Service. The strings are composed in the Public Telegram Service. 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
Each string is one value of this multi-valued attribute. one value of this multi-valued attribute.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
[Syntaxes]. [RFC4517].
Examples: "AASD" as a destination indicator for Sydney, Australia. Examples: "AASD" as a destination indicator for Sydney, Australia.
"GBLD" as a destination indicator for London, United "GBLD" as a destination indicator for London, United
Kingdom. Kingdom.
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 F.1 and F.30 CCITT Recommendations. It is attribute conform to the F.1 and F.31 CCITT Recommendations. It is
the application's responsibility to ensure destination indicators the application's responsibility to ensure destination indicators
that it stores in this attribute are appropriately constructed. that it stores in this attribute are appropriately constructed.
2.7 'distinguishedName' 2.7. 'distinguishedName'
The 'distinguishedName' attribute type is not used as the name of the 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 object itself, but it is instead a base type from which some user
attribute types with a DN syntax can inherit. 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 that 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]) (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 [RFC4517].
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 that 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 particular 'dnQualifier' attribute be the same for all entries from a particular
source. source.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
[Syntaxes]. [RFC4517].
Examples: "20050322123345Z" - timestamps can be used to disambiguate Examples: "20050322123345Z" - timestamps can be used to disambiguate
information. information.
"123456A" - serial numbers can be used to disambiguate "123456A" - serial numbers can be used to disambiguate
information. information.
2.9 'enhancedSearchGuide' 2.9. 'enhancedSearchGuide'
The 'enhancedSearchGuide' attribute type contains sets of information 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]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
[Syntaxes]. [RFC4517].
Examples: "person#(sn$APPROX)#wholeSubtree" and Examples: "person#(sn$APPROX)#wholeSubtree" and
"organizationalUnit#(ou$SUBSTR)#oneLevel". "organizationalUnit#(ou$SUBSTR)#oneLevel".
2.10 'facsimileTelephoneNumber' 2.10. 'facsimileTelephoneNumber'
The 'facsimileTelephoneNumber' attribute type contains telephone 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]) (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 [RFC4517].
Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution". Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
2.11 'generationQualifier' 2.11. 'generationQualifier'
The 'generationQualifier' attribute type contains name strings that The 'generationQualifier' attribute type contains name strings that
are the part of a person's name which typically is the suffix. Each are typically the suffix part of a person's name. Each string is one
string is one value of this multi-valued attribute. value of this multi-valued attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.44 NAME 'generationQualifier' ( 2.5.4.44 NAME 'generationQualifier'
SUP name ) SUP name )
Examples: "III", "3rd" and "Jr.". Examples: "III", "3rd", and "Jr.".
2.12 'givenName' 2.12. 'givenName'
The 'givenName' attribute type contains name strings that are the The 'givenName' attribute type contains name strings that are the
part of a person's name which is not their surname. Each string is part of a person's name that is not their surname. Each string is
one value of this multi-valued attribute. one value of this multi-valued attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.42 NAME 'givenName' ( 2.5.4.42 NAME 'givenName'
SUP name ) SUP name )
Examples: "Andrew", "Charles" and "Joanne". Examples: "Andrew", "Charles", and "Joanne".
2.13 'houseIdentifier' 2.13. 'houseIdentifier'
The 'houseIdentifier' attribute type contains identifiers for a 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]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes]. [RFC4517].
Examples: "20" to represent the house number 20. Example: "20" to represent the house number 20.
2.14 'initials' 2.14. 'initials'
The 'initials' attribute type contains strings of initials of some or The 'initials' attribute type contains strings of initials of some or
all of an individual's names, except the surname(s). Each string is all of an individual's names, except the surname(s). Each string is
one value of this multi-valued attribute. one value of this multi-valued attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.43 NAME 'initials' ( 2.5.4.43 NAME 'initials'
SUP name ) SUP name )
Examples: "K. A." and "K". Examples: "K. A." and "K".
2.15 'internationalISDNNumber' 2.15. 'internationalISDNNumber'
The 'internationalISDNNumber' attribute type contains Integrated The 'internationalISDNNumber' attribute type contains Integrated
Services Digital Network (ISDN) addresses, as defined in the Services Digital Network (ISDN) addresses, as defined in the
International Telecommunication Union (ITU) Recommendation E.164 International Telecommunication Union (ITU) Recommendation E.164
[E.164]. Each address is one value of this multi-valued attribute. [E.164]. Each address is one value of this multi-valued attribute.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
[Syntaxes]. [RFC4517].
Example: "0198 333 333". Example: "0198 333 333".
2.16 'l' 2.16. 'l'
The 'l' ('localityName' in X.500) attribute type contains names of a The 'l' ('localityName' in X.500) attribute type contains names of a
locality or place, such as a city, county or other geographic region. locality or place, such as a city, county, or other geographic
Each name is one value of this multi-valued attribute. region. Each name is one value of this multi-valued attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.7 NAME 'l' ( 2.5.4.7 NAME 'l'
SUP name ) SUP name )
Examples: "Geneva", "Paris" and "Edinburgh". Examples: "Geneva", "Paris", and "Edinburgh".
2.17 'member' 2.17. 'member'
The 'member' attribute type contains the Distinguished Names of 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]) (Source: X.520 [X.520])
( 2.5.4.31 NAME 'member' ( 2.5.4.31 NAME 'member'
SUP distinguishedName ) SUP distinguishedName )
Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
"cn=John Xerri,ou=Finance,o=Widget\, Inc." may "cn=John Xerri,ou=Finance,o=Widget\, Inc." may
be two members of the financial team (group) at Widget, be two members of the financial team (group) at Widget,
Inc. In which case, both of these distinguished names would Inc., in which case, both of these distinguished names
be present as individual values of the member attribute. would be present as individual values of the member
attribute.
2.18 'name' 2.18. 'name'
The 'name' attribute type is the attribute supertype from which user The 'name' attribute type is the attribute supertype from which user
attribute types with the name syntax inherit. Such attribute types attribute types with the name syntax inherit. Such attribute types
are typically used for naming. The attribute type is multi-valued. 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 that 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]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes]. [RFC4517].
2.19 'o' 2.19. 'o'
The 'o' ('organizationName' in X.500) attribute type contains the The 'o' ('organizationName' in X.500) attribute type contains the
names of an organization. Each name is one value of this names of an organization. Each name is one value of this
multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.10 NAME 'o' ( 2.5.4.10 NAME 'o'
SUP name ) SUP name )
Examples: "Widget", "Widget, Inc." and "Widget, Incorporated.". Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.".
2.20 'ou' 2.20. 'ou'
The 'ou' ('organizationalUnitName' in X.500) attribute type contains The 'ou' ('organizationalUnitName' in X.500) attribute type contains
the names of an organizational unit. Each name is one value of this the names of an organizational unit. Each name is one value of this
multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.11 NAME 'ou' ( 2.5.4.11 NAME 'ou'
SUP name ) SUP name )
Examples: "Finance", "Human Resources" and "Research and Examples: "Finance", "Human Resources", and "Research and
Development". Development".
2.21 'owner' 2.21. 'owner'
The 'owner' attribute type contains the Distinguished Names of The 'owner' attribute type contains the distinguished names of
objects that have an ownership responsibility for the object that is objects that have an ownership responsibility for the object that is
owned. Each owner's name is one value of this multi-valued owned. Each owner's name is one value of this multi-valued
attribute. attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.32 NAME 'owner' ( 2.5.4.32 NAME 'owner'
SUP distinguishedName ) SUP distinguishedName )
Example: The mailing list object, whose DN is "cn=All Employees, Example: The mailing list object, whose DN is "cn=All Employees,
ou=Mailing List,o=Widget\, Inc.", is owned by the Human ou=Mailing List,o=Widget\, Inc.", is owned by the Human
skipping to change at page 13, line 44 skipping to change at page 12, line 39
owned. Each owner's name is one value of this multi-valued owned. Each owner's name is one value of this multi-valued
attribute. attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.32 NAME 'owner' ( 2.5.4.32 NAME 'owner'
SUP distinguishedName ) SUP distinguishedName )
Example: The mailing list object, whose DN is "cn=All Employees, Example: The mailing list object, whose DN is "cn=All Employees,
ou=Mailing List,o=Widget\, Inc.", is owned by the Human ou=Mailing List,o=Widget\, Inc.", is owned by the Human
Resources Director. Resources Director.
Therefore, the value of the 'owner' attribute within the Therefore, the value of the 'owner' attribute within the
mailing list object, would be the DN of the director (role): mailing list object, would be the DN of the director (role):
"cn=Human Resources Director,ou=employee,o=Widget\, Inc.". "cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
2.22 'physicalDeliveryOfficeName' 2.22. 'physicalDeliveryOfficeName'
The 'physicalDeliveryOfficeName' attribute type contains names that a The 'physicalDeliveryOfficeName' attribute type contains names that a
Postal Service uses to identify a post office. Postal Service uses to identify a post office.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes]. [RFC4517].
Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse". Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
2.23 'postalAddress' 2.23. 'postalAddress'
The 'postalAddress' attribute type contains addresses used by a The 'postalAddress' attribute type contains addresses used by a
Postal Service to perform services for the object. Each address is Postal Service to perform services for the object. Each address is
one value of this multi-valued attribute. one value of this multi-valued attribute.
(Source: X.520 [X.520]) (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 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
[Syntaxes]. [RFC4517].
Example: "15 Main St.$Ottawa$Canada". Example: "15 Main St.$Ottawa$Canada".
2.24 'postalCode' 2.24. 'postalCode'
The 'postalCode' attribute type contains codes used by a Postal The 'postalCode' attribute type contains codes used by a Postal
Service to identify postal service zones. Each code is one value of Service to identify postal service zones. Each code is one value of
this multi-valued attribute. this multi-valued attribute.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes]. [RFC4517].
Example: "22180", to identify Vienna, VA in the USA. Example: "22180", to identify Vienna, VA, in the USA.
2.25 'postOfficeBox' 2.25. 'postOfficeBox'
The 'postOfficeBox' attribute type contains postal box identifiers The 'postOfficeBox' attribute type contains postal box identifiers
that a Postal Service uses when a customer arranges to receive mail that a Postal Service uses when a customer arranges to receive mail
at a box on premises of the Postal Service. Each postal box at a box on the premises of the Postal Service. Each postal box
identifier is a single value of this multi-valued attribute. identifier is a single value of this multi-valued attribute.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes]. [RFC4517].
Example: "Box 45". Example: "Box 45".
2.26 'preferredDeliveryMethod' 2.26. 'preferredDeliveryMethod'
The 'preferredDeliveryMethod' attribute type contains an indication The 'preferredDeliveryMethod' attribute type contains an indication
of the preferred method of getting a message to the object. of the preferred method of getting a message to the object.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
[Syntaxes]. [RFC4517].
Example: If the mhs-delivery Delivery Method is preferred over Example: If the mhs-delivery Delivery Method is preferred over
telephone-delivery, which is preferred over all other telephone-delivery, which is preferred over all other
methods, the value would be: "mhs $ telephone". methods, the value would be: "mhs $ telephone".
2.27 'registeredAddress' 2.27. 'registeredAddress'
The 'registeredAddress' attribute type contains postal addresses 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. one value of this multi-valued attribute.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
[Syntaxes]. [RFC4517].
Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada". Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
2.28 'roleOccupant' 2.28. 'roleOccupant'
The 'roleOccupant' attribute type contains the Distinguished Names of The 'roleOccupant' attribute type contains the distinguished names of
objects (normally people) that fulfill the responsibilities of a role objects (normally people) that fulfill the responsibilities of a role
object. Each distinguished name is one value of this multi-valued object. Each distinguished name is one value of this multi-valued
attribute. attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.33 NAME 'roleOccupant' ( 2.5.4.33 NAME 'roleOccupant'
SUP distinguishedName ) SUP distinguishedName )
Example: The role object, "cn=Human Resources Example: The role object, "cn=Human Resources
Director,ou=Position,o=Widget\, Inc.", is fulfilled by two Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
people whose object names are "cn=Mary people whose object names are "cn=Mary
Smith,ou=employee,o=Widget\, Inc." and "cn=James Smith,ou=employee,o=Widget\, Inc." and "cn=James
Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant' Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant'
attribute will contain both of these distinguished names, attribute will contain both of these distinguished names,
since they are the occupants of this role. since they are the occupants of this role.
2.29 'searchGuide' 2.29. 'searchGuide'
The 'searchGuide' attribute type contains sets of information for use 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. Each set is 'enhancedSearchGuide', described above in Section 2.9. Each set is
one value of this multi-valued attribute. one value of this multi-valued attribute.
(Source: X.520 [X.520]) (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 [RFC4517].
Example: "person#sn$EQ". Example: "person#sn$EQ".
2.30 'seeAlso' 2.30. 'seeAlso'
The 'seeAlso' attribute type contains Distinguished Names of objects The 'seeAlso' attribute type contains the distinguished names of
that are related to the subject object. Each related object name is objects that are related to the subject object. Each related object
one value of this multi-valued attribute. name is one value of this multi-valued attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.34 NAME 'seeAlso' ( 2.5.4.34 NAME 'seeAlso'
SUP distinguishedName ) SUP distinguishedName )
Example: The person object, "cn=James Brown,ou=employee,o=Widget\, Example: The person object "cn=James Brown,ou=employee,o=Widget\,
Inc." is related to the role objects, "cn=Football Team Inc." is related to the role objects "cn=Football Team
Captain,ou=sponsored activities,o=Widget\, Inc." and Captain,ou=sponsored activities,o=Widget\, Inc." and
"cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.". "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
Since the role objects are related to the person object, the Since the role objects are related to the person object, the
'seeAlso' attribute will contain the distinguished name of 'seeAlso' attribute will contain the distinguished name of
each role object as separate values. each role object as separate values.
2.31 'serialNumber' 2.31. 'serialNumber'
The 'serialNumber' attribute type contains the serial numbers of The 'serialNumber' attribute type contains the serial numbers of
devices. Each serial number is one value of this multi-valued devices. Each serial number is one value of this multi-valued
attribute. attribute.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
[Syntaxes]. [RFC4517].
Examples: "WI-3005" and "XF551426". Examples: "WI-3005" and "XF551426".
2.32 'sn' 2.32. 'sn'
The 'sn' ('surname' in X.500) attribute type contains name strings 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 for the family names of a person. Each string is one value of this
multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.4 NAME 'sn' ( 2.5.4.4 NAME 'sn'
SUP name ) SUP name )
Example: "Smith". Example: "Smith".
2.33 'st' 2.33. 'st'
The 'st' ('stateOrProvinceName' in X.500) attribute type contains the The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
full names of states or provinces. Each name is one value of this full names of states or provinces. Each name is one value of this
multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.8 NAME 'st' ( 2.5.4.8 NAME 'st'
SUP name ) SUP name )
Example: "California". Example: "California".
2.34 'street' 2.34. 'street'
The 'street' ('streetAddress' in X.500) attribute type contains site The 'street' ('streetAddress' in X.500) attribute type contains site
information from a postal address (i.e., the street name, place, information from a postal address (i.e., the street name, place,
avenue, and the house number.). Each street is one value of this avenue, and the house number). Each street is one value of this
multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes]. [RFC4517].
Example: "15 Main St.". Example: "15 Main St.".
2.35 'telephoneNumber' 2.35. 'telephoneNumber'
The 'telephoneNumber' attribute type contains telephone numbers that The 'telephoneNumber' attribute type contains telephone numbers that
comply with the ITU Recommendation E.123 [E.123]. Each number is one comply with the ITU Recommendation E.123 [E.123]. Each number is one
value of this multi-valued attribute. value of this multi-valued attribute.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
[Syntaxes]. [RFC4517].
Example: "+1 234 567 8901". Example: "+1 234 567 8901".
2.36 'teletexTerminalIdentifier' 2.36. 'teletexTerminalIdentifier'
The withdrawal of Rec. F.200 has resulted in the withdrawal of this The withdrawal of Recommendation F.200 has resulted in the withdrawal
attribute. of this attribute.
(Source: X.520 [X.520]) (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 )
1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal 1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
Identifier syntax [Syntaxes]. Identifier syntax [RFC4517].
2.37 'telexNumber' 2.37. 'telexNumber'
The 'telexNumber' attribute type contains sets of strings which are a The 'telexNumber' attribute type contains sets of strings that 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]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
[Syntaxes]. [RFC4517].
Example: "12345$023$ABCDE". Example: "12345$023$ABCDE".
2.38 'title' 2.38. 'title'
The 'title' attribute type contains the title of a person in their The 'title' attribute type contains the title of a person in their
organizational context. Each title is one value of this multi-valued organizational context. Each title is one value of this multi-valued
attribute. attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.12 NAME 'title' ( 2.5.4.12 NAME 'title'
SUP name ) SUP name )
Examples: "Vice President", "Software Engineer" and "CEO". Examples: "Vice President", "Software Engineer", and "CEO".
2.39 'uid' 2.39. 'uid'
The 'uid' ('userid' in RFC 1274) attribute type contains computer The 'uid' ('userid' in RFC 1274) attribute type contains computer
system login names associated with the object. Each name is one 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]) (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])
( 0.9.2342.19200300.100.1.1 NAME 'uid' ( 0.9.2342.19200300.100.1.1 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 syntax 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes]. [RFC4517].
Examples: "s9709015", "admin" and "Administrator". 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. Each between objects when a distinguished name has been reused. Each
distinguished name is one value of this multi-valued attribute. distinguished name is one value of this multi-valued attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 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 [RFC4517].
Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
disbanded, establishing a new battalion with the "same" name disbanded, establishing a new battalion with the "same" name
would have a unique identifier value added, resulting in would have a unique identifier value added, resulting in
"ou=1st Battalion, o=Defense,c=US#'010101'B". "ou=1st Battalion, o=Defense,c=US#'010101'B".
2.41 'userPassword' 2.41. 'userPassword'
The 'userPassword' attribute contains octet strings that are known 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 [RFC4013], and transcoding them to Unicode, applying SASLprep [RFC4013], and
encoding as UTF-8. The determination of whether a password is encoding as UTF-8. The determination of whether a password is
textual is a local client matter. textual is a local client matter.
(Source: X.509 [X.509]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
[Syntaxes]. [RFC4517].
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 is expected to
to use a different password generated by some automated system. use a different password generated by some automated system. During
During transitional periods, like the last and first day of the transitional periods, like the last and first day of the periods, it
periods, it may be necessary to allow two passwords for the two may be necessary to allow two passwords for the two consecutive
consecutive periods to be valid in the system. periods to be valid in the system.
2.42 'x121Address' 2.42. 'x121Address'
The 'x121Address' attribute type contains data network addresses as The 'x121Address' attribute type contains data network addresses as
defined by ITU Recommendation X.121 [X.121]. Each address is one defined by ITU Recommendation X.121 [X.121]. Each address is one
value of this multi-valued attribute. value of this multi-valued attribute.
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
[Syntaxes]. [RFC4517].
Example: "36111222333444555". Example: "36111222333444555".
2.43 'x500UniqueIdentifier' 2.43. 'x500UniqueIdentifier'
The 'x500UniqueIdentifier' attribute type contains binary strings The 'x500UniqueIdentifier' attribute type contains binary strings
that are used to distinguish between objects when a distinguished that are used to distinguish between objects when a distinguished
name has been reused. Each string is one value of this multi-valued name has been reused. Each string is one value of this multi-valued
attribute. attribute.
In X.520 [X.520], this attribute type is called 'uniqueIdentifier'. In X.520 [X.520], this attribute type is called 'uniqueIdentifier'.
This is a different attribute type from both the 'uid' and This is a different attribute type from both the 'uid' and
'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier' 'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier'
attribute type is defined in [RFC1274]. attribute type is defined in [RFC4524].
(Source: X.520 [X.520]) (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 syntax 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
[Syntaxes]. [RFC4517].
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 [RFC4512]).
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 that represents an application executing in a computer system.
(Source: X.521 [X.521]) (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 that
represents a country. represents a country.
(Source: X.521 [X.521]) (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 'dcObject' 3.3. 'dcObject'
The 'dcObject' object class permits an entry to contains domain The 'dcObject' object class permits an entry to contains domain
component information. This object class is defined as auxiliary, component information. This object class is defined as auxiliary,
because it will be used in conjunction with an existing structural because it will be used in conjunction with an existing structural
object class. object class.
(Source: RFC 2247 [RFC2247]) (Source: RFC 2247 [RFC2247])
( 1.3.6.1.4.1.1466.344 NAME 'dcObject' ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
SUP top SUP top
AUXILIARY AUXILIARY
MUST dc ) MUST dc )
3.4 'device' 3.4. 'device'
The 'device' object class is the basis of an entry which represents The 'device' object class is the basis of an entry that represents an
an appliance, computer or network element. appliance, computer, or network element.
(Source: X.521 [X.521]) (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 $
skipping to change at page 23, line 23 skipping to change at page 22, line 16
STRUCTURAL STRUCTURAL
MUST cn MUST cn
MAY ( serialNumber $ MAY ( serialNumber $
seeAlso $ seeAlso $
owner $ owner $
ou $ ou $
o $ o $
l $ l $
description ) ) description ) )
3.5 '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 that
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]) (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.6 'groupOfUniqueNames' 3.6. 'groupOfUniqueNames'
The 'groupOfUniqueNames' object class is the same as the The 'groupOfUniqueNames' object class is the same as the
'groupOfNames' object class except that the object names are not 'groupOfNames' object class except that the object names are not
repeated or reassigned within a set scope. repeated or reassigned within a set scope.
(Source: X.521 [X.521]) (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 $
skipping to change at page 24, line 12 skipping to change at page 23, line 16
STRUCTURAL STRUCTURAL
MUST ( uniqueMember $ MUST ( uniqueMember $
cn ) cn )
MAY ( businessCategory $ MAY ( businessCategory $
seeAlso $ seeAlso $
owner $ owner $
ou $ ou $
o $ o $
description ) ) description ) )
3.7 '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 that represents
a place in the physical world. a place in the physical world.
(Source: X.521 [X.521]) (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.8 '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 that
represents a structured group of people. represents a structured group of people.
(Source: X.521 [X.521]) (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 $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $ telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $ facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $ postalCode $ postalAddress $ physicalDeliveryOfficeName $
st $ l $ description ) ) st $ l $ description ) )
3.9 'organizationalPerson' 3.9. 'organizationalPerson'
The 'organizationalPerson' object class is the basis of an entry The 'organizationalPerson' object class is the basis of an entry that
which represents a person in relation to an organization. represents a person in relation to an organization.
(Source: X.521 [X.521]) (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 $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $ telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $ facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $ postalCode $ postalAddress $ physicalDeliveryOfficeName $
ou $ st $ l ) ) ou $ st $ l ) )
3.10 '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 that
represents a job, function or position in an organization. represents a job, function, or position in an organization.
(Source: X.521 [X.521]) (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 $ physicalDeliveryOfficeName $ ou $ st $ l $
description ) ) description ) )
3.11 '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 that
represents a piece of an organization. represents a piece of an organization.
(Source: X.521 [X.521]) (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 $ telephoneNumber $ teletexTerminalIdentifier $
telexNumber $ userPassword $ x121Address ) ) telexNumber $ userPassword $ x121Address ) )
3.12 '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 that represents a
human being. human being.
(Source: X.521 [X.521]) (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.13 '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 that
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]) (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 $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $ telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ preferredDeliveryMethod $ facsimileTelephoneNumber $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $ street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l ) ) physicalDeliveryOfficeName $ st $ l ) )
3.14 'uidObject' 3.14. 'uidObject'
The 'uidObject' object class permits an entry to contains user The 'uidObject' object class permits an entry to contains user
identification information. This object class is defined as identification information. This object class is defined as
auxiliary, because it will be used in conjunction with an existing auxiliary, because it will be used in conjunction with an existing
structural object class. structural object class.
(Source: RFC 2377 [RFC2377]) (Source: RFC 2377 [RFC2377])
( 1.3.6.1.1.3.1 NAME 'uidObject' ( 1.3.6.1.1.3.1 NAME 'uidObject'
SUP top SUP top
AUXILIARY AUXILIARY
MUST uid ) MUST uid )
4. IANA Considerations 4. IANA Considerations
It is requested that the Internet Assigned Numbers Authority (IANA) The Internet Assigned Numbers Authority (IANA) has updated the LDAP
update the LDAP descriptors registry as indicated in the following 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 comments
Object Identifier: see comment Object Identifier: see comments
Person & email address to contact for further information: Person & email address to contact for further information:
Andrew Sciberras <andrew.sciberras@eb2bcom.com> 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 4519
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
names) should be updated to refer to RFC XXXX [editor's note: This In the LDAP descriptors registry, the following descriptors (short
document]. Names that need to be reserved, rather than assigned to names) have been updated to refer to RFC 4519. Names that need to
an Object Identifier, will contain an Object Identifier value of be reserved, rather than assigned to an Object Identifier, will
RESERVED. 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 commonName A 2.5.4.3
country O 2.5.6.2 country O 2.5.6.2
countryName A 2.5.4.6 countryName A 2.5.4.6
DC A 0.9.2342.19200300.100.1.25 dc A 0.9.2342.19200300.100.1.25
dcObject O 1.3.6.1.4.1.1466.344 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
NAME Type OID
------------------------ ---- ----------------------------
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 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 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 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 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
skipping to change at page 28, line 38 skipping to change at page 28, line 4
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 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
NAME Type OID
------------------------ ---- ----------------------------
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 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 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 underlying transport service cannot guarantee confidentiality and
integrity, since this may result in disclosure of the password to integrity, since this may result in disclosure of the password to
unauthorized parties. unauthorized parties.
Multiple attribute values for the 'userPassword' attribute need to be Multiple attribute values for the 'userPassword' attribute need to be
used with care. Especially reset/deletion of a password by an admin used with care. Especially reset/deletion of a password by an
without knowing the old user password gets tricky or impossible if administrator without knowing the old user password gets tricky or
multiple values for different applications are present. impossible if multiple values for different applications are present.
Certainly, applications which intend to replace the 'userPassword' Certainly, applications that 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). In addition, server
implementations are encouraged to provide administrative controls implementations are encouraged to provide administrative controls
which, if enabled, restrict the 'userPassword' attribute to one that, if enabled, restrict the 'userPassword' attribute to one value.
value.
Note that when used for authentication purposes [AuthMeth], the user Note that when used for authentication purposes [RFC4513], the user
need only prove knowledge of one of the values, not all of the need only prove knowledge of one of the values, not all of 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.
skipping to change at page 29, line 45 skipping to change at page 29, line 15
The 'dc' attribute type definition and the 'dcObject' object class The 'dc' attribute type definition and the 'dcObject' object class
definition in this document supersede the specification in RFC 2247 definition in this document supersede the specification in RFC 2247
by S. Kille, M. Wahl, A. Grimstad, 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 supersedes 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 'uidObject' object class definition in this document supersedes
the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R. the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
Huber, S. Sataluri and M. Smith. Huber, S. Sataluri, and M. Wahl.
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. The author would also like significant contribution to this update. The author would also like
to thank Kathy Dally who edited early drafts of this document. to thank Kathy Dally, who edited early versions of this document.
7. References 7. References
7.1 Normative 7.1. Normative References
[E.123] Notation for national and international telephone
numbers, ITU-T Recommendation E.123, 1988
[E.164] The international public telecommunication numbering
plan, ITU-T Recommendation E.164, 1997
[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
countries".
[Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
models-xx (a work in progress)
[RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
FACILITIES", RFC 1034, January 1987
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC3490] Faltstrom P., Hoffman P., Costello A., [E.123] Notation for national and international telephone numbers,
"Internationalizing Domain Names in Applications ITU-T Recommendation E.123, 1988
(IDNA)", RFC 3490, March 2003
[RFC4013] Zeilenga K., "SASLprep: Stringprep profile for User [E.164] The international public telecommunication numbering plan,
Names and Passwords", RFC 4013, February 2005. ITU-T Recommendation E.164, 1997
[RFC4234] Crocker, D., Overell P., "Augmented BNF for Syntax [F.1] Operational Provisions For The International Public
Specifications: ABNF", RFC 4234, October 2005 Telegram Service Transmission System, CCITT Recommendation
F.1, 1992
[Roadmap] Zeilenga, K., "LDAP: Technical Specification Road [F.31] Telegram Retransmission System, CCITT Recommendation F.31,
Map", draft-ietf-ldapbis-roadmap-xx (a work in 1988
progress)
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis- [ISO3166] ISO 3166, "Codes for the representation of names of
syntaxes-xx (a work in progress) countries".
[X.121] International numbering plan for public data networks, [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
ITU-T Recommendation X.121, 1996 STD 13, RFC 1034, November 1987.
[X.509] The Directory: Authentication Framework, ITU-T [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
Recommendation X.509, 1993 and Support", STD 3, RFC 1123, October 1989.
[X.520] The Directory: Selected Attribute Types, ITU-T [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Recommendation X.520, 1993 Requirement Levels", BCP 14, RFC 2119, March 1997.
[X.521] The Directory: Selected Object Classes. ITU-T [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Recommendation X.521, 1993 Specification", RFC 2181, July 1997.
7.2 Informative [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[AuthMeth] Harrison R., "LDAP: Authentication Methods and [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
Connection Level Security Mechanisms", draft-ietf- and Passwords", RFC 4013, February 2005.
ldapbis-authmeth-xx (a work in progress)
[LDAP-PKI] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
(LDAP) schema definitions for X.509 Certificates", Specifications: ABNF", RFC 4234, October 2005.
draft-zeilenga-ldap-x509-xx (a work in progress)
[RFC1274] Barker, P., Kille, S.,"The COSINE and Internet X.500 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
Schema", RFC 1274, November 1991 (LDAP): Technical Specification Road Map", RFC 4510, June
2006.
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
Sataluri, S., "Using Domains in LDAP/X.500 (LDAP): Directory Information Models", RFC 4512, June
Distinguished Names", RFC 2247, January 1998 2006.
[RFC2377] Grimstad, A., Huber, R., Sataluri, S., and Wahl, M., [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
"Naming Plan for Internet-Enabled Applications", RFC (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
2377, September 1998.
[RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object [X.121] International numbering plan for public data networks,
Class", RFC 2798, April 2000 ITU-T Recommendation X.121, 1996
[X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC [X.509] The Directory: Authentication Framework, ITU-T
9594-1:1994, Information Technology - Open Systems Recommendation X.509, 1993
Interconnection - The Directory: Overview of concepts,
models and services.
8. Author's Address [X.520] The Directory: Selected Attribute Types, ITU-T
Recommendation X.520, 1993
Andrew Sciberras [X.521] The Directory: Selected Object Classes. ITU-T
eB2Bcom Recommendation X.521, 1993
Suite 3, Woodhouse Corporate Centre,
935 Station Street,
Box Hill North, Victoria 3129
AUSTRALIA
Phone: +61 3 9896 7833 7.2. Informative References
Email: andrew.sciberras@eb2bcom.com
9. Intellectual Property Statement [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
Schema", RFC 1274, November 1991.
The IETF takes no position regarding the validity or scope of any [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
Intellectual Property Rights or other rights that might be claimed to Sataluri, "Using Domains in LDAP/X.500 Distinguished
pertain to the implementation or use of the technology described in Names", RFC 2247, January 1998.
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl,
assurances of licenses to be made available, or the result of an "Naming Plan for Internet Directory-Enabled Applications",
attempt made to obtain a general license or permission for the use of RFC 2377, September 1998.
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
copyrights, patents or patent applications, or other proprietary Class", RFC 2798, April 2000.
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
10. Full Copyright Statement [RFC4513] Harrison R., Ed., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006.
Copyright (C) The Internet Society (2006). [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Schema Definitions for X.509 Certificates", RFC
4523, June 2006.
This document is subject to the rights, licenses and restrictions [RFC4524] Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524,
contained in BCP 78, and except as set forth therein, the authors June 2006.
retain all their rights.
This document and the information contained herein are provided on an [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994,
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Information Technology - Open Systems Interconnection -
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET The Directory: Overview of concepts, models and services.
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.
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. RFC 4519.
This appendix is not a normative part of this specification, which This appendix is not a normative part of this specification, which
has been provided for informational purposes only. 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 [RFC4517].
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 [RFC4517]).
8. Removed the certificate-related attribute types: 8. Removed the certificate-related attribute types:
authorityRevocationList, cACertificate, authorityRevocationList, cACertificate,
certificateRevocationList, crossCertificatePair, certificateRevocationList, crossCertificatePair,
deltaRevocationList, supportedAlgorithms, and userCertificate. deltaRevocationList, supportedAlgorithms, and userCertificate.
Removed the certificate-related Object Classes: Removed the certificate-related Object Classes:
certificationAuthority, certificationAuthority-V2, certificationAuthority, 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 [RFC4523].
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 type 10. Deleted the aliasedObjectName and objectClass attribute 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 [RFC4512].
11. Added the 'dc' attribute type from RFC 2247. 11. Added the 'dc' attribute type from RFC 2247, making the
distinction between 'stored' and 'query' values when preparing
IDN strings.
12. Numerous edititorial changes. 12. Numerous editorial 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 [RFC4013], and UTF-8 for
userPassword.
changes since 07:
15. Corrected examples in preferredDeliveryMethod, uniqueMember,
postalAddress, and registeredAddress attribute types.
16. Clarified and corrected examples in owner and roleOccupant
attribute types.
17. Added RFC 2234 to normative references.
18. Added RFC 1274 and RFC 2798 to informative references.
19. Removed the statement about RFC 2026 conformance.
20. Added the IPR Disclosure and Notice
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' 15. Included definitions, comments and references for 'dcObject'
and 'uidObject'. and 'uidObject'.
29. Replaced PKI schema references to use draft-zeilenga-ldap- 16. Replaced PKI schema references to use RFC 4523.
x509-xx
30. Spelt out and referenced ABNF on first usage. 17. Spelt out and referenced ABNF on first usage.
31. Removed Section 2.4 (Source). Replaced the source table with 18. Removed Section 2.4 (Source). Replaced the source table with
explicit references for each definition. explicit references for each definition.
32. All references to an attribute type or object class are 19. All references to an attribute type or object class are
enclosed in single quotes. enclosed in single quotes.
33. The layout of attribute type definitions has been changed to 20. The layout of attribute type definitions has been changed to
provide consistency throughout the document: provide consistency throughout the document:
> Section Heading > Section Heading
> Description of Attribute type > Description of Attribute type
> Multivalued description > Multivalued description
> Source Information > Source Information
> Definition > Definition
> Example > Example
> Additional Comments > Additional Comments
Adding this consistent output included the addition of Adding this consistent output included the addition of
examples to some definitions. examples to some definitions.
34. References to alternate names for attributes types are 21. References to alternate names for attributes types are
provided with a reference to where they were originally provided with a reference to where they were originally
specified. specified.
35. Clarification of the description of 'distinguishedName' and 22. Clarification of the description of 'distinguishedName' and
'name', in regards to these attribute types being supertypes. 'name', in regards to these attribute types being supertypes.
36. Spelt out ISDN on first usage. 23. Spelt out ISDN on first usage.
37. Inserted a reference to [Syntaxes] for the 24. Inserted a reference to [RFC4517] for the
'teletexTerminalIdentifier' definition's SYNTAX OID. 'teletexTerminalIdentifier' definition's SYNTAX OID.
38. Additional names were added to the IANA Considerations. Names 25. Additional names were added to the IANA Considerations. Names
include 'commonName', 'dcObject', 'domainComponent', 'GN', include 'commonName', 'dcObject', 'domainComponent', 'GN',
'localityName', 'organizationName', 'organizationUnitName', 'localityName', 'organizationName', 'organizationUnitName',
'surname', 'uidObject' and 'userid'. 'surname', 'uidObject' and 'userid'.
39. Renamed all instances of supercede to supersede. 26. Renamed all instances of supercede to supersede.
40. Moved [F.1], [F.30] and [SASLprep] from informative to 27. Moved [F.1], [F.31] and [RFC4013] from informative to
normative references. normative references.
41. Changed the 'c' definition to be consistent with X.500. 28. Changed the 'c' definition to be consistent with X.500.
42. Added text to 'dc', making the distinction between 'stored' Author's Address
and 'query' values when preparing IDN strings.
Andrew Sciberras
eB2Bcom
Suite 3, Woodhouse Corporate Centre,
935 Station Street,
Box Hill North, Victoria 3129
AUSTRALIA
Phone: +61 3 9896 7833
EMail: andrew.sciberras@eb2bcom.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 244 change blocks. 
520 lines changed or deleted 422 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/