4519
PROPOSED STANDARD
Lightweight Directory Access Protocol (LDAP): Schema for User Applications
Authors: A. Sciberras
Date: June 2006
Area: app
Working Group: ldapbis
Stream: IETF
Abstract
This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. [STANDARDS-TRACK]
RFC 4519
PROPOSED STANDARD
Errata Exist
Network Working Group A. Sciberras, Ed.
Request for Comments: 4519 eB2Bcom
Obsoletes: <a href="./rfc2256">2256</a> June 2006
Updates: <a href="./rfc2247">2247</a>, <a href="./rfc2798">2798</a>, <a href="./rfc2377">2377</a>
Category: Standards Track
<span class="h1">Lightweight Directory Access Protocol (LDAP):</span>
<span class="h1">Schema for User Applications</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document is an integral part of the Lightweight Directory Access
Protocol (LDAP) technical specification. It provides a technical
specification of attribute types and object classes intended for use
by LDAP directory clients for many directory services, such as White
Pages. These objects are widely used as a basis for the schema in
many LDAP directories. This document does not cover attributes used
for the administration of directory servers, nor does it include
directory objects defined for specific uses in other documents.
<span class="grey">Sciberras Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Relationship with Other Specifications .....................<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Conventions ................................................<a href="#page-4">4</a>
<a href="#section-1.3">1.3</a>. General Issues .............................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Attribute Types .................................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. 'businessCategory' .........................................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. 'c' ........................................................<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. 'cn' .......................................................<a href="#page-5">5</a>
<a href="#section-2.4">2.4</a>. 'dc' .......................................................<a href="#page-6">6</a>
<a href="#section-2.5">2.5</a>. 'description' ..............................................<a href="#page-6">6</a>
<a href="#section-2.6">2.6</a>. 'destinationIndicator' .....................................<a href="#page-7">7</a>
<a href="#section-2.7">2.7</a>. 'distinguishedName' ........................................<a href="#page-7">7</a>
<a href="#section-2.8">2.8</a>. 'dnQualifier' ..............................................<a href="#page-8">8</a>
<a href="#section-2.9">2.9</a>. 'enhancedSearchGuide' ......................................<a href="#page-8">8</a>
<a href="#section-2.10">2.10</a>. 'facsimileTelephoneNumber' ................................<a href="#page-9">9</a>
<a href="#section-2.11">2.11</a>. 'generationQualifier' .....................................<a href="#page-9">9</a>
<a href="#section-2.12">2.12</a>. 'givenName' ...............................................<a href="#page-9">9</a>
<a href="#section-2.13">2.13</a>. 'houseIdentifier' .........................................<a href="#page-9">9</a>
<a href="#section-2.14">2.14</a>. 'initials' ...............................................<a href="#page-10">10</a>
<a href="#section-2.15">2.15</a>. 'internationalISDNNumber' ................................<a href="#page-10">10</a>
<a href="#section-2.16">2.16</a>. 'l' ......................................................<a href="#page-10">10</a>
<a href="#section-2.17">2.17</a>. 'member' .................................................<a href="#page-11">11</a>
<a href="#section-2.18">2.18</a>. 'name' ...................................................<a href="#page-11">11</a>
<a href="#section-2.19">2.19</a>. 'o' ......................................................<a href="#page-11">11</a>
<a href="#section-2.20">2.20</a>. 'ou' .....................................................<a href="#page-12">12</a>
<a href="#section-2.21">2.21</a>. 'owner' ..................................................<a href="#page-12">12</a>
<a href="#section-2.22">2.22</a>. 'physicalDeliveryOfficeName' .............................<a href="#page-12">12</a>
<a href="#section-2.23">2.23</a>. 'postalAddress' ..........................................<a href="#page-13">13</a>
<a href="#section-2.24">2.24</a>. 'postalCode' .............................................<a href="#page-13">13</a>
<a href="#section-2.25">2.25</a>. 'postOfficeBox' ..........................................<a href="#page-14">14</a>
<a href="#section-2.26">2.26</a>. 'preferredDeliveryMethod' ................................<a href="#page-14">14</a>
<a href="#section-2.27">2.27</a>. 'registeredAddress' ......................................<a href="#page-14">14</a>
<a href="#section-2.28">2.28</a>. 'roleOccupant' ...........................................<a href="#page-15">15</a>
<a href="#section-2.29">2.29</a>. 'searchGuide' ............................................<a href="#page-15">15</a>
<a href="#section-2.30">2.30</a>. 'seeAlso' ................................................<a href="#page-15">15</a>
<a href="#section-2.31">2.31</a>. 'serialNumber' ...........................................<a href="#page-16">16</a>
<a href="#section-2.32">2.32</a>. 'sn' .....................................................<a href="#page-16">16</a>
<a href="#section-2.33">2.33</a>. 'st' .....................................................<a href="#page-16">16</a>
<a href="#section-2.34">2.34</a>. 'street' .................................................<a href="#page-17">17</a>
<a href="#section-2.35">2.35</a>. 'telephoneNumber' ........................................<a href="#page-17">17</a>
<a href="#section-2.36">2.36</a>. 'teletexTerminalIdentifier' ..............................<a href="#page-17">17</a>
<a href="#section-2.37">2.37</a>. 'telexNumber' ............................................<a href="#page-18">18</a>
<a href="#section-2.38">2.38</a>. 'title' ..................................................<a href="#page-18">18</a>
<a href="#section-2.39">2.39</a>. 'uid' ....................................................<a href="#page-18">18</a>
<a href="#section-2.40">2.40</a>. 'uniqueMember' ...........................................<a href="#page-19">19</a>
<a href="#section-2.41">2.41</a>. 'userPassword' ...........................................<a href="#page-19">19</a>
<span class="grey">Sciberras Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
<a href="#section-2.42">2.42</a>. 'x121Address' ............................................<a href="#page-20">20</a>
<a href="#section-2.43">2.43</a>. 'x500UniqueIdentifier' ...................................<a href="#page-20">20</a>
<a href="#section-3">3</a>. Object Classes .................................................<a href="#page-20">20</a>
<a href="#section-3.1">3.1</a>. 'applicationProcess' ......................................<a href="#page-21">21</a>
<a href="#section-3.2">3.2</a>. 'country' .................................................<a href="#page-21">21</a>
<a href="#section-3.3">3.3</a>. 'dcObject' ................................................<a href="#page-21">21</a>
<a href="#section-3.4">3.4</a>. 'device' ..................................................<a href="#page-21">21</a>
<a href="#section-3.5">3.5</a>. 'groupOfNames' ............................................<a href="#page-22">22</a>
<a href="#section-3.6">3.6</a>. 'groupOfUniqueNames' ......................................<a href="#page-22">22</a>
<a href="#section-3.7">3.7</a>. 'locality' ................................................<a href="#page-23">23</a>
<a href="#section-3.8">3.8</a>. 'organization' ............................................<a href="#page-23">23</a>
<a href="#section-3.9">3.9</a>. 'organizationalPerson' ....................................<a href="#page-24">24</a>
<a href="#section-3.10">3.10</a>. 'organizationalRole' .....................................<a href="#page-24">24</a>
<a href="#section-3.11">3.11</a>. 'organizationalUnit' .....................................<a href="#page-24">24</a>
<a href="#section-3.12">3.12</a>. 'person' .................................................<a href="#page-25">25</a>
<a href="#section-3.13">3.13</a>. 'residentialPerson' ......................................<a href="#page-25">25</a>
<a href="#section-3.14">3.14</a>. 'uidObject' ..............................................<a href="#page-26">26</a>
<a href="#section-4">4</a>. IANA Considerations ............................................<a href="#page-26">26</a>
<a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-28">28</a>
<a href="#section-6">6</a>. Acknowledgements ...............................................<a href="#page-28">28</a>
<a href="#section-7">7</a>. References .....................................................<a href="#page-29">29</a>
<a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-29">29</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-30">30</a>
<a href="#appendix-A">Appendix A</a> Changes Made Since <a href="./rfc2256">RFC 2256</a> ...........................<a href="#page-32">32</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document provides an overview of attribute types and object
classes intended for use by Lightweight Directory Access Protocol
(LDAP) directory clients for many directory services, such as White
Pages. Originally specified in the X.500 [<a href="#ref-X.500" title=" Information Technology - Open Systems Interconnection - The Directory: Overview of concepts">X.500</a>] documents, these
objects are widely used as a basis for the schema in many LDAP
directories. This document does not cover attributes used for the
administration of directory servers, nor does it include directory
objects defined for specific uses in other documents.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Relationship with Other Specifications</span>
This document is an integral part of the LDAP technical specification
[<a href="./rfc4510" title=""Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map"">RFC4510</a>], which obsoletes the previously defined LDAP technical
specification, <a href="./rfc3377">RFC 3377</a>, in its entirety. In terms of <a href="./rfc2256">RFC 2256</a>,
Sections <a href="#section-6">6</a> and <a href="#section-8">8</a> of <a href="./rfc2256">RFC 2256</a> are obsoleted by [<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>]. Sections
5.1, 5.2, 7.1, and 7.2 of <a href="./rfc2256">RFC 2256</a> are obsoleted by [<a href="./rfc4512" title=""Lightweight Directory Access Protocol (LDAP): Directory Information Models"">RFC4512</a>]. The
remainder of <a href="./rfc2256">RFC 2256</a> is obsoleted by this document. The technical
specification for the 'dc' attribute type and 'dcObject' object class
found in <a href="./rfc2247">RFC 2247</a> are superseded by sections <a href="#section-2.4">2.4</a> and <a href="#section-3.3">3.3</a> of this
document. The remainder of <a href="./rfc2247">RFC 2247</a> remains in force.
<span class="grey">Sciberras Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
This document updates <a href="./rfc2798">RFC 2798</a> by replacing the informative
description of the 'uid' attribute type with the definitive
description provided in <a href="#section-2.39">Section 2.39</a> of this document.
This document updates <a href="./rfc2377">RFC 2377</a> by replacing the informative
description of the 'uidObject' object class with the definitive
description provided in <a href="#section-3.14">Section 3.14</a> 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 LDAP. PKI-related schema elements are now specified in
[<a href="./rfc4523" title=""Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates"">RFC4523</a>]. Unless reintroduced in future technical specifications,
the remainder are to be considered Historic.
The descriptions in this document SHALL be considered definitive for
use in LDAP.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Conventions</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. General Issues</span>
This document references Syntaxes defined in <a href="./rfc4517#section-3">Section 3 of [RFC4517]</a>
and Matching Rules defined in <a href="./rfc4517#section-4">Section 4 of [RFC4517]</a>.
The definitions of Attribute Types and Object Classes are written
using the Augmented Backus-Naur Form (ABNF) [<a href="./rfc4234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC4234</a>] of
AttributeTypeDescription and ObjectClassDescription given in
[<a href="./rfc4512" title=""Lightweight Directory Access Protocol (LDAP): Directory Information Models"">RFC4512</a>]. Lines have been folded for readability. When such values
are transferred as attribute values in the LDAP Protocol, the values
will not contain line breaks.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Attribute Types</span>
The attribute types contained in this section hold user information.
There is no requirement that servers implement the 'searchGuide' and
'teletexTerminalIdentifier' attribute types. In fact, their use is
greatly discouraged.
An LDAP server implementation SHOULD recognize the rest of the
attribute types described in this section.
<span class="grey">Sciberras Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. 'businessCategory'</span>
The 'businessCategory' attribute type describes the kinds of business
performed by an organization. Each kind is one value of this
multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.15 NAME 'businessCategory'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Examples: "banking", "transportation", and "real estate".
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. 'c'</span>
The 'c' ('countryName' in X.500) attribute type contains a two-letter
ISO 3166 [<a href="#ref-ISO3166" title=""Codes for the representation of names of countries"">ISO3166</a>] country code.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.6 NAME 'c'
SUP name
SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Examples: "DE", "AU" and "FR".
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. 'cn'</span>
The 'cn' ('commonName' in X.500) attribute type contains names of an
object. Each name is one value of this multi-valued attribute. If
the object corresponds to a person, it is typically the person's full
name.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.3 NAME 'cn'
SUP name )
Examples: "Martin K Smith", "Marty Smith" and "printer12".
<span class="grey">Sciberras Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. 'dc'</span>
The 'dc' ('domainComponent' in <a href="./rfc1274">RFC 1274</a>) attribute type is a string
holding one component, a label, of a DNS domain name
[<a href="./rfc1034" title=""Domain names - concepts and facilities"">RFC1034</a>][RFC2181] naming a host [<a href="./rfc1123" title=""Requirements for Internet Hosts - Application and Support"">RFC1123</a>]. That is, a value of this
attribute is a string of ASCII characters adhering to the following
ABNF [<a href="./rfc4234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC4234</a>]:
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: <a href="./rfc2247">RFC 2247</a> [<a href="./rfc2247" title=""Using Domains in LDAP/X.500 Distinguished Names"">RFC2247</a>] and <a href="./rfc1274">RFC 1274</a> [<a href="./rfc1274">RFC 1274</a>])
( 0.9.2342.19200300.100.1.25 NAME 'dc'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Examples: Valid values include "example" and "com" but not
"example.com". The latter is invalid as it contains multiple domain
components.
It is noted that the directory service will not ensure that values of
this attribute conform to the host label restrictions [<a href="./rfc1123" title=""Requirements for Internet Hosts - Application and Support"">RFC1123</a>]
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
use the ToASCII method [<a href="./rfc3490" title=""Internationalizing Domain Names in Applications (IDNA)"">RFC3490</a>] to produce the domain component
label. The special considerations discussed in <a href="./rfc3490#section-4">Section 4 of RFC 3490</a>
[<a href="./rfc3490" title=""Internationalizing Domain Names in Applications (IDNA)"">RFC3490</a>] should be taken, depending on whether the domain component
is used for "stored" or "query" purposes.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. 'description'</span>
The 'description' attribute type contains human-readable descriptive
phrases about the object. Each description is one value of this
multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
<span class="grey">Sciberras Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
( 2.5.4.13 NAME 'description'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Examples: "a color printer", "Maintenance is done every Monday, at
1pm.", and "distribution list for all technical staff".
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. 'destinationIndicator'</span>
The 'destinationIndicator' attribute type contains country and city
strings associated with the object (the addressee) needed to provide
the Public Telegram Service. The strings are composed in accordance
with CCITT Recommendations F.1 [<a href="#ref-F.1" title="CCITT Recommendation F.1">F.1</a>] and F.31 [<a href="#ref-F.31" title="CCITT Recommendation F.31">F.31</a>]. Each string is
one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.27 NAME 'destinationIndicator'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Examples: "AASD" as a destination indicator for Sydney, Australia.
"GBLD" as a destination indicator for London, United
Kingdom.
It is noted that the directory will not ensure that values of this
attribute conform to the F.1 and F.31 CCITT Recommendations. It is
the application's responsibility to ensure destination indicators
that it stores in this attribute are appropriately constructed.
<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>. 'distinguishedName'</span>
The 'distinguishedName' attribute type is not used as the name of the
object itself, but it is instead a base type from which some user
attribute types with a DN syntax can inherit.
It is unlikely that values of this type itself will occur in an
entry. LDAP server implementations that do not support attribute
subtyping need not recognize this attribute in requests. Client
implementations MUST NOT assume that LDAP servers are capable of
performing attribute subtyping.
<span class="grey">Sciberras Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.49 NAME 'distinguishedName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
<span class="h3"><a class="selflink" id="section-2.8" href="#section-2.8">2.8</a>. 'dnQualifier'</span>
The 'dnQualifier' attribute type contains disambiguating information
strings to add to the relative distinguished name of an entry. The
information is intended for use when merging data from multiple
sources in order to prevent conflicts between entries that would
otherwise have the same name. Each string is one value of this
multi-valued attribute. It is recommended that a value of the
'dnQualifier' attribute be the same for all entries from a particular
source.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.46 NAME 'dnQualifier'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Examples: "20050322123345Z" - timestamps can be used to disambiguate
information.
"123456A" - serial numbers can be used to disambiguate
information.
<span class="h3"><a class="selflink" id="section-2.9" href="#section-2.9">2.9</a>. 'enhancedSearchGuide'</span>
The 'enhancedSearchGuide' attribute type contains sets of information
for use by directory clients in constructing search filters. Each
set is one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.47 NAME 'enhancedSearchGuide'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
<span class="grey">Sciberras Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
Examples: "person#(sn$APPROX)#wholeSubtree" and
"organizationalUnit#(ou$SUBSTR)#oneLevel".
<span class="h3"><a class="selflink" id="section-2.10" href="#section-2.10">2.10</a>. 'facsimileTelephoneNumber'</span>
The 'facsimileTelephoneNumber' attribute type contains telephone
numbers (and, optionally, the parameters) for facsimile terminals.
Each telephone number is one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.23 NAME 'facsimileTelephoneNumber'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
Number syntax [<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
<span class="h3"><a class="selflink" id="section-2.11" href="#section-2.11">2.11</a>. 'generationQualifier'</span>
The 'generationQualifier' attribute type contains name strings that
are typically the suffix part of a person's name. Each string is one
value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.44 NAME 'generationQualifier'
SUP name )
Examples: "III", "3rd", and "Jr.".
<span class="h3"><a class="selflink" id="section-2.12" href="#section-2.12">2.12</a>. 'givenName'</span>
The 'givenName' attribute type contains name strings that are the
part of a person's name that is not their surname. Each string is
one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.42 NAME 'givenName'
SUP name )
Examples: "Andrew", "Charles", and "Joanne".
<span class="h3"><a class="selflink" id="section-2.13" href="#section-2.13">2.13</a>. 'houseIdentifier'</span>
The 'houseIdentifier' attribute type contains identifiers for a
building within a location. Each identifier is one value of this
multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
<span class="grey">Sciberras Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
( 2.5.4.51 NAME 'houseIdentifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: "20" to represent the house number 20.
<span class="h3"><a class="selflink" id="section-2.14" href="#section-2.14">2.14</a>. 'initials'</span>
The 'initials' attribute type contains strings of initials of some or
all of an individual's names, except the surname(s). Each string is
one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.43 NAME 'initials'
SUP name )
Examples: "K. A." and "K".
<span class="h3"><a class="selflink" id="section-2.15" href="#section-2.15">2.15</a>. 'internationalISDNNumber'</span>
The 'internationalISDNNumber' attribute type contains Integrated
Services Digital Network (ISDN) addresses, as defined in the
International Telecommunication Union (ITU) Recommendation E.164
[<a href="#ref-E.164" title=" ITU-T Recommendation E.164">E.164</a>]. Each address is one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.25 NAME 'internationalISDNNumber'
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: "0198 333 333".
<span class="h3"><a class="selflink" id="section-2.16" href="#section-2.16">2.16</a>. 'l'</span>
The 'l' ('localityName' in X.500) attribute type contains names of a
locality or place, such as a city, county, or other geographic
region. Each name is one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
<span class="grey">Sciberras Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
( 2.5.4.7 NAME 'l'
SUP name )
Examples: "Geneva", "Paris", and "Edinburgh".
<span class="h3"><a class="selflink" id="section-2.17" href="#section-2.17">2.17</a>. 'member'</span>
The 'member' attribute type contains the distinguished names of
objects that are on a list or in a group. Each name is one value of
this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.31 NAME 'member'
SUP distinguishedName )
Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
"cn=John Xerri,ou=Finance,o=Widget\, Inc." may
be two members of the financial team (group) at Widget,
Inc., in which case, both of these distinguished names
would be present as individual values of the member
attribute.
<span class="h3"><a class="selflink" id="section-2.18" href="#section-2.18">2.18</a>. 'name'</span>
The 'name' attribute type is the attribute supertype from which user
attribute types with the name syntax inherit. Such attribute types
are typically used for naming. The attribute type is multi-valued.
It is unlikely that values of this type itself will occur in an
entry. LDAP server implementations that do not support attribute
subtyping need not recognize this attribute in requests. Client
implementations MUST NOT assume that LDAP servers are capable of
performing attribute subtyping.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.41 NAME 'name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
<span class="h3"><a class="selflink" id="section-2.19" href="#section-2.19">2.19</a>. 'o'</span>
The 'o' ('organizationName' in X.500) attribute type contains the
names of an organization. Each name is one value of this
multi-valued attribute.
<span class="grey">Sciberras Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.10 NAME 'o'
SUP name )
Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.".
<span class="h3"><a class="selflink" id="section-2.20" href="#section-2.20">2.20</a>. 'ou'</span>
The 'ou' ('organizationalUnitName' in X.500) attribute type contains
the names of an organizational unit. Each name is one value of this
multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.11 NAME 'ou'
SUP name )
Examples: "Finance", "Human Resources", and "Research and
Development".
<span class="h3"><a class="selflink" id="section-2.21" href="#section-2.21">2.21</a>. 'owner'</span>
The 'owner' attribute type contains the distinguished names of
objects that have an ownership responsibility for the object that is
owned. Each owner's name is one value of this multi-valued
attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.32 NAME 'owner'
SUP distinguishedName )
Example: The mailing list object, whose DN is "cn=All Employees,
ou=Mailing List,o=Widget\, Inc.", is owned by the Human
Resources Director.
Therefore, the value of the 'owner' attribute within the
mailing list object, would be the DN of the director (role):
"cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
<span class="h3"><a class="selflink" id="section-2.22" href="#section-2.22">2.22</a>. 'physicalDeliveryOfficeName'</span>
The 'physicalDeliveryOfficeName' attribute type contains names that a
Postal Service uses to identify a post office.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
<span class="grey">Sciberras Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
<span class="h3"><a class="selflink" id="section-2.23" href="#section-2.23">2.23</a>. 'postalAddress'</span>
The 'postalAddress' attribute type contains addresses used by a
Postal Service to perform services for the object. Each address is
one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.16 NAME 'postalAddress'
EQUALITY caseIgnoreListMatch
SUBSTR caseIgnoreListSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: "15 Main St.$Ottawa$Canada".
<span class="h3"><a class="selflink" id="section-2.24" href="#section-2.24">2.24</a>. 'postalCode'</span>
The 'postalCode' attribute type contains codes used by a Postal
Service to identify postal service zones. Each code is one value of
this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.17 NAME 'postalCode'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: "22180", to identify Vienna, VA, in the USA.
<span class="grey">Sciberras Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
<span class="h3"><a class="selflink" id="section-2.25" href="#section-2.25">2.25</a>. 'postOfficeBox'</span>
The 'postOfficeBox' attribute type contains postal box identifiers
that a Postal Service uses when a customer arranges to receive mail
at a box on the premises of the Postal Service. Each postal box
identifier is a single value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.18 NAME 'postOfficeBox'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: "Box 45".
<span class="h3"><a class="selflink" id="section-2.26" href="#section-2.26">2.26</a>. 'preferredDeliveryMethod'</span>
The 'preferredDeliveryMethod' attribute type contains an indication
of the preferred method of getting a message to the object.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.28 NAME 'preferredDeliveryMethod'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: If the mhs-delivery Delivery Method is preferred over
telephone-delivery, which is preferred over all other
methods, the value would be: "mhs $ telephone".
<span class="h3"><a class="selflink" id="section-2.27" href="#section-2.27">2.27</a>. 'registeredAddress'</span>
The 'registeredAddress' attribute type contains postal addresses
suitable for reception of telegrams or expedited documents, where it
is necessary to have the recipient accept delivery. Each address is
one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.26 NAME 'registeredAddress'
SUP postalAddress
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
<span class="grey">Sciberras Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
<span class="h3"><a class="selflink" id="section-2.28" href="#section-2.28">2.28</a>. 'roleOccupant'</span>
The 'roleOccupant' attribute type contains the distinguished names of
objects (normally people) that fulfill the responsibilities of a role
object. Each distinguished name is one value of this multi-valued
attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.33 NAME 'roleOccupant'
SUP distinguishedName )
Example: The role object, "cn=Human Resources
Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
people whose object names are "cn=Mary
Smith,ou=employee,o=Widget\, Inc." and "cn=James
Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant'
attribute will contain both of these distinguished names,
since they are the occupants of this role.
<span class="h3"><a class="selflink" id="section-2.29" href="#section-2.29">2.29</a>. 'searchGuide'</span>
The 'searchGuide' attribute type contains sets of information for use
by clients in constructing search filters. It is superseded by
'enhancedSearchGuide', described above in <a href="#section-2.9">Section 2.9</a>. Each set is
one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.14 NAME 'searchGuide'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: "person#sn$EQ".
<span class="h3"><a class="selflink" id="section-2.30" href="#section-2.30">2.30</a>. 'seeAlso'</span>
The 'seeAlso' attribute type contains the distinguished names of
objects that are related to the subject object. Each related object
name is one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.34 NAME 'seeAlso'
SUP distinguishedName )
<span class="grey">Sciberras Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
Example: The person object "cn=James Brown,ou=employee,o=Widget\,
Inc." is related to the role objects "cn=Football Team
Captain,ou=sponsored activities,o=Widget\, Inc." and
"cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
Since the role objects are related to the person object, the
'seeAlso' attribute will contain the distinguished name of
each role object as separate values.
<span class="h3"><a class="selflink" id="section-2.31" href="#section-2.31">2.31</a>. 'serialNumber'</span>
The 'serialNumber' attribute type contains the serial numbers of
devices. Each serial number is one value of this multi-valued
attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.5 NAME 'serialNumber'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Examples: "WI-3005" and "XF551426".
<span class="h3"><a class="selflink" id="section-2.32" href="#section-2.32">2.32</a>. 'sn'</span>
The 'sn' ('surname' in X.500) attribute type contains name strings
for the family names of a person. Each string is one value of this
multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.4 NAME 'sn'
SUP name )
Example: "Smith".
<span class="h3"><a class="selflink" id="section-2.33" href="#section-2.33">2.33</a>. 'st'</span>
The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
full names of states or provinces. Each name is one value of this
multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.8 NAME 'st'
SUP name )
Example: "California".
<span class="grey">Sciberras Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
<span class="h3"><a class="selflink" id="section-2.34" href="#section-2.34">2.34</a>. 'street'</span>
The 'street' ('streetAddress' in X.500) attribute type contains site
information from a postal address (i.e., the street name, place,
avenue, and the house number). Each street is one value of this
multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.9 NAME 'street'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: "15 Main St.".
<span class="h3"><a class="selflink" id="section-2.35" href="#section-2.35">2.35</a>. 'telephoneNumber'</span>
The 'telephoneNumber' attribute type contains telephone numbers that
comply with the ITU Recommendation E.123 [<a href="#ref-E.123" title=" ITU-T Recommendation E.123">E.123</a>]. Each number is one
value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.20 NAME 'telephoneNumber'
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: "+1 234 567 8901".
<span class="h3"><a class="selflink" id="section-2.36" href="#section-2.36">2.36</a>. 'teletexTerminalIdentifier'</span>
The withdrawal of Recommendation F.200 has resulted in the withdrawal
of this attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.22 NAME 'teletexTerminalIdentifier'
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
Identifier syntax [<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
<span class="grey">Sciberras Standards Track [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
<span class="h3"><a class="selflink" id="section-2.37" href="#section-2.37">2.37</a>. 'telexNumber'</span>
The 'telexNumber' attribute type contains sets of strings that are a
telex number, country code, and answerback code of a telex terminal.
Each set is one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.21 NAME 'telexNumber'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: "12345$023$ABCDE".
<span class="h3"><a class="selflink" id="section-2.38" href="#section-2.38">2.38</a>. 'title'</span>
The 'title' attribute type contains the title of a person in their
organizational context. Each title is one value of this multi-valued
attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.12 NAME 'title'
SUP name )
Examples: "Vice President", "Software Engineer", and "CEO".
<span class="h3"><a class="selflink" id="section-2.39" href="#section-2.39">2.39</a>. 'uid'</span>
The 'uid' ('userid' in <a href="./rfc1274">RFC 1274</a>) attribute type contains computer
system login names associated with the object. Each name is one
value of this multi-valued attribute.
(Source: <a href="./rfc2798">RFC 2798</a> [<a href="./rfc2798" title=""Definition of the inetOrgPerson LDAP Object Class"">RFC2798</a>] and <a href="./rfc1274">RFC 1274</a> [<a href="./rfc1274" title=""The COSINE and Internet X.500 Schema"">RFC1274</a>])
( 0.9.2342.19200300.100.1.1 NAME 'uid'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Examples: "s9709015", "admin", and "Administrator".
<span class="grey">Sciberras Standards Track [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
<span class="h3"><a class="selflink" id="section-2.40" href="#section-2.40">2.40</a>. 'uniqueMember'</span>
The 'uniqueMember' attribute type contains the distinguished names of
an object that is on a list or in a group, where the relative
distinguished names of the object include a value that distinguishes
between objects when a distinguished name has been reused. Each
distinguished name is one value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.50 NAME 'uniqueMember'
EQUALITY uniqueMemberMatch
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
syntax [<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
disbanded, establishing a new battalion with the "same" name
would have a unique identifier value added, resulting in
"ou=1st Battalion, o=Defense,c=US#'010101'B".
<span class="h3"><a class="selflink" id="section-2.41" href="#section-2.41">2.41</a>. 'userPassword'</span>
The 'userPassword' attribute contains octet strings that are known
only to the user and the system to which the user has access. Each
string is one value of this multi-valued attribute.
The application SHOULD prepare textual strings used as passwords by
transcoding them to Unicode, applying SASLprep [<a href="./rfc4013" title=""SASLprep: Stringprep Profile for User Names and Passwords"">RFC4013</a>], and
encoding as UTF-8. The determination of whether a password is
textual is a local client matter.
(Source: X.509 [<a href="#ref-X.509" title="ITU-T Recommendation X.509">X.509</a>])
( 2.5.4.35 NAME 'userPassword'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Passwords are stored using an Octet String syntax and are not
encrypted. Transfer of cleartext passwords is strongly discouraged
where the underlying transport service cannot guarantee
confidentiality and may result in disclosure of the password to
unauthorized parties.
An example of a need for multiple values in the 'userPassword'
attribute is an environment where every month the user is expected to
<span class="grey">Sciberras Standards Track [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
use a different password generated by some automated system. During
transitional periods, like the last and first day of the periods, it
may be necessary to allow two passwords for the two consecutive
periods to be valid in the system.
<span class="h3"><a class="selflink" id="section-2.42" href="#section-2.42">2.42</a>. 'x121Address'</span>
The 'x121Address' attribute type contains data network addresses as
defined by ITU Recommendation X.121 [<a href="#ref-X.121" title=" ITU-T Recommendation X.121">X.121</a>]. Each address is one
value of this multi-valued attribute.
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.24 NAME 'x121Address'
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
Example: "36111222333444555".
<span class="h3"><a class="selflink" id="section-2.43" href="#section-2.43">2.43</a>. 'x500UniqueIdentifier'</span>
The 'x500UniqueIdentifier' attribute type contains binary strings
that are used to distinguish between objects when a distinguished
name has been reused. Each string is one value of this multi-valued
attribute.
In X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>], this attribute type is called 'uniqueIdentifier'.
This is a different attribute type from both the 'uid' and
'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier'
attribute type is defined in [<a href="./rfc4524" title=""COSINE LDAP/X.500 Schema"">RFC4524</a>].
(Source: X.520 [<a href="#ref-X.520" title="ITU-T Recommendation X.520">X.520</a>])
( 2.5.4.45 NAME 'x500UniqueIdentifier'
EQUALITY bitStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
[<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Object Classes</span>
LDAP servers SHOULD recognize all the Object Classes listed here as
values of the 'objectClass' attribute (see [<a href="./rfc4512" title=""Lightweight Directory Access Protocol (LDAP): Directory Information Models"">RFC4512</a>]).
<span class="grey">Sciberras Standards Track [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. 'applicationProcess'</span>
The 'applicationProcess' object class definition is the basis of an
entry that represents an application executing in a computer system.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
( 2.5.6.11 NAME 'applicationProcess'
SUP top
STRUCTURAL
MUST cn
MAY ( seeAlso $
ou $
l $
description ) )
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. 'country'</span>
The 'country' object class definition is the basis of an entry that
represents a country.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
( 2.5.6.2 NAME 'country'
SUP top
STRUCTURAL
MUST c
MAY ( searchGuide $
description ) )
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. 'dcObject'</span>
The 'dcObject' object class permits an entry to contains domain
component information. This object class is defined as auxiliary,
because it will be used in conjunction with an existing structural
object class.
(Source: <a href="./rfc2247">RFC 2247</a> [<a href="./rfc2247" title=""Using Domains in LDAP/X.500 Distinguished Names"">RFC2247</a>])
( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
SUP top
AUXILIARY
MUST dc )
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. 'device'</span>
The 'device' object class is the basis of an entry that represents an
appliance, computer, or network element.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
<span class="grey">Sciberras Standards Track [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
( 2.5.6.14 NAME 'device'
SUP top
STRUCTURAL
MUST cn
MAY ( serialNumber $
seeAlso $
owner $
ou $
o $
l $
description ) )
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. 'groupOfNames'</span>
The 'groupOfNames' object class is the basis of an entry that
represents a set of named objects including information related to
the purpose or maintenance of the set.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
( 2.5.6.9 NAME 'groupOfNames'
SUP top
STRUCTURAL
MUST ( member $
cn )
MAY ( businessCategory $
seeAlso $
owner $
ou $
o $
description ) )
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. 'groupOfUniqueNames'</span>
The 'groupOfUniqueNames' object class is the same as the
'groupOfNames' object class except that the object names are not
repeated or reassigned within a set scope.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
<span class="grey">Sciberras Standards Track [Page 22]</span><span id="page-23" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
( 2.5.6.17 NAME 'groupOfUniqueNames'
SUP top
STRUCTURAL
MUST ( uniqueMember $
cn )
MAY ( businessCategory $
seeAlso $
owner $
ou $
o $
description ) )
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. 'locality'</span>
The 'locality' object class is the basis of an entry that represents
a place in the physical world.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
( 2.5.6.3 NAME 'locality'
SUP top
STRUCTURAL
MAY ( street $
seeAlso $
searchGuide $
st $
l $
description ) )
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>. 'organization'</span>
The 'organization' object class is the basis of an entry that
represents a structured group of people.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
( 2.5.6.4 NAME 'organization'
SUP top
STRUCTURAL
MUST o
MAY ( userPassword $ searchGuide $ seeAlso $
businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $
st $ l $ description ) )
<span class="grey">Sciberras Standards Track [Page 23]</span><span id="page-24" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a>. 'organizationalPerson'</span>
The 'organizationalPerson' object class is the basis of an entry that
represents a person in relation to an organization.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
( 2.5.6.7 NAME 'organizationalPerson'
SUP person
STRUCTURAL
MAY ( title $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $
ou $ st $ l ) )
<span class="h3"><a class="selflink" id="section-3.10" href="#section-3.10">3.10</a>. 'organizationalRole'</span>
The 'organizationalRole' object class is the basis of an entry that
represents a job, function, or position in an organization.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
( 2.5.6.8 NAME 'organizationalRole'
SUP top
STRUCTURAL
MUST cn
MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationalISDNNumber $ facsimileTelephoneNumber $
seeAlso $ roleOccupant $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l $
description ) )
<span class="h3"><a class="selflink" id="section-3.11" href="#section-3.11">3.11</a>. 'organizationalUnit'</span>
The 'organizationalUnit' object class is the basis of an entry that
represents a piece of an organization.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
<span class="grey">Sciberras Standards Track [Page 24]</span><span id="page-25" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
( 2.5.6.5 NAME 'organizationalUnit'
SUP top
STRUCTURAL
MUST ou
MAY ( businessCategory $ description $ destinationIndicator $
facsimileTelephoneNumber $ internationalISDNNumber $ l $
physicalDeliveryOfficeName $ postalAddress $ postalCode $
postOfficeBox $ preferredDeliveryMethod $
registeredAddress $ searchGuide $ seeAlso $ st $ street $
telephoneNumber $ teletexTerminalIdentifier $
telexNumber $ userPassword $ x121Address ) )
<span class="h3"><a class="selflink" id="section-3.12" href="#section-3.12">3.12</a> 'person'</span>
The 'person' object class is the basis of an entry that represents a
human being.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
( 2.5.6.6 NAME 'person'
SUP top
STRUCTURAL
MUST ( sn $
cn )
MAY ( userPassword $
telephoneNumber $
seeAlso $ description ) )
<span class="h3"><a class="selflink" id="section-3.13" href="#section-3.13">3.13</a>. 'residentialPerson'</span>
The 'residentialPerson' object class is the basis of an entry that
includes a person's residence in the representation of the person.
(Source: X.521 [<a href="#ref-X.521">X.521</a>])
( 2.5.6.10 NAME 'residentialPerson'
SUP person
STRUCTURAL
MUST l
MAY ( businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l ) )
<span class="grey">Sciberras Standards Track [Page 25]</span><span id="page-26" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
<span class="h3"><a class="selflink" id="section-3.14" href="#section-3.14">3.14</a>. 'uidObject'</span>
The 'uidObject' object class permits an entry to contains user
identification information. This object class is defined as
auxiliary, because it will be used in conjunction with an existing
structural object class.
(Source: <a href="./rfc2377">RFC 2377</a> [<a href="./rfc2377" title=""Naming Plan for Internet Directory-Enabled Applications"">RFC2377</a>])
( 1.3.6.1.1.3.1 NAME 'uidObject'
SUP top
AUXILIARY
MUST uid )
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
The Internet Assigned Numbers Authority (IANA) has updated the LDAP
descriptors registry as indicated in the following template:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comments
Object Identifier: see comments
Person & email address to contact for further information:
Andrew Sciberras <andrew.sciberras@eb2bcom.com>
Usage: (A = attribute type, O = Object Class) see comment
Specification: <a href="./rfc4519">RFC 4519</a>
Author/Change Controller: IESG
Comments
In the LDAP descriptors registry, the following descriptors (short
names) have been updated to refer to <a href="./rfc4519">RFC 4519</a>. Names that need to
be reserved, rather than assigned to an Object Identifier, will
contain an Object Identifier value of RESERVED.
NAME Type OID
------------------------ ---- ----------------------------
applicationProcess O 2.5.6.11
businessCategory A 2.5.4.15
c A 2.5.4.6
cn A 2.5.4.3
commonName A 2.5.4.3
country O 2.5.6.2
countryName A 2.5.4.6
dc A 0.9.2342.19200300.100.1.25
dcObject O 1.3.6.1.4.1.1466.344
description A 2.5.4.13
destinationIndicator A 2.5.4.27
device O 2.5.6.14
<span class="grey">Sciberras Standards Track [Page 26]</span><span id="page-27" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
NAME Type OID
------------------------ ---- ----------------------------
distinguishedName A 2.5.4.49
dnQualifier A 2.5.4.46
domainComponent A 0.9.2342.19200300.100.1.25
enhancedSearchGuide A 2.5.4.47
facsimileTelephoneNumber A 2.5.4.23
generationQualifier A 2.5.4.44
givenName A 2.5.4.42
gn A RESERVED
groupOfNames O 2.5.6.9
groupOfUniqueNames O 2.5.6.17
houseIdentifier A 2.5.4.51
initials A 2.5.4.43
internationalISDNNumber A 2.5.4.25
l A 2.5.4.7
locality O 2.5.6.3
localityName A 2.5.4.7
member A 2.5.4.31
name A 2.5.4.41
o A 2.5.4.10
organization O 2.5.6.4
organizationName A 2.5.4.10
organizationalPerson O 2.5.6.7
organizationalRole O 2.5.6.8
organizationalUnit O 2.5.6.5
organizationalUnitName A 2.5.4.11
ou A 2.5.4.11
owner A 2.5.4.32
person O 2.5.6.6
physicalDeliveryOfficeName A 2.5.4.19
postalAddress A 2.5.4.16
postalCode A 2.5.4.17
postOfficeBox A 2.5.4.18
preferredDeliveryMethod A 2.5.4.28
registeredAddress A 2.5.4.26
residentialPerson O 2.5.6.10
roleOccupant A 2.5.4.33
searchGuide A 2.5.4.14
seeAlso A 2.5.4.34
serialNumber A 2.5.4.5
sn A 2.5.4.4
st A 2.5.4.8
street A 2.5.4.9
surname A 2.5.4.4
telephoneNumber A 2.5.4.20
teletexTerminalIdentifier A 2.5.4.22
telexNumber A 2.5.4.21
<span class="grey">Sciberras Standards Track [Page 27]</span><span id="page-28" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
NAME Type OID
------------------------ ---- ----------------------------
title A 2.5.4.12
uid A 0.9.2342.19200300.100.1.1
uidObject O 1.3.6.1.1.3.1
uniqueMember A 2.5.4.50
userid A 0.9.2342.19200300.100.1.1
userPassword A 2.5.4.35
x121Address A 2.5.4.24
x500UniqueIdentifier A 2.5.4.45
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
Attributes of directory entries are used to provide descriptive
information about the real-world objects they represent, which can be
people, organizations, or devices. Most countries have privacy laws
regarding the publication of information about people.
Transfer of cleartext passwords is strongly discouraged where the
underlying transport service cannot guarantee confidentiality and
integrity, since this may result in disclosure of the password to
unauthorized parties.
Multiple attribute values for the 'userPassword' attribute need to be
used with care. Especially reset/deletion of a password by an
administrator without knowing the old user password gets tricky or
impossible if multiple values for different applications are present.
Certainly, applications that intend to replace the 'userPassword'
value(s) with new value(s) should use modify/replaceValues (or
modify/deleteAttribute+addAttribute). In addition, server
implementations are encouraged to provide administrative controls
that, if enabled, restrict the 'userPassword' attribute to one value.
Note that when used for authentication purposes [<a href="./rfc4513" title=""Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms"">RFC4513</a>], the user
need only prove knowledge of one of the values, not all of the
values.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgements</span>
The definitions, on which this document is based, have been developed
by committees for telecommunications and international standards.
This document is an update of <a href="./rfc2256">RFC 2256</a> by Mark Wahl. <a href="./rfc2256">RFC 2256</a> was a
product of the IETF ASID Working Group.
<span class="grey">Sciberras Standards Track [Page 28]</span><span id="page-29" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
The 'dc' attribute type definition and the 'dcObject' object class
definition in this document supersede the specification in <a href="./rfc2247">RFC 2247</a>
by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.
The 'uid' attribute type definition in this document supersedes the
specification of the 'userid' in <a href="./rfc1274">RFC 1274</a> by P. Barker and S. Kille
and of the uid in <a href="./rfc2798">RFC 2798</a> by M. Smith.
The 'uidObject' object class definition in this document supersedes
the specification of the 'uidObject' in <a href="./rfc2377">RFC 2377</a> by A. Grimstad, R.
Huber, S. Sataluri, and M. Wahl.
This document is based upon input of the IETF LDAPBIS working group.
The author wishes to thank S. Legg and K. Zeilenga for their
significant contribution to this update. The author would also like
to thank Kathy Dally, who edited early versions of this document.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-E.123">E.123</a>] Notation for national and international telephone numbers,
ITU-T Recommendation E.123, 1988
[<a id="ref-E.164">E.164</a>] The international public telecommunication numbering plan,
ITU-T Recommendation E.164, 1997
[<a id="ref-F.1">F.1</a>] Operational Provisions For The International Public
Telegram Service Transmission System, CCITT Recommendation
F.1, 1992
[<a id="ref-F.31">F.31</a>] Telegram Retransmission System, CCITT Recommendation F.31,
1988
[<a id="ref-ISO3166">ISO3166</a>] ISO 3166, "Codes for the representation of names of
countries".
[<a id="ref-RFC1034">RFC1034</a>] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, <a href="./rfc1034">RFC 1034</a>, November 1987.
[<a id="ref-RFC1123">RFC1123</a>] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, <a href="./rfc1123">RFC 1123</a>, October 1989.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2181">RFC2181</a>] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", <a href="./rfc2181">RFC 2181</a>, July 1997.
<span class="grey">Sciberras Standards Track [Page 29]</span><span id="page-30" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
[<a id="ref-RFC3490">RFC3490</a>] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
<a href="./rfc3490">RFC 3490</a>, March 2003.
[<a id="ref-RFC4013">RFC4013</a>] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", <a href="./rfc4013">RFC 4013</a>, February 2005.
[<a id="ref-RFC4234">RFC4234</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", <a href="./rfc4234">RFC 4234</a>, October 2005.
[<a id="ref-RFC4510">RFC4510</a>] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", <a href="./rfc4510">RFC 4510</a>, June
2006.
[<a id="ref-RFC4512">RFC4512</a>] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", <a href="./rfc4512">RFC 4512</a>, June
2006.
[<a id="ref-RFC4517">RFC4517</a>] Legg, S., Ed., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", <a href="./rfc4517">RFC 4517</a>, June 2006.
[<a id="ref-X.121">X.121</a>] International numbering plan for public data networks,
ITU-T Recommendation X.121, 1996
[<a id="ref-X.509">X.509</a>] The Directory: Authentication Framework, ITU-T
Recommendation X.509, 1993
[<a id="ref-X.520">X.520</a>] The Directory: Selected Attribute Types, ITU-T
Recommendation X.520, 1993
[<a id="ref-X.521">X.521</a>] The Directory: Selected Object Classes. ITU-T
Recommendation X.521, 1993
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-RFC1274">RFC1274</a>] Barker, P. and S. Kille, "The COSINE and Internet X.500
Schema", <a href="./rfc1274">RFC 1274</a>, November 1991.
[<a id="ref-RFC2247">RFC2247</a>] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
Sataluri, "Using Domains in LDAP/X.500 Distinguished
Names", <a href="./rfc2247">RFC 2247</a>, January 1998.
[<a id="ref-RFC2377">RFC2377</a>] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl,
"Naming Plan for Internet Directory-Enabled Applications",
<a href="./rfc2377">RFC 2377</a>, September 1998.
[<a id="ref-RFC2798">RFC2798</a>] Smith, M., "Definition of the inetOrgPerson LDAP Object
Class", <a href="./rfc2798">RFC 2798</a>, April 2000.
<span class="grey">Sciberras Standards Track [Page 30]</span><span id="page-31" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
[<a id="ref-RFC4513">RFC4513</a>] Harrison R., Ed., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms",
<a href="./rfc4513">RFC 4513</a>, June 2006.
[<a id="ref-RFC4523">RFC4523</a>] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Schema Definitions for X.509 Certificates", <a href="./rfc4523">RFC</a>
<a href="./rfc4523">4523</a>, June 2006.
[<a id="ref-RFC4524">RFC4524</a>] Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", <a href="./rfc4524">RFC 4524</a>,
June 2006.
[<a id="ref-X.500">X.500</a>] ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services.
<span class="grey">Sciberras Standards Track [Page 31]</span><span id="page-32" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Changes Made Since <a href="./rfc2256">RFC 2256</a></span>
This appendix lists the changes that have been made from <a href="./rfc2256">RFC 2256</a> to
<a href="./rfc4519">RFC 4519</a>.
This appendix is not a normative part of this specification, which
has been provided for informational purposes only.
1. Replaced the document title.
2. Removed the IESG Note.
3. Dependencies on <a href="./rfc1274">RFC 1274</a> have been eliminated.
4. Added a Security Considerations section and an IANA
Considerations section.
5. Deleted the conformance requirement for subschema object
classes in favor of a statement in [<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>].
6. Added explanation to attribute types and to each object class.
7. Removed <a href="#section-4">Section 4</a>, Syntaxes, and <a href="#section-6">Section 6</a>, Matching Rules,
(moved to [<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>]).
8. Removed the certificate-related attribute types:
authorityRevocationList, cACertificate,
certificateRevocationList, crossCertificatePair,
deltaRevocationList, supportedAlgorithms, and userCertificate.
Removed the certificate-related Object Classes:
certificationAuthority, certificationAuthority-V2,
cRLDistributionPoint, strongAuthenticationUser, and
userSecurityInformation
LDAP PKI is now discussed in [<a href="./rfc4523" title=""Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates"">RFC4523</a>].
9. Removed the dmdName, knowledgeInformation,
presentationAddress, protocolInformation, and
supportedApplicationContext attribute types and the dmd,
applicationEntity, and dSA object classes.
10. Deleted the aliasedObjectName and objectClass attribute type
definitions. Deleted the alias and top object class
definitions. They are included in [<a href="./rfc4512" title=""Lightweight Directory Access Protocol (LDAP): Directory Information Models"">RFC4512</a>].
<span class="grey">Sciberras Standards Track [Page 32]</span><span id="page-33" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
11. Added the 'dc' attribute type from <a href="./rfc2247">RFC 2247</a>, making the
distinction between 'stored' and 'query' values when preparing
IDN strings.
12. Numerous editorial changes.
13. Removed upper bound after the SYNTAX oid in all attribute
definitions where it appeared.
14. Added text about Unicode, SASLprep [<a href="./rfc4013" title=""SASLprep: Stringprep Profile for User Names and Passwords"">RFC4013</a>], and UTF-8 for
userPassword.
15. Included definitions, comments and references for 'dcObject'
and 'uidObject'.
16. Replaced PKI schema references to use <a href="./rfc4523">RFC 4523</a>.
17. Spelt out and referenced ABNF on first usage.
18. Removed <a href="#section-2.4">Section 2.4</a> (Source). Replaced the source table with
explicit references for each definition.
19. All references to an attribute type or object class are
enclosed in single quotes.
20. The layout of attribute type definitions has been changed to
provide consistency throughout the document:
> Section Heading
> Description of Attribute type
> Multivalued description
> Source Information
> Definition
> Example
> Additional Comments
Adding this consistent output included the addition of
examples to some definitions.
21. References to alternate names for attributes types are
provided with a reference to where they were originally
specified.
22. Clarification of the description of 'distinguishedName' and
'name', in regards to these attribute types being supertypes.
23. Spelt out ISDN on first usage.
<span class="grey">Sciberras Standards Track [Page 33]</span><span id="page-34" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
24. Inserted a reference to [<a href="./rfc4517" title=""Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"">RFC4517</a>] for the
'teletexTerminalIdentifier' definition's SYNTAX OID.
25. Additional names were added to the IANA Considerations. Names
include 'commonName', 'dcObject', 'domainComponent', 'GN',
'localityName', 'organizationName', 'organizationUnitName',
'surname', 'uidObject' and 'userid'.
26. Renamed all instances of supercede to supersede.
27. Moved [<a href="#ref-F.1" title="CCITT Recommendation F.1">F.1</a>], [<a href="#ref-F.31" title="CCITT Recommendation F.31">F.31</a>] and [<a href="./rfc4013" title=""SASLprep: Stringprep Profile for User Names and Passwords"">RFC4013</a>] from informative to
normative references.
28. Changed the 'c' definition to be consistent with X.500.
Author's Address
Andrew Sciberras
eB2Bcom
Suite 3, Woodhouse Corporate Centre,
935 Station Street,
Box Hill North, Victoria 3129
AUSTRALIA
Phone: +61 3 9896 7833
EMail: [email protected]
<span class="grey">Sciberras Standards Track [Page 34]</span><span id="page-35" ></span>
<span class="grey"><a href="./rfc4519">RFC 4519</a> LDAP: Schema for User Applications June 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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
[email protected].
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Sciberras Standards Track [Page 35]
Annotations
Select text to annotate