draft-ietf-ldapbis-models-14.txt   rfc4512.txt 
INTERNET-DRAFT Editor: Kurt D. Zeilenga Network Working Group K. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation Request for Comments: 4512 OpenLDAP Foundation
Expires in six months 21 February 2005
Obsoletes: RFC 2251, RFC 2252, RFC 2256, RFC 3674
LDAP: Directory Information Models
<draft-ietf-ldapbis-models-14.txt>
Status of this Memo
This document is intended to be published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.org>. Please send editorial
comments directly to the editor <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Category: Standards Track
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 Directory Information Models
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.
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright Notice
Please see the Full Copyright section near the end of this document Copyright (C) The Internet Society (2006).
for more information.
Abstract Abstract
The Lightweight Directory Access Protocol (LDAP) is an Internet The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in protocol for accessing distributed directory services that act in
accordance with X.500 data and service models. This document accordance with X.500 data and service models. This document
describes the X.500 Directory Information Models, as used in LDAP. describes the X.500 Directory Information Models, as used in LDAP.
Table of Contents Table of Contents
Status of this Memo 1 1. Introduction ....................................................3
Abstract 2 1.1. Relationship to Other LDAP Specifications ..................3
Table of Contents 1.2. Relationship to X.501 ......................................4
1. Introduction 3 1.3. Conventions ................................................4
1.1. Relationship to Other LDAP Specifications 1.4. Common ABNF Productions ....................................4
1.2. Relationship to X.501 4 2. Model of Directory User Information .............................6
1.3. Conventions 2.1. The Directory Information Tree .............................7
1.4. Common ABNF Productions 2.2. Structure of an Entry ......................................7
2. Model of Directory User Information 6 2.3. Naming of Entries ..........................................8
2.1. The Directory Information Tree 7 2.4. Object Classes .............................................9
2.2. Structure of an Entry 2.5. Attribute Descriptions ....................................12
2.3. Naming of Entries 8 2.6. Alias Entries .............................................16
2.4. Object Classes 9 3. Directory Administrative and Operational Information ...........17
2.5. Attribute Descriptions 12 3.1. Subtrees ..................................................17
2.6. Alias Entries 16 3.2. Subentries ................................................18
3. Directory Administrative and Operational Information 17 3.3. The 'objectClass' attribute ...............................18
3.1. Subtrees 3.4. Operational Attributes ....................................19
3.2. Subentries 18 4. Directory Schema ...............................................22
3.3. The 'objectClass' attribute 4.1. Schema Definitions ........................................23
3.4. Operational attributes 19 4.2. Subschema Subentries ......................................32
4. Directory Schema 22 4.3. 'extensibleObject' object class ...........................35
4.1. Schema Definitions 23 4.4. Subschema Discovery .......................................35
4.2. Subschema Subentries 32 5. DSA (Server) Informational Model ...............................36
4.3. 'extensibleObject' 35 5.1. Server-Specific Data Requirements .........................36
4.4. Subschema Discovery 36 6. Other Considerations ...........................................40
5. DSA (Server) Informational Model 6.1. Preservation of User Information ..........................40
5.1. Server-specific Data Requirements 37 6.2. Short Names ...............................................41
6. Other Considerations 40 6.3. Cache and Shadowing .......................................41
6.1. Preservation of User Information 41 7. Implementation Guidelines ......................................42
6.2. Short Names 7.1. Server Guidelines .........................................42
6.3. Cache and Shadowing 7.2. Client Guidelines .........................................42
7. Implementation Guidelines 42 8. Security Considerations ........................................43
7.1. Server Guidelines 9. IANA Considerations ............................................43
7.2. Client Guidelines 10. Acknowledgements ..............................................44
8. Security Considerations 43 11. Normative References ..........................................45
9. IANA Considerations Appendix A. Changes ...............................................47
10. Acknowledgments 44 A.1. Changes to RFC 2251 .......................................47
11. Editor's Address A.2. Changes to RFC 2252 .......................................49
12. References A.3. Changes to RFC 2256 .......................................50
12.1. Normative References 45 A.4. Changes to RFC 3674 .......................................51
12.2. Informative References
Appendix A. Changes
Intellectual Property Rights 51
Full Copyright
1. Introduction 1. Introduction
This document discusses the X.500 Directory Information Models This document discusses the X.500 Directory Information Models
[X.501], as used by the Lightweight Directory Access Protocol (LDAP) [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
[Roadmap]. [RFC4510].
The Directory is "a collection of open systems cooperating to provide The Directory is "a collection of open systems cooperating to provide
directory services" [X.500]. The information held in the Directory is directory services" [X.500]. The information held in the Directory
collectively known as the Directory Information Base (DIB). A is collectively known as the Directory Information Base (DIB). A
Directory user, which may be a human or other entity, accesses the Directory user, which may be a human or other entity, accesses the
Directory through a client (or Directory User Agent (DUA)). The Directory through a client (or Directory User Agent (DUA)). The
client, on behalf of the directory user, interacts with one or more client, on behalf of the directory user, interacts with one or more
servers (or Directory System Agents (DSA)). A server holds a fragment servers (or Directory System Agents (DSA)). A server holds a
of the DIB. fragment of the DIB.
The DIB contains two classes of information: The DIB contains two classes of information:
1) user information (e.g., information provided and administrated 1) user information (e.g., information provided and administrated
by users). Section 2 describes the Model of User Information. by users). Section 2 describes the Model of User Information.
2) administrative and operational information (e.g., information 2) administrative and operational information (e.g., information
used to administer and/or operate the directory). Section 3 used to administer and/or operate the directory). Section 3
describes the model of Directory Administrative and Operational describes the model of Directory Administrative and Operational
Information. Information.
These two models, referred to as the generic Directory Information These two models, referred to as the generic Directory Information
Models, describe how information is represented in the Directory. Models, describe how information is represented in the Directory.
These generic models provide a framework for other information models. These generic models provide a framework for other information
Section 4 discusses the subschema information model and subschema models. Section 4 discusses the subschema information model and
discovery. Section 5 discusses the DSA (Server) Informational Model. subschema discovery. Section 5 discusses the DSA (Server)
Informational Model.
Other X.500 information models, such as access control distribution Other X.500 information models (such as access control distribution
knowledge, and replication knowledge information models, may be knowledge and replication knowledge information models) may be
adapted for use in LDAP. Specification of how these models apply to adapted for use in LDAP. Specification of how these models apply to
LDAP is left to future documents. LDAP is left to future documents.
1.1. Relationship to Other LDAP Specifications 1.1. Relationship to Other LDAP Specifications
This document is a integral part of the LDAP technical specification This document is a 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. specification, RFC 3377, in its entirety.
This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as
portions of sections 4 and 6. Appendix A.1 summarizes changes to portions of Sections 4 and 6. Appendix A.1 summarizes changes to
these sections. The remainder of RFC 2251 is obsoleted by the these sections. The remainder of RFC 2251 is obsoleted by the
[Protocol], [AuthMeth], and [Roadmap] documents. [RFC4511], [RFC4513], and [RFC4510] documents.
This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2 This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2
summarizes changes to these sections. The remainder of RFC 2252 is summarizes changes to these sections. The remainder of RFC 2252 is
obsoleted by [Syntaxes]. obsoleted by [RFC4517].
This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2. This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2.
Appendix A.3 summarizes changes to these sections. The remainder of Appendix A.3 summarizes changes to these sections. The remainder of
RFC 2256 is obsoleted by [Schema] and [Syntaxes]. RFC 2256 is obsoleted by [RFC4519] and [RFC4517].
This document obsoletes RFC 3674 in its entirety. Appendix A.4 This document obsoletes RFC 3674 in its entirety. Appendix A.4
summarizes changes since RFC 3674. summarizes changes since RFC 3674.
1.2. Relationship to X.501 1.2. Relationship to X.501
This document includes material, with and without adaptation, from This document includes material, with and without adaptation, from
[X.501] as necessary to describe this protocol. These adaptations [X.501] as necessary to describe this protocol. These adaptations
(and any other differences herein) apply to this protocol, and only (and any other differences herein) apply to this protocol, and only
this protocol. this protocol.
1.3. Conventions 1.3. 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 BCP 14 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119].
Schema definitions are provided using LDAP description formats (as Schema definitions are provided using LDAP description formats (as
defined in Section 4.1). Definitions provided here are formatted defined in Section 4.1). Definitions provided here are formatted
(line wrapped) for readability. Matching rules and LDAP syntaxes (line wrapped) for readability. Matching rules and LDAP syntaxes
referenced in these definitions are specified in [Syntaxes]. referenced in these definitions are specified in [RFC4517].
1.4. Common ABNF Productions 1.4. Common ABNF Productions
A number of syntaxes in this document are described using Augmented A number of syntaxes in this document are described using Augmented
Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a
number of syntaxes defined in other documents) rely on the following number of syntaxes defined in other documents) rely on the following
common productions: common productions:
keystring = leadkeychar *keychar keystring = leadkeychar *keychar
leadkeychar = ALPHA leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT ) number = DIGIT / ( LDIGIT 1*DIGIT )
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9" DIGIT = %x30 / LDIGIT ; "0"-"9"
skipping to change at page 5, line 36 skipping to change at page 5, line 25
DOT = %x2E ; period (".") DOT = %x2E ; period (".")
SEMI = %x3B ; semicolon (";") SEMI = %x3B ; semicolon (";")
LANGLE = %x3C ; left angle bracket ("<") LANGLE = %x3C ; left angle bracket ("<")
EQUALS = %x3D ; equals sign ("=") EQUALS = %x3D ; equals sign ("=")
RANGLE = %x3E ; right angle bracket (">") RANGLE = %x3E ; right angle bracket (">")
ESC = %x5C ; backslash ("\") ESC = %x5C ; backslash ("\")
USCORE = %x5F ; underscore ("_") USCORE = %x5F ; underscore ("_")
LCURLY = %x7B ; left curly brace "{" LCURLY = %x7B ; left curly brace "{"
RCURLY = %x7D ; right curly brace "}" RCURLY = %x7D ; right curly brace "}"
; Any UTF-8 [UTF-8] encoded Unicode [Unicode] character ; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
UTF8 = UTF1 / UTFMB UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4 UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF UTF0 = %x80-BF
UTF1 = %x00-7F UTF1 = %x00-7F
UTF2 = %xC2-DF UTF0 UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0) %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0) %xF4 %x80-8F 2(UTF0)
skipping to change at page 6, line 12 skipping to change at page 6, line 4
Object identifiers (OIDs) [X.680] are represented in LDAP using a Object identifiers (OIDs) [X.680] are represented in LDAP using a
dot-decimal format conforming to the ABNF: dot-decimal format conforming to the ABNF:
numericoid = number 1*( DOT number ) numericoid = number 1*( DOT number )
Short names, also known as descriptors, are used as more readable Short names, also known as descriptors, are used as more readable
aliases for object identifiers. Short names are case insensitive and aliases for object identifiers. Short names are case insensitive and
conform to the ABNF: conform to the ABNF:
descr = keystring descr = keystring
Where either an object identifier or a short name may be specified, Where either an object identifier or a short name may be specified,
the following production is used: the following production is used:
oid = descr / numericoid oid = descr / numericoid
While the <descr> form is generally preferred when the usage is While the <descr> form is generally preferred when the usage is
restricted to short names referring to object identifiers which restricted to short names referring to object identifiers that
identify like kinds of objects (e.g., attribute type descriptions, identify like kinds of objects (e.g., attribute type descriptions,
matching rule descriptions, object class descriptions), the matching rule descriptions, object class descriptions), the
<numericoid> form should be used when the object identifiers may <numericoid> form should be used when the object identifiers may
identify multiple kinds of objects or when an unambiguous short name identify multiple kinds of objects or when an unambiguous short name
(descriptor) is not available. (descriptor) is not available.
Implementations SHOULD treat short names (descriptors) used in an Implementations SHOULD treat short names (descriptors) used in an
ambiguous manner (as discussed above) as unrecognized. ambiguous manner (as discussed above) as unrecognized.
Short Names (descriptors) are discussed further in Section 6.2. Short Names (descriptors) are discussed further in Section 6.2.
2. Model of Directory User Information 2. Model of Directory User Information
As [X.501] states: As [X.501] states:
The purpose of the Directory is to hold, and provide access to, The purpose of the Directory is to hold, and provide access to,
information about objects of interest (objects) in some 'world'. information about objects of interest (objects) in some 'world'.
An object can be anything which is identifiable (can be named). An object can be anything which is identifiable (can be named).
An object class is an identified family of objects, or conceivable An object class is an identified family of objects, or conceivable
objects, which share certain characteristics. Every object belongs objects, which share certain characteristics. Every object
to at least one class. An object class may be a subclass of other belongs to at least one class. An object class may be a subclass
object classes, in which case the members of the former class, the of other object classes, in which case the members of the former
subclass, are also considered to be members of the latter classes, class, the subclass, are also considered to be members of the
the superclasses. There may be subclasses of subclasses, etc., to latter classes, the superclasses. There may be subclasses of
an arbitrary depth. subclasses, etc., to an arbitrary depth.
A directory entry, a named collection of information, is the basic A directory entry, a named collection of information, is the basic
unit of information held in the Directory. There are multiple kinds unit of information held in the Directory. There are multiple kinds
of directory entries. of directory entries.
An object entry represents a particular object. An alias entry An object entry represents a particular object. An alias entry
provides alternative naming. A subentry holds administrative and/or provides alternative naming. A subentry holds administrative and/or
operational information. operational information.
The set of entries representing the DIB are organized hierarchically The set of entries representing the DIB are organized hierarchically
in a tree structure known as the Directory Information Tree (DIT). in a tree structure known as the Directory Information Tree (DIT).
Section 2.1 describes the Directory Information Tree Section 2.1 describes the Directory Information Tree.
Section 2.2 discusses the structure of entries. Section 2.2 discusses the structure of entries.
Section 2.3 discusses naming of entries. Section 2.3 discusses naming of entries.
Section 2.4 discusses object classes. Section 2.4 discusses object classes.
Section 2.5 discusses attribute descriptions. Section 2.5 discusses attribute descriptions.
Section 2.6 discusses alias entries. Section 2.6 discusses alias entries.
2.1. The Directory Information Tree 2.1. The Directory Information Tree
As noted above, the DIB is composed of a set of entries organized As noted above, the DIB is composed of a set of entries organized
hierarchically in a tree structure known as the Directory Information hierarchically in a tree structure known as the Directory Information
Tree (DIT). Specifically, a tree where vertices are the entries. Tree (DIT); specifically, a tree where vertices are the entries.
The arcs between vertices define relations between entries. If an arc The arcs between vertices define relations between entries. If an
exists from X to Y, then the entry at X is the immediate superior of Y arc exists from X to Y, then the entry at X is the immediate superior
and Y is the immediate subordinate of X. An entry's superiors are the of Y, and Y is the immediate subordinate of X. An entry's superiors
entry's immediate superior and its superiors. An entry's subordinates are the entry's immediate superior and its superiors. An entry's
are all of its immediate subordinates and their subordinates. subordinates are all of its immediate subordinates and their
subordinates.
Similarly, the superior/subordinate relationship between object Similarly, the superior/subordinate relationship between object
entries can be used to derive a relation between the objects they entries can be used to derive a relation between the objects they
represent. DIT structure rules can be used to govern relationships represent. DIT structure rules can be used to govern relationships
between objects. between objects.
Note: An entry's immediate superior is also known as the entry's Note: An entry's immediate superior is also known as the entry's
parent and an entry's immediate subordinate is also known as the parent, and an entry's immediate subordinate is also known as
entry's child. Entries which have the same parent are known as the entry's child. Entries that have the same parent are known
siblings. as siblings.
2.2. Structure of an Entry 2.2. Structure of an Entry
An entry consists of a set of attributes which hold information about An entry consists of a set of attributes that hold information about
the object which the entry represents. Some attributes represent user the object that the entry represents. Some attributes represent user
information and are called user attributes. Other attributes information and are called user attributes. Other attributes
represent operational and/or administrative information and are called represent operational and/or administrative information and are
operational attributes. called operational attributes.
An attribute is an attribute description (a type and zero or more An attribute is an attribute description (a type and zero or more
options) with one or more associated values. An attribute is often options) with one or more associated values. An attribute is often
referred to by its attribute description. For example, the referred to by its attribute description. For example, the
'givenName' attribute is the attribute which consists of the attribute 'givenName' attribute is the attribute that consists of the attribute
description 'givenName' (the 'givenName' attribute type [Schema] and description 'givenName' (the 'givenName' attribute type [RFC4519] and
zero options) and one or more associated values. zero options) and one or more associated values.
The attribute type governs whether the attribute can have multiple The attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used to construct and compare values, the syntax and matching rules used to construct and compare
values of that attribute, and other functions. Options indicate values of that attribute, and other functions. Options indicate
subtypes and other functions. subtypes and other functions.
Attribute values conform to the defined syntax of the attribute type. Attribute values conform to the defined syntax of the attribute type.
No two values of an attribute may be equivalent. Two values are No two values of an attribute may be equivalent. Two values are
considered equivalent if and only if they would match according to the considered equivalent if and only if they would match according to
equality matching rule of the attribute type or, if the attribute type the equality matching rule of the attribute type. Or, if the
is defined with no equality matching rule, two values are equivalent attribute type is defined with no equality matching rule, two values
if and only if they are identical. (See 2.5.1 for other are equivalent if and only if they are identical. (See 2.5.1 for
restrictions.) other restrictions.)
For example, a 'givenName' attribute can have more than one value, For example, a 'givenName' attribute can have more than one value,
they must be Directory Strings, and they are case insensitive. A they must be Directory Strings, and they are case insensitive. A
'givenName' attribute cannot hold both "John" and "JOHN" as these are 'givenName' attribute cannot hold both "John" and "JOHN", as these
equivalent values per the equality matching rule of the attribute are equivalent values per the equality matching rule of the attribute
type. type.
Additionally, no attribute is to have a value which is not equivalent Additionally, no attribute is to have a value that is not equivalent
to itself. For example, the 'givenName' attribute cannot have as a to itself. For example, the 'givenName' attribute cannot have as a
value a directory string which includes the REPLACEMENT CHARACTER value a directory string that includes the REPLACEMENT CHARACTER
(U+FFFD) code point as matching involving that directory string is (U+FFFD) code point, as matching involving that directory string is
Undefined per this attribute's equality matching rule. Undefined per this attribute's equality matching rule.
When an attribute is used for naming of the entry, one and only one When an attribute is used for naming of the entry, one and only one
value of the attribute is used in forming the Relative Distinguished value of the attribute is used in forming the Relative Distinguished
Name. This value is known as a distinguished value. Name. This value is known as a distinguished value.
2.3. Naming of Entries 2.3. Naming of Entries
2.3.1. Relative Distinguished Names 2.3.1. Relative Distinguished Names
Each entry is named relative to its immediate superior. This relative Each entry is named relative to its immediate superior. This
name, known as its Relative Distinguished Name (RDN) [X.501], is relative name, known as its Relative Distinguished Name (RDN)
composed of an unordered set of one or more attribute value assertions [X.501], is composed of an unordered set of one or more attribute
(AVA) consisting of an attribute description with zero options and an value assertions (AVA) consisting of an attribute description with
attribute value. These AVAs are chosen to match attribute values zero options and an attribute value. These AVAs are chosen to match
(each a distinguished value) of the entry. attribute values (each a distinguished value) of the entry.
An entry's relative distinguished name must be unique among all An entry's relative distinguished name must be unique among all
immediate subordinates of the entry's immediate superior (i.e., all immediate subordinates of the entry's immediate superior (i.e., all
siblings). siblings).
The following are examples of string representations of RDNs [LDAPDN]: The following are examples of string representations of RDNs
[RFC4514]:
UID=12345 UID=12345
OU=Engineering OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores CN=Kurt Zeilenga+L=Redwood Shores
The last is an example of a multi-valued RDN. That is, an RDN The last is an example of a multi-valued RDN; that is, an RDN
composed of multiple AVAs. composed of multiple AVAs.
2.3.2. Distinguished Names 2.3.2. Distinguished Names
An entry's fully qualified name, known as its Distinguished Name (DN) An entry's fully qualified name, known as its Distinguished Name (DN)
[X.501], is the concatenation of its RDN and its immediate superior's [X.501], is the concatenation of its RDN and its immediate superior's
DN. A Distinguished Name unambiguously refers to an entry in the DN. A Distinguished Name unambiguously refers to an entry in the
tree. The following are examples of string representations of DNs tree. The following are examples of string representations of DNs
[LDAPDN]: [RFC4514]:
UID=nobody@example.com,DC=example,DC=com UID=nobody@example.com,DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
2.3.3. Alias Names 2.3.3. Alias Names
An alias, or alias name, is "an name for an object, provided by the An alias, or alias name, is "an name for an object, provided by the
use of alias entries" [X.501]. Alias entries are described in Section use of alias entries" [X.501]. Alias entries are described in
2.6. Section 2.6.
2.4. Object Classes 2.4. Object Classes
An object class is "an identified family of objects (or conceivable An object class is "an identified family of objects (or conceivable
objects) which share certain characteristics" [X.501]. objects) that share certain characteristics" [X.501].
As defined in [X.501]: As defined in [X.501]:
Object classes are used in the Directory for a number of purposes: Object classes are used in the Directory for a number of purposes:
- describing and categorising objects and the entries that - describing and categorizing objects and the entries that
correspond to these objects; correspond to these objects;
- where appropriate, controlling the operation of the Directory; - where appropriate, controlling the operation of the Directory;
- regulating, in conjunction with DIT structure rule - regulating, in conjunction with DIT structure rule
specifications, the position of entries in the DIT; specifications, the position of entries in the DIT;
- regulating, in conjunction with DIT content rule - regulating, in conjunction with DIT content rule
specifications, the attributes that are contained in entries; specifications, the attributes that are contained in entries;
- identifying classes of entry that are to be associated with a - identifying classes of entry that are to be associated with a
particular policy by the appropriate administrative authority. particular policy by the appropriate administrative authority.
An object class (a subclass) may be derived from an object class An object class (a subclass) may be derived from an object class
(its direct superclass) which is itself derived from an even more (its direct superclass) which is itself derived from an even more
generic object class. For structural object classes, this process generic object class. For structural object classes, this process
stops at the most generic object class, 'top' (defined in Section stops at the most generic object class, 'top' (defined in Section
skipping to change at page 10, line 26 skipping to change at page 10, line 14
An object class may be derived from two or more direct An object class may be derived from two or more direct
superclasses (superclasses not part of the same superclass chain). superclasses (superclasses not part of the same superclass chain).
This feature of subclassing is termed multiple inheritance. This feature of subclassing is termed multiple inheritance.
Each object class identifies the set of attributes required to be Each object class identifies the set of attributes required to be
present in entries belonging to the class and the set of attributes present in entries belonging to the class and the set of attributes
allowed to be present in entries belonging to the class. As an entry allowed to be present in entries belonging to the class. As an entry
of a class must meet the requirements of each class it belongs to, it of a class must meet the requirements of each class it belongs to, it
can be said that an object class inherits the sets of allowed and can be said that an object class inherits the sets of allowed and
required attributes from its superclasses. A subclass can identify an required attributes from its superclasses. A subclass can identify
attribute allowed by its superclass as being required. If an an attribute allowed by its superclass as being required. If an
attribute is a member of both sets, it is required to be present. attribute is a member of both sets, it is required to be present.
Each object class is defined to be one of three kinds of object Each object class is defined to be one of three kinds of object
classes: Abstract, Structural, or Auxiliary. classes: Abstract, Structural, or Auxiliary.
Each object class is identified by an object identifier (OID) and, Each object class is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors). optionally, one or more short names (descriptors).
2.4.1. Abstract Object Classes 2.4.1. Abstract Object Classes
An abstract object class, as the name implies, provides a base of An abstract object class, as the name implies, provides a base of
characteristics from which other object classes can be defined to characteristics from which other object classes can be defined to
inherit from. An entry cannot belong to an abstract object class inherit from. An entry cannot belong to an abstract object class
unless it belongs to a structural or auxiliary class which inherits unless it belongs to a structural or auxiliary class that inherits
from that abstract class. from that abstract class.
Abstract object classes can not derive from structural nor auxiliary Abstract object classes cannot derive from structural or auxiliary
object classes. object classes.
All structural object classes derive (directly or indirectly) from the All structural object classes derive (directly or indirectly) from
'top' abstract object class. Auxiliary object classes do not the 'top' abstract object class. Auxiliary object classes do not
necessarily derive from 'top'. necessarily derive from 'top'.
The following is the object class definition (see Section 4.1.1) for The following is the object class definition (see Section 4.1.1) for
the 'top' object class: the 'top' object class:
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
All entries belong to the 'top' abstract object class. All entries belong to the 'top' abstract object class.
2.4.2. Structural Object Classes 2.4.2. Structural Object Classes
As stated in [X.501]: As stated in [X.501]:
An object class defined for use in the structural specification of An object class defined for use in the structural specification of
the DIT is termed a structural object class. Structural object the DIT is termed a structural object class. Structural object
classes are used in the definition of the structure of the names classes are used in the definition of the structure of the names
of the objects for compliant entries. of the objects for compliant entries.
An object or alias entry is characterised by precisely one An object or alias entry is characterized by precisely one
structural object class superclass chain which has a single structural object class superclass chain which has a single
structural object class as the most subordinate object class. structural object class as the most subordinate object class.
This structural object class is referred to as the structural This structural object class is referred to as the structural
object class of the entry. object class of the entry.
Structural object classes are related to associated entries: Structural object classes are related to associated entries:
- an entry conforming to a structural object class shall - an entry conforming to a structural object class shall
represent the real-world object constrained by the object represent the real-world object constrained by the object
class; class;
skipping to change at page 11, line 43 skipping to change at page 11, line 36
- DIT structure rules only refer to structural object classes; - DIT structure rules only refer to structural object classes;
the structural object class of an entry is used to specify the the structural object class of an entry is used to specify the
position of the entry in the DIT; position of the entry in the DIT;
- the structural object class of an entry is used, along with an - the structural object class of an entry is used, along with an
associated DIT content rule, to control the content of an associated DIT content rule, to control the content of an
entry. entry.
The structural object class of an entry shall not be changed. The structural object class of an entry shall not be changed.
Each structural object class is a (direct or indirect) subclass of the Each structural object class is a (direct or indirect) subclass of
'top' abstract object class. the 'top' abstract object class.
Structural object classes cannot subclass auxiliary object classes. Structural object classes cannot subclass auxiliary object classes.
Each entry is said to belong to its structural object class as well as Each entry is said to belong to its structural object class as well
all classes in its structural object class's superclass chain. as all classes in its structural object class's superclass chain.
2.4.3. Auxiliary Object Classes 2.4.3. Auxiliary Object Classes
Auxiliary object classes are used to augment the characteristics of Auxiliary object classes are used to augment the characteristics of
entries. They are commonly used to augment the sets of attributes entries. They are commonly used to augment the sets of attributes
required and allowed to be present in an entry. They can be used to required and allowed to be present in an entry. They can be used to
describe entries or classes of entries. describe entries or classes of entries.
Auxiliary object classes cannot subclass structural object classes. Auxiliary object classes cannot subclass structural object classes.
An entry can belong to any subset of the set of auxiliary object An entry can belong to any subset of the set of auxiliary object
classes allowed by the DIT content rule associated with the structural classes allowed by the DIT content rule associated with the
object class of the entry. If no DIT content rule is associated with structural object class of the entry. If no DIT content rule is
the structural object class of the entry, the entry cannot belong to associated with the structural object class of the entry, the entry
any auxiliary object class. cannot belong to any auxiliary object class.
The set of auxiliary object classes which an entry belongs to can The set of auxiliary object classes that an entry belongs to can
change over time. change over time.
2.5. Attribute Descriptions 2.5. Attribute Descriptions
An attribute description is composed of an attribute type (see Section An attribute description is composed of an attribute type (see
2.5.1) and a set of zero or more attribute options (see Section Section 2.5.1) and a set of zero or more attribute options (see
2.5.2). Section 2.5.2).
An attribute description is represented by the ABNF: An attribute description is represented by the ABNF:
attributedescription = attributetype options attributedescription = attributetype options
attributetype = oid attributetype = oid
options = *( SEMI option ) options = *( SEMI option )
option = 1*keychar option = 1*keychar
where <attributetype> identifies the attribute type and each <option> where <attributetype> identifies the attribute type and each <option>
identifies an attribute option. Both <attributetype> and <option> identifies an attribute option. Both <attributetype> and <option>
productions are case insensitive. The order in which <option>s appear productions are case insensitive. The order in which <option>s
is irrelevant. That is, any two <attributedescription>s which consist appear is irrelevant. That is, any two <attributedescription>s that
of the same <attributetype> and same set of <option>s are equivalent. consist of the same <attributetype> and same set of <option>s are
equivalent.
Examples of valid attribute descriptions: Examples of valid attribute descriptions:
2.5.4.0 2.5.4.0
cn;lang-de;lang-en cn;lang-de;lang-en
owner owner
An attribute description with an unrecognized attribute type is to be An attribute description with an unrecognized attribute type is to be
treated as unrecognized. Servers SHALL treat an attribute description treated as unrecognized. Servers SHALL treat an attribute
with an unrecognized attribute option as unrecognized. Clients MAY description with an unrecognized attribute option as unrecognized.
treat an unrecognized attribute option as a tagging option (see Clients MAY treat an unrecognized attribute option as a tagging
Section 2.5.2.1). option (see Section 2.5.2.1).
All attributes of an entry must have distinct attribute descriptions. All attributes of an entry must have distinct attribute descriptions.
2.5.1. Attribute Types 2.5.1. Attribute Types
An attribute type governs whether the attribute can have multiple An attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used to construct and compare values, the syntax and matching rules used to construct and compare
values of that attribute, and other functions. values of that attribute, and other functions.
If no equality matching is specified for the attribute type: If no equality matching is specified for the attribute type:
skipping to change at page 13, line 15 skipping to change at page 13, line 6
All attributes of an entry must have distinct attribute descriptions. All attributes of an entry must have distinct attribute descriptions.
2.5.1. Attribute Types 2.5.1. Attribute Types
An attribute type governs whether the attribute can have multiple An attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used to construct and compare values, the syntax and matching rules used to construct and compare
values of that attribute, and other functions. values of that attribute, and other functions.
If no equality matching is specified for the attribute type: If no equality matching is specified for the attribute type:
- the attribute (of the type) cannot be used for naming; - the attribute (of the type) cannot be used for naming;
- when adding the attribute (or replacing all values), no two values - when adding the attribute (or replacing all values), no two
may be equivalent (see 2.2); values may be equivalent (see 2.2);
- individual values of a multi-valued attribute are not to be - individual values of a multi-valued attribute are not to be
independently added or deleted; independently added or deleted;
- attribute value assertions (such as matching in search filters and - attribute value assertions (such as matching in search filters
comparisons) using values of such a type cannot be performed. and comparisons) using values of such a type cannot be
performed.
Otherwise, the specified equality matching rule is to be used for the Otherwise, the specified equality matching rule is to be used to
purposes of evaluating attribute value assertions concerning the evaluate attribute value assertions concerning the attribute type.
attribute type. The specified equality rule is to be transitive and The specified equality rule is to be transitive and commutative.
commutative.
The attribute type indicates whether the attribute is a user attribute The attribute type indicates whether the attribute is a user
or an operational attribute. If operational, the attribute type attribute or an operational attribute. If operational, the attribute
indicates the operational usage and whether the attribute is type indicates the operational usage and whether or not the attribute
modifiable by users or not. Operational attributes are discussed in is modifiable by users. Operational attributes are discussed in
Section 3.4. Section 3.4.
An attribute type (a subtype) may derive from a more generic attribute An attribute type (a subtype) may derive from a more generic
type (a direct supertype). The following restrictions apply to attribute type (a direct supertype). The following restrictions
subtyping: apply to subtyping:
- a subtype must have the same usage as its direct supertype, - a subtype must have the same usage as its direct supertype,
- a subtype's syntax must be the same, or a refinement of, its - a subtype's syntax must be the same, or a refinement of, its
supertype's syntax, and supertype's syntax, and
- a subtype must be collective [RFC3671] if its supertype is - a subtype must be collective [RFC3671] if its supertype is
collective. collective.
An attribute description consisting of a subtype and no options is An attribute description consisting of a subtype and no options is
said to be the direct description subtype of the attribute description said to be the direct description subtype of the attribute
consisting of the subtype's direct supertype and no options. description consisting of the subtype's direct supertype and no
options.
Each attribute type is identified by an object identifier (OID) and, Each attribute type is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors). optionally, one or more short names (descriptors).
2.5.2. Attribute Options 2.5.2. Attribute Options
There are multiple kinds of attribute description options. The LDAP There are multiple kinds of attribute description options. The LDAP
technical specification details one kind: tagging options. technical specification details one kind: tagging options.
Not all options can be associated with attributes held in the Not all options can be associated with attributes held in the
skipping to change at page 14, line 30 skipping to change at page 14, line 22
unrecognized. unrecognized.
Other kinds of options may be specified in future documents. These Other kinds of options may be specified in future documents. These
documents must detail how new kinds of options they define relate to documents must detail how new kinds of options they define relate to
tagging options. In particular, these documents must detail whether tagging options. In particular, these documents must detail whether
or not new kinds of options can be associated with attributes held in or not new kinds of options can be associated with attributes held in
the directory, how new kinds of options affect transfer of attribute the directory, how new kinds of options affect transfer of attribute
values, and how new kinds of options are treated in attribute values, and how new kinds of options are treated in attribute
description hierarchies. description hierarchies.
Options are represented as short case insensitive textual strings Options are represented as short, case-insensitive textual strings
conforming to the <option> production defined in Section 2.5 of this conforming to the <option> production defined in Section 2.5 of this
document. document.
Procedures for registering options are detailed in BCP 64 [BCP64bis]. Procedures for registering options are detailed in BCP 64, RFC 4520
[RFC4520].
2.5.2.1. Tagging Options 2.5.2.1. Tagging Options
Attributes held in the directory can have attribute descriptions with Attributes held in the directory can have attribute descriptions with
any number of tagging options. Tagging options are never mutually any number of tagging options. Tagging options are never mutually
exclusive. exclusive.
An attribute description with N tagging options is a direct An attribute description with N tagging options is a direct
(description) subtype of all attribute descriptions of the same (description) subtype of all attribute descriptions of the same
attribute type and all but one of the N options. If the attribute attribute type and all but one of the N options. If the attribute
type has a supertype, then the attribute description is also a direct type has a supertype, then the attribute description is also a direct
(description) subtype of the attribute description of the supertype (description) subtype of the attribute description of the supertype
and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
(description) subtype of 'cn;lang-de', 'cn;lang-en', and (description) subtype of 'cn;lang-de', 'cn;lang-en', and
'name;lang-de;lang-en' ('cn' is a subtype of 'name', both are defined 'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined
in [Schema]). in [RFC4519]).
2.5.3. Attribute Description Hierarchies 2.5.3. Attribute Description Hierarchies
An attribute description can be the direct subtype of zero or more An attribute description can be the direct subtype of zero or more
other attribute descriptions as indicated by attribute type subtyping other attribute descriptions as indicated by attribute type subtyping
(as described in Section 2.5.1) or attribute tagging option subtyping (as described in Section 2.5.1) or attribute tagging option subtyping
(as described in Section 2.5.2.1). These subtyping relationships are (as described in Section 2.5.2.1). These subtyping relationships are
used to form hierarchies of attribute descriptions and attributes. used to form hierarchies of attribute descriptions and attributes.
As adapted from [X.501]: As adapted from [X.501]:
Attribute hierarchies allow access to the DIB with varying degrees Attribute hierarchies allow access to the DIB with varying degrees
of granularity. This is achieved by allowing the value components of granularity. This is achieved by allowing the value components
of attributes to be accessed by using either their specific of attributes to be accessed by using either their specific
attribute description (a direct reference to the attribute) or by attribute description (a direct reference to the attribute) or a
a more generic attribute description (an indirect reference). more generic attribute description (an indirect reference).
Semantically related attributes may be placed in a hierarchical Semantically related attributes may be placed in a hierarchical
relationship, the more specialized being placed subordinate to the relationship, the more specialized being placed subordinate to the
more generalized. Searching for, or retrieving attributes and more generalized. Searching for or retrieving attributes and
their values is made easier by quoting the more generalized their values is made easier by quoting the more generalized
attribute description; a filter item so specified is evaluated for attribute description; a filter item so specified is evaluated for
the more specialized descriptions as well as for the quoted the more specialized descriptions as well as for the quoted
description. description.
Where subordinate specialized descriptions are selected to be Where subordinate specialized descriptions are selected to be
returned as part of a search result these descriptions shall be returned as part of a search result these descriptions shall be
returned if available. Where the more general descriptions are returned if available. Where the more general descriptions are
selected to be returned as part of a search result both the selected to be returned as part of a search result both the
general and the specialized descriptions shall be returned, if general and the specialized descriptions shall be returned, if
skipping to change at page 15, line 47 skipping to change at page 15, line 39
All of the attribute descriptions in an attribute hierarchy are All of the attribute descriptions in an attribute hierarchy are
treated as distinct and unrelated descriptions for user treated as distinct and unrelated descriptions for user
modification of entry content. modification of entry content.
An attribute value stored in an object or alias entry is of An attribute value stored in an object or alias entry is of
precisely one attribute description. The description is indicated precisely one attribute description. The description is indicated
when the value is originally added to the entry. when the value is originally added to the entry.
For the purpose of subschema administration of the entry, a For the purpose of subschema administration of the entry, a
specification that an attribute is required is fulfilled if the entry specification that an attribute is required is fulfilled if the entry
contains a value of an attribute description belonging to an attribute contains a value of an attribute description belonging to an
hierarchy where the attribute type of that description is the same as attribute hierarchy where the attribute type of that description is
the required attribute's type. That is, a "MUST name" specification the same as the required attribute's type. That is, a "MUST name"
is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by specification is fulfilled by 'name' or 'name;x-tag-option', but is
'CN' nor by 'CN;x-tag-option' (even though 'CN' is a subtype of not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a
'name'). Likewise, an entry may contain a value of an attribute subtype of 'name'). Likewise, an entry may contain a value of an
description belonging to an attribute hierarchy where the attribute attribute description belonging to an attribute hierarchy where the
type of that description is either explicitly included in the attribute type of that description is either explicitly included in
definition of an object class to which the entry belongs or allowed by the definition of an object class to which the entry belongs or
the DIT content rule applicable to that entry. That is, 'name' and allowed by the DIT content rule applicable to that entry. That is,
'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but 'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (nor by "MUST name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
name"). (or by "MUST name").
For the purposes of other policy administration, unless stated For the purposes of other policy administration, unless stated
otherwise in the specification of the particular administrative model, otherwise in the specification of the particular administrative
all of the attribute descriptions in an attribute hierarchy are model, all of the attribute descriptions in an attribute hierarchy
treated as distinct and unrelated descriptions. are treated as distinct and unrelated descriptions.
2.6. Alias Entries 2.6. Alias Entries
As adapted from [X.501]: As adapted from [X.501]:
An alias, or an alias name, for an object is an alternative name An alias, or an alias name, for an object is an alternative name
for an object or object entry which is provided by the use of for an object or object entry which is provided by the use of
alias entries. alias entries.
Each alias entry contains, within the 'aliasedObjectName' Each alias entry contains, within the 'aliasedObjectName'
attribute (known as the 'aliasedEntryName' attribute in X.500]), a attribute (known as the 'aliasedEntryName' attribute in X.500), a
name of some object. The distinguished name of the alias entry is name of some object. The distinguished name of the alias entry is
thus also a name for this object. thus also a name for this object.
NOTE - The name within the 'aliasedObjectName' is said to be NOTE - The name within the 'aliasedObjectName' is said to be
pointed to by the alias. It does not have to be the pointed to by the alias. It does not have to be the
distinguished name of any entry. distinguished name of any entry.
The conversion of an alias name to an object name is termed The conversion of an alias name to an object name is termed
(alias) dereferencing and comprises the systematic replacement of (alias) dereferencing and comprises the systematic replacement of
alias names, where found within a purported name, by the value of alias names, where found within a purported name, by the value of
skipping to change at page 17, line 4 skipping to change at page 16, line 44
It therefore follows that several alias entries may point to the It therefore follows that several alias entries may point to the
same entry. An alias entry may point to an entry that is not a same entry. An alias entry may point to an entry that is not a
leaf entry and may point to another alias entry. leaf entry and may point to another alias entry.
An alias entry shall have no subordinates, so that an alias entry An alias entry shall have no subordinates, so that an alias entry
is always a leaf entry. is always a leaf entry.
Every alias entry shall belong to the 'alias' object class. Every alias entry shall belong to the 'alias' object class.
An entry with the 'alias' object class must also belong to an object An entry with the 'alias' object class must also belong to an object
class (or classes), or be governed by a DIT content rule, which allows class (or classes), or be governed by a DIT content rule, which
suitable naming attributes to be present. allows suitable naming attributes to be present.
Example: Example:
dn: cn=bar,dc=example,dc=com dn: cn=bar,dc=example,dc=com
objectClass: top objectClass: top
objectClass: alias objectClass: alias
objectClass: extensibleObject objectClass: extensibleObject
cn: bar cn: bar
aliasedObjectName: cn=foo,dc=example,dc=com aliasedObjectName: cn=foo,dc=example,dc=com
2.6.1. 'alias' object class 2.6.1. 'alias' Object Class
Alias entries belong to the 'alias' object class. Alias entries belong to the 'alias' object class.
( 2.5.6.1 NAME 'alias' ( 2.5.6.1 NAME 'alias'
SUP top STRUCTURAL SUP top STRUCTURAL
MUST aliasedObjectName ) MUST aliasedObjectName )
2.6.2. 'aliasedObjectName' attribute type 2.6.2. 'aliasedObjectName' Attribute Type
The 'aliasedObjectName' attribute holds the name of the entry an alias The 'aliasedObjectName' attribute holds the name of the entry an
points to. The 'aliasedObjectName' attribute is known as the alias points to. The 'aliasedObjectName' attribute is known as the
'aliasedEntryName' attribute in X.500. 'aliasedEntryName' attribute in X.500.
( 2.5.4.1 NAME 'aliasedObjectName' ( 2.5.4.1 NAME 'aliasedObjectName'
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
SINGLE-VALUE ) SINGLE-VALUE )
The 'distinguishedNameMatch' matching rule and the DistinguishedName The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
3. Directory Administrative and Operational Information 3. Directory Administrative and Operational Information
This section discusses select aspects of the X.500 Directory This section discusses select aspects of the X.500 Directory
Administrative and Operational Information model [X.501]. LDAP Administrative and Operational Information model [X.501]. LDAP
implementations MAY support other aspects of this model. implementations MAY support other aspects of this model.
3.1. Subtrees 3.1. Subtrees
As defined in [X.501]: As defined in [X.501]:
skipping to change at page 18, line 28 skipping to change at page 18, line 19
[X.501]. Subentries are used in Directory to hold for administrative [X.501]. Subentries are used in Directory to hold for administrative
and operational purposes as defined in [X.501]. Their use in LDAP is and operational purposes as defined in [X.501]. Their use in LDAP is
detailed in [RFC3672]. detailed in [RFC3672].
The term "(sub)entry" in this specification indicates that servers The term "(sub)entry" in this specification indicates that servers
implementing X.500(93) models are, in accordance with X.500(93) as implementing X.500(93) models are, in accordance with X.500(93) as
described in [RFC3672], to use a subentry and that other servers are described in [RFC3672], to use a subentry and that other servers are
to use an object entry belonging to the appropriate auxiliary class to use an object entry belonging to the appropriate auxiliary class
normally used with the subentry (e.g., 'subschema' for subschema normally used with the subentry (e.g., 'subschema' for subschema
subentries) to mimic the subentry. This object entry's RDN SHALL be subentries) to mimic the subentry. This object entry's RDN SHALL be
formed from a value of the 'cn' (commonName) attribute [Schema] (as formed from a value of the 'cn' (commonName) attribute [RFC4519] (as
all subentries are named with 'cn'). all subentries are named with 'cn').
3.3. The 'objectClass' attribute 3.3. The 'objectClass' attribute
Each entry in the DIT has an 'objectClass' attribute. Each entry in the DIT has an 'objectClass' attribute.
( 2.5.4.0 NAME 'objectClass' ( 2.5.4.0 NAME 'objectClass'
EQUALITY objectIdentifierMatch EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
(1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
The 'objectClass' attribute specifies the object classes of an entry, The 'objectClass' attribute specifies the object classes of an entry,
which (among other things) is used in conjunction with the controlling which (among other things) are used in conjunction with the
schema to determine the permitted attributes of an entry. Values of controlling schema to determine the permitted attributes of an entry.
this attribute can be modified by clients, but the 'objectClass' Values of this attribute can be modified by clients, but the
attribute cannot be removed. 'objectClass' attribute cannot be removed.
Servers which follow X.500(93) models SHALL restrict modifications of Servers that follow X.500(93) models SHALL restrict modifications of
this attribute to prevent the basic structural class of the entry from this attribute to prevent the basic structural class of the entry
being changed. That is, one cannot change a 'person' into a from being changed. That is, one cannot change a 'person' into a
'country'. 'country'.
When creating an entry or adding an 'objectClass' value to an entry, When creating an entry or adding an 'objectClass' value to an entry,
all superclasses of the named classes SHALL be implicitly added as all superclasses of the named classes SHALL be implicitly added as
well if not already present. That is, if the auxiliary class 'x-a' is well if not already present. That is, if the auxiliary class 'x-a'
a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes is a subclass of the class 'x-b', adding 'x-a' to 'objectClass'
'x-b' to be implicitly added (if is not already present). causes 'x-b' to be implicitly added (if is not already present).
Servers SHALL restrict modifications of this attribute to prevent Servers SHALL restrict modifications of this attribute to prevent
superclasses of remaining 'objectClass' values from being deleted. superclasses of remaining 'objectClass' values from being deleted.
That is, if the auxiliary class 'x-a' is a subclass of the auxiliary That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b', class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
an attempt to delete only 'x-b' from the 'objectClass' attribute is an an attempt to delete only 'x-b' from the 'objectClass' attribute is
error. an error.
3.4. Operational attributes 3.4. Operational Attributes
Some attributes, termed operational attributes, are used or maintained Some attributes, termed operational attributes, are used or
by servers for administrative and operational purposes. As stated in maintained by servers for administrative and operational purposes.
[X.501]: "There are three varieties of operational attributes: As stated in [X.501]: "There are three varieties of operational
Directory operational attributes, DSA-shared operational attributes, attributes: Directory operational attributes, DSA-shared operational
and DSA-specific operational attributes." attributes, and DSA-specific operational attributes".
A directory operational attribute is used to represent operational A directory operational attribute is used to represent operational
and/or administrative information in the Directory Information Model. and/or administrative information in the Directory Information Model.
This includes operational attributes maintained by the server (e.g. This includes operational attributes maintained by the server (e.g.,
'createTimestamp') as well as operational attributes which hold values 'createTimestamp') as well as operational attributes that hold values
administrated by the user (e.g. 'ditContentRules'). administrated by the user (e.g., 'ditContentRules').
A DSA-shared operational attribute is used to represent information of A DSA-shared operational attribute is used to represent information
the DSA Information Model which is shared between DSAs. of the DSA Information Model that is shared between DSAs.
A DSA-specific operational attribute is used to represent information A DSA-specific operational attribute is used to represent information
of the DSA Information Model which is specific to the DSA (though, in of the DSA Information Model that is specific to the DSA (though, in
some cases, may be derived from information shared between DSAs) some cases, may be derived from information shared between DSAs;
(e.g., 'namingContexts'). e.g., 'namingContexts').
The DSA Information Model operational attributes are detailed in The DSA Information Model operational attributes are detailed in
[X.501]. [X.501].
Operational attributes are not normally visible. They are not Operational attributes are not normally visible. They are not
returned in search results unless explicitly requested by name. returned in search results unless explicitly requested by name.
Not all operational attributes are user modifiable. Not all operational attributes are user modifiable.
Entries may contain, among others, the following operational Entries may contain, among others, the following operational
skipping to change at page 20, line 22 skipping to change at page 20, line 11
modified this entry, and modified this entry, and
- modifyTimestamp: the time this entry was last modified. - modifyTimestamp: the time this entry was last modified.
Servers SHOULD maintain the 'creatorsName', 'createTimestamp', Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
'modifiersName', and 'modifyTimestamp' attributes for all entries of 'modifiersName', and 'modifyTimestamp' attributes for all entries of
the DIT. the DIT.
3.4.1. 'creatorsName' 3.4.1. 'creatorsName'
This attribute appears in entries which were added using the protocol This attribute appears in entries that were added using the protocol
(e.g., using the Add operation). The value is the distinguished name (e.g., using the Add operation). The value is the distinguished name
of the creator. of the creator.
( 2.5.18.3 NAME 'creatorsName' ( 2.5.18.3 NAME 'creatorsName'
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
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
3.4.2. 'createTimestamp' 3.4.2. 'createTimestamp'
This attribute appears in entries which were added using the protocol This attribute appears in entries that were added using the protocol
(e.g., using the Add operation). The value is the time the entry was (e.g., using the Add operation). The value is the time the entry was
added. added.
( 2.5.18.1 NAME 'createTimestamp' ( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax matching rules and the GeneralizedTime
are defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
3.4.3. 'modifiersName' 3.4.3. 'modifiersName'
This attribute appears in entries which have been modified using the This attribute appears in entries that have been modified using the
protocol (e.g., using Modify operation). The value is the protocol (e.g., using the Modify operation). The value is the
distinguished name of the last modifier. distinguished name of the last modifier.
( 2.5.18.4 NAME 'modifiersName' ( 2.5.18.4 NAME 'modifiersName'
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
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
3.4.4. 'modifyTimestamp' 3.4.4. 'modifyTimestamp'
This attribute appears in entries which have been modified using the This attribute appears in entries that have been modified using the
protocol (e.g., using the Modify operation). The value is the time protocol (e.g., using the Modify operation). The value is the time
the entry was last modified. the entry was last modified.
( 2.5.18.2 NAME 'modifyTimestamp' ( 2.5.18.2 NAME 'modifyTimestamp'
EQUALITY generalizedTimeMatch EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax matching rules and the GeneralizedTime
are defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
3.4.5. 'structuralObjectClass' 3.4.5. 'structuralObjectClass'
This attribute indicates the structural object class of the entry. This attribute indicates the structural object class of the entry.
( 2.5.21.9 NAME 'structuralObjectClass' ( 2.5.21.9 NAME 'structuralObjectClass'
EQUALITY objectIdentifierMatch EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
(1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
3.4.6. 'governingStructureRule' 3.4.6. 'governingStructureRule'
This attribute indicates the structure rule governing the entry. This attribute indicates the structure rule governing the entry.
( 2.5.21.10 NAME 'governingStructureRule' ( 2.5.21.10 NAME 'governingStructureRule'
EQUALITY integerMatch EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The 'integerMatch' matching rule and INTEGER The 'integerMatch' matching rule and INTEGER
(1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
4. Directory Schema 4. Directory Schema
As defined in [X.501]: As defined in [X.501]:
The Directory Schema is a set of definitions and constraints The Directory Schema is a set of definitions and constraints
concerning the structure of the DIT, the possible ways entries are concerning the structure of the DIT, the possible ways entries are
named, the information that can be held in an entry, the named, the information that can be held in an entry, the
attributes used to represent that information and their attributes used to represent that information and their
organization into hierarchies to facilitate search and retrieval organization into hierarchies to facilitate search and retrieval
of the information and the ways in which values of attributes may of the information and the ways in which values of attributes may
be matched in attribute value and matching rule assertions. be matched in attribute value and matching rule assertions.
NOTE 1 - The schema enables the Directory system to, for example: NOTE 1 - The schema enables the Directory system to, for example:
- prevent the creation of subordinate entries of the wrong - prevent the creation of subordinate entries of the wrong
object-class (e.g. a country as a subordinate of a person); object-class (e.g., a country as a subordinate of a person);
- prevent the addition of attribute-types to an entry - prevent the addition of attribute-types to an entry
inappropriate to the object-class (e.g. a serial number to a inappropriate to the object-class (e.g., a serial number to a
person's entry); person's entry);
- prevent the addition of an attribute value of a syntax not - prevent the addition of an attribute value of a syntax not
matching that defined for the attribute-type (e.g. a printable matching that defined for the attribute-type (e.g., a printable
string to a bit string). string to a bit string).
Formally, the Directory Schema comprises a set of: Formally, the Directory Schema comprises a set of:
a) Name Form definitions that define primitive naming relations a) Name Form definitions that define primitive naming relations
for structural object classes; for structural object classes;
b) DIT Structure Rule definitions that define the names that b) DIT Structure Rule definitions that define the names that
entries may have and the ways in which the entries may be entries may have and the ways in which the entries may be
related to one another in the DIT; related to one another in the DIT;
skipping to change at page 24, line 4 skipping to change at page 23, line 39
xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE ) xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN ) qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( SP qdescr ) ] qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE qdescr = SQUOTE descr SQUOTE
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN ) qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ] qdstringlist = [ qdstring *( SP qdstring ) ]
qdstring = SQUOTE dstring SQUOTE qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
QQ = ESC %x32 %x37 ; "\27" QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c" QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
; Any UTF-8 encoded Unicode character ; Any UTF-8 encoded Unicode character
; except %x27 ("'") and %x5C ("\") ; except %x27 ("\'") and %x5C ("\")
QUTF8 = QUTF1 / UTFMB QUTF8 = QUTF1 / UTFMB
; Any ASCII character except %x27 ("'") and %x5C ("\") ; Any ASCII character except %x27 ("\'") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F QUTF1 = %x00-26 / %x28-5B / %x5D-7F
Schema definitions in this section also share a number of common Schema definitions in this section also share a number of common
terms. terms.
The NAME field provides a set of short names (descriptors) which are The NAME field provides a set of short names (descriptors) that are
to be used as aliases for the OID. to be used as aliases for the OID.
The DESC field optionally allows a descriptive string to be provided The DESC field optionally allows a descriptive string to be provided
by the directory administrator and/or implementor. While by the directory administrator and/or implementor. While
specifications may suggest a descriptive string, there is no specifications may suggest a descriptive string, there is no
requirement that the suggested (or any) descriptive string be used. requirement that the suggested (or any) descriptive string be used.
The OBSOLETE field, if present, indicates the element is not active. The OBSOLETE field, if present, indicates the element is not active.
Implementors should note that future versions of this document may Implementors should note that future versions of this document may
expand these definitions to include additional terms. Terms whose expand these definitions to include additional terms. Terms whose
identifier begins with "X-" are reserved for private experiments, and identifier begins with "X-" are reserved for private experiments and
are followed by <SP> and <qdstrings> tokens. are followed by <SP> and <qdstrings> tokens.
4.1.1. Object Class Definitions 4.1.1. Object Class Definitions
Object Class definitions are written according to the ABNF: Object Class definitions are written according to the ABNF:
ObjectClassDescription = LPAREN WSP ObjectClassDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
skipping to change at page 25, line 4 skipping to change at page 24, line 39
[ SP "SUP" SP oids ] ; superior object classes [ SP "SUP" SP oids ] ; superior object classes
[ SP kind ] ; kind of class [ SP kind ] ; kind of class
[ SP "MUST" SP oids ] ; attribute types [ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN extensions WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
where: where:
<numericoid> is object identifier assigned to this object class; <numericoid> is object identifier assigned to this object class;
NAME <qdescrs> are short names (descriptors) identifying this object NAME <qdescrs> are short names (descriptors) identifying this
class; object class;
DESC <qdstring> is a short descriptive string; DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this object class is not active; OBSOLETE indicates this object class is not active;
SUP <oids> specifies the direct superclasses of this object class; SUP <oids> specifies the direct superclasses of this object class;
the kind of object class is indicated by one of ABSTRACT, the kind of object class is indicated by one of ABSTRACT,
STRUCTURAL, or AUXILIARY, default is STRUCTURAL; STRUCTURAL, or AUXILIARY (the default is STRUCTURAL);
MUST and MAY specify the sets of required and allowed attribute MUST and MAY specify the sets of required and allowed attribute
types, respectively; and types, respectively; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.2. Attribute Types 4.1.2. Attribute Types
Attribute Type definitions are written according to the ABNF: Attribute Type definitions are written according to the ABNF:
AttributeTypeDescription = LPAREN WSP AttributeTypeDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
skipping to change at page 25, line 47 skipping to change at page 25, line 37
"distributedOperation" / ; DSA-shared operational "distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operational "dSAOperation" ; DSA-specific operational
where: where:
<numericoid> is object identifier assigned to this attribute type; <numericoid> is object identifier assigned to this attribute type;
NAME <qdescrs> are short names (descriptors) identifying this NAME <qdescrs> are short names (descriptors) identifying this
attribute type; attribute type;
DESC <qdstring> is a short descriptive string; DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this attribute type is not active; OBSOLETE indicates this attribute type is not active;
SUP oid specifies the direct supertype of this type; SUP oid specifies the direct supertype of this type;
EQUALITY, ORDERING, SUBSTR provide the oid of the equality, EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
ordering, and substrings matching rules, respectively; ordering, and substrings matching rules, respectively;
SYNTAX identifies value syntax by object identifier and may suggest SYNTAX identifies value syntax by object identifier and may suggest
a minimum upper bound; a minimum upper bound;
SINGLE-VALUE indicates attributes of this type are restricted to a SINGLE-VALUE indicates attributes of this type are restricted to a
single value; single value;
COLLECTIVE indicates this attribute type is collective COLLECTIVE indicates this attribute type is collective
[X.501][RFC3671]; [X.501][RFC3671];
NO-USER-MODIFICATION indicates this attribute type is not user NO-USER-MODIFICATION indicates this attribute type is not user
modifiable; modifiable;
USAGE indicates the application of this attribute type; and USAGE indicates the application of this attribute type; and
skipping to change at page 26, line 26 skipping to change at page 26, line 14
If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
fields, if not specified, take their value from the supertype. fields, if not specified, take their value from the supertype.
Usage of userApplications, the default, indicates that attributes of Usage of userApplications, the default, indicates that attributes of
this type represent user information. That is, they are user this type represent user information. That is, they are user
attributes. attributes.
A usage of directoryOperation, distributedOperation, or dSAOperation A usage of directoryOperation, distributedOperation, or dSAOperation
indicates that attributes of this type represent operational and/or indicates that attributes of this type represent operational and/or
administrative information. That is, they are operational attributes. administrative information. That is, they are operational
attributes.
directoryOperation usage indicates that the attribute of this type is directoryOperation usage indicates that the attribute of this type is
a directory operational attribute. distributedOperation usage a directory operational attribute. distributedOperation usage
indicates that the attribute of this DSA-shared usage operational indicates that the attribute of this type is a DSA-shared usage
attribute. dSAOperation usage indicates that the attribute of this operational attribute. dSAOperation usage indicates that the
type is a DSA-specific operational attribute. attribute of this type is a DSA-specific operational attribute.
COLLECTIVE requires usage userApplications. Use of collective COLLECTIVE requires usage userApplications. Use of collective
attribute types in LDAP is discussed in [RFC3671]. attribute types in LDAP is discussed in [RFC3671].
NO-USER-MODIFICATION requires an operational usage. NO-USER-MODIFICATION requires an operational usage.
Note that the <AttributeTypeDescription> does not list the matching Note that the <AttributeTypeDescription> does not list the matching
rules which can be used with that attribute type in an extensibleMatch rules that can be used with that attribute type in an extensibleMatch
search filter [Protocol]. This is done using the 'matchingRuleUse' search filter [RFC4511]. This is done using the 'matchingRuleUse'
attribute described in Section 4.1.4. attribute described in Section 4.1.4.
This document refines the schema description of X.501 by requiring This document refines the schema description of X.501 by requiring
that the SYNTAX field in an <AttributeTypeDescription> be a string that the SYNTAX field in an <AttributeTypeDescription> be a string
representation of an object identifier for the LDAP string syntax representation of an object identifier for the LDAP string syntax
definition with an optional indication of the suggested minimum bound definition, with an optional indication of the suggested minimum
of a value of this attribute. bound of a value of this attribute.
A suggested minimum upper bound on the number of characters in a value A suggested minimum upper bound on the number of characters in a
with a string-based syntax, or the number of bytes in a value for all value with a string-based syntax, or the number of bytes in a value
other syntaxes, may be indicated by appending this bound count inside for all other syntaxes, may be indicated by appending this bound
of curly braces following the syntax's OBJECT IDENTIFIER in an count inside of curly braces following the syntax's OBJECT IDENTIFIER
Attribute Type Description. This bound is not part of the syntax name in an Attribute Type Description. This bound is not part of the
itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server syntax name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests
implementations should allow a string to be 64 characters long, that server implementations should allow a string to be 64 characters
although they may allow longer strings. Note that a single character long, although they may allow longer strings. Note that a single
of the Directory String syntax may be encoded in more than one octet character of the Directory String syntax may be encoded in more than
since UTF-8 [RFC3629] is a variable-length encoding. one octet since UTF-8 [RFC3629] is a variable-length encoding.
4.1.3. Matching Rules 4.1.3. Matching Rules
Matching rules are used in performance of attribute value assertions, Matching rules are used in performance of attribute value assertions,
such as in performance of a Compare operation. They are also used in such as in performance of a Compare operation. They are also used in
evaluation of a Search filters, in determining which individual values evaluating search filters, determining which individual values are to
are be added or deleted during performance of a Modify operation, and be added or deleted during performance of a Modify operation, and in
used in comparison of distinguished names. comparing distinguished names.
Each matching rule is identified by an object identifier (OID) and, Each matching rule is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors). optionally, one or more short names (descriptors).
Matching rule definitions are written according to the ABNF: Matching rule definitions are written according to the ABNF:
MatchingRuleDescription = LPAREN WSP MatchingRuleDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
skipping to change at page 27, line 46 skipping to change at page 27, line 38
NAME <qdescrs> are short names (descriptors) identifying this NAME <qdescrs> are short names (descriptors) identifying this
matching rule; matching rule;
DESC <qdstring> is a short descriptive string; DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this matching rule is not active; OBSOLETE indicates this matching rule is not active;
SYNTAX identifies the assertion syntax (the syntax of the assertion SYNTAX identifies the assertion syntax (the syntax of the assertion
value) by object identifier; and value) by object identifier; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.4. Matching Rule Uses 4.1.4. Matching Rule Uses
A matching rule use lists the attribute types which are suitable for A matching rule use lists the attribute types that are suitable for
use with an extensibleMatch search filter. use with an extensibleMatch search filter.
Matching rule use descriptions are written according to the following Matching rule use descriptions are written according to the following
ABNF: ABNF:
MatchingRuleUseDescription = LPAREN WSP MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
skipping to change at page 28, line 13 skipping to change at page 28, line 4
Matching rule use descriptions are written according to the following Matching rule use descriptions are written according to the following
ABNF: ABNF:
MatchingRuleUseDescription = LPAREN WSP MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "APPLIES" SP oids ; attribute types SP "APPLIES" SP oids ; attribute types
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
<numericoid> is the object identifier of the matching rule <numericoid> is the object identifier of the matching rule
associated with this matching rule use description; associated with this matching rule use description;
NAME <qdescrs> are short names (descriptors) identifying this NAME <qdescrs> are short names (descriptors) identifying this
matching rule use; matching rule use;
DESC <qdstring> is a short descriptive string; DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this matching rule use is not active; OBSOLETE indicates this matching rule use is not active;
APPLIES provides a list of attribute types the matching rule applies APPLIES provides a list of attribute types the matching rule
to; and applies to; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.5. LDAP Syntaxes 4.1.5. LDAP Syntaxes
LDAP Syntaxes of (attribute and assertion) values are described in LDAP Syntaxes of (attribute and assertion) values are described in
terms of ASN.1 [X.680] and, optionally, have an octet string encoding terms of ASN.1 [X.680] and, optionally, have an octet string encoding
known as the LDAP-specific encoding. Commonly, the LDAP-specific known as the LDAP-specific encoding. Commonly, the LDAP-specific
encoding is constrained to a string of Unicode [Unicode] characters in encoding is constrained to a string of Unicode [Unicode] characters
UTF-8 [RFC3629] form. in UTF-8 [RFC3629] form.
Each LDAP syntax is identified by an object identifier (OID). Each LDAP syntax is identified by an object identifier (OID).
LDAP syntax definitions are written according to the ABNF: LDAP syntax definitions are written according to the ABNF:
SyntaxDescription = LPAREN WSP SyntaxDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
<numericoid> is the object identifier assigned to this LDAP syntax; <numericoid> is the object identifier assigned to this LDAP syntax;
DESC <qdstring> is a short descriptive string; and DESC <qdstring> is a short descriptive string; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.6. DIT Content Rules 4.1.6. DIT Content Rules
A DIT content rule is a "rule governing the content of entries of a A DIT content rule is a "rule governing the content of entries of a
particular structural object class" [X.501]. particular structural object class" [X.501].
For DIT entries of a particular structural object class, a DIT content For DIT entries of a particular structural object class, a DIT
rule specifies which auxiliary object classes the entries are allowed content rule specifies which auxiliary object classes the entries are
to belong to and which additional attributes (by type) are required, allowed to belong to and which additional attributes (by type) are
allowed or not allowed to appear in the entries. required, allowed, or not allowed to appear in the entries.
The list of precluded attributes cannot include any attribute listed The list of precluded attributes cannot include any attribute listed
as mandatory in the rule, the structural object class, or any of the as mandatory in the rule, the structural object class, or any of the
allowed auxiliary object classes. allowed auxiliary object classes.
Each content rule is identified by the object identifier, as well as Each content rule is identified by the object identifier, as well as
any short names (descriptors), of the structural object class it any short names (descriptors), of the structural object class it
applies to. applies to.
An entry may only belong to auxiliary object classes listed in the An entry may only belong to auxiliary object classes listed in the
skipping to change at page 29, line 34 skipping to change at page 29, line 24
governing content rule. governing content rule.
An entry may contain any non-precluded attributes allowed by the An entry may contain any non-precluded attributes allowed by the
object classes the entry belongs to as well as all attributes allowed object classes the entry belongs to as well as all attributes allowed
by the governing content rule. by the governing content rule.
An entry cannot include any attribute precluded by the governing An entry cannot include any attribute precluded by the governing
content rule. content rule.
An entry is governed by (if present and active in the subschema) the An entry is governed by (if present and active in the subschema) the
DIT content rule which applies to the structural object class of the DIT content rule that applies to the structural object class of the
entry (see Section 2.4.2). If no active rule is present for the entry (see Section 2.4.2). If no active rule is present for the
entry's structural object class, the entry's content is governed by entry's structural object class, the entry's content is governed by
the structural object class (and possibly other aspects of user and the structural object class (and possibly other aspects of user and
system schema). DIT content rules for superclasses of the structural system schema). DIT content rules for superclasses of the structural
object class of an entry are not applicable to that entry. object class of an entry are not applicable to that entry.
DIT content rule descriptions are written according to the ABNF: DIT content rule descriptions are written according to the ABNF:
DITContentRuleDescription = LPAREN WSP DITContentRuleDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
[ SP "AUX" SP oids ] ; auxiliary object classes [ SP "AUX" SP oids ] ; auxiliary object classes
[ SP "MUST" SP oids ] ; attribute types [ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types
[ SP "NOT" SP oids ] ; attribute types [ SP "NOT" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
<numericoid> is the object identifier of the structural object class <numericoid> is the object identifier of the structural object
associated with this DIT content rule; class associated with this DIT content rule;
NAME <qdescrs> are short names (descriptors) identifying this DIT NAME <qdescrs> are short names (descriptors) identifying this DIT
content rule; content rule;
DESC <qdstring> is a short descriptive string; DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this DIT content rule use is not active; OBSOLETE indicates this DIT content rule use is not active;
AUX specifies a list of auxiliary object classes which entries AUX specifies a list of auxiliary object classes that entries
subject to this DIT content rule may belong to; subject to this DIT content rule may belong to;
MUST, MAY, and NOT specify lists of attribute types which are MUST, MAY, and NOT specify lists of attribute types that are
required, allowed, or precluded, respectively, from appearing in required, allowed, or precluded, respectively, from appearing
entries subject to this DIT content rule; and in entries subject to this DIT content rule; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.7. DIT Structure Rules and Name Forms 4.1.7. DIT Structure Rules and Name Forms
It is sometimes desirable to regulate where object and alias entries It is sometimes desirable to regulate where object and alias entries
can be placed in the DIT and how they can be named based upon their can be placed in the DIT and how they can be named based upon their
structural object class. structural object class.
4.1.7.1. DIT Structure Rules 4.1.7.1. DIT Structure Rules
skipping to change at page 31, line 16 skipping to change at page 31, line 6
NAME <qdescrs> are short names (descriptors) identifying this DIT NAME <qdescrs> are short names (descriptors) identifying this DIT
structure rule; structure rule;
DESC <qdstring> is a short descriptive string; DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this DIT structure rule use is not active; OBSOLETE indicates this DIT structure rule use is not active;
FORM is specifies the name form associated with this DIT structure FORM is specifies the name form associated with this DIT structure
rule; rule;
SUP identifies superior rules (by rule id); and SUP identifies superior rules (by rule id); and
<extensions> describe extensions. <extensions> describe extensions.
If no superior rules are identified, the DIT structure rule applies If no superior rules are identified, the DIT structure rule applies
to an autonomous administrative point (e.g. the root vertex of the to an autonomous administrative point (e.g., the root vertex of the
subtree controlled by the subschema) [X.501]. subtree controlled by the subschema) [X.501].
4.1.7.2. Name Forms 4.1.7.2. Name Forms
A name form "specifies a permissible RDN for entries of a particular A name form "specifies a permissible RDN for entries of a particular
structural object class. A name form identifies a named object structural object class. A name form identifies a named object class
class and one or more attribute types to be used for naming (i.e. and one or more attribute types to be used for naming (i.e., for the
for the RDN). Name forms are primitive pieces of specification RDN). Name forms are primitive pieces of specification used in the
used in the definition of DIT structure rules" [X.501]. definition of DIT structure rules" [X.501].
Each name form indicates the structural object class to be named, Each name form indicates the structural object class to be named, a
a set of required attribute types, and a set of allowed attribute set of required attribute types, and a set of allowed attribute
types. A particular attribute type cannot be in both sets. types. A particular attribute type cannot be in both sets.
Entries governed by the form must be named using a value from each Entries governed by the form must be named using a value from each
required attribute type and zero or more values from the allowed required attribute type and zero or more values from the allowed
attribute types. attribute types.
Each name form is identified by an object identifier (OID) and, Each name form is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors). optionally, one or more short names (descriptors).
Name form descriptions are written according to the ABNF: Name form descriptions are written according to the ABNF:
skipping to change at page 32, line 4 skipping to change at page 31, line 41
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "OC" SP oid ; structural object class SP "OC" SP oid ; structural object class
SP "MUST" SP oids ; attribute types SP "MUST" SP oids ; attribute types
[ SP "MAY" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
<numericoid> is object identifier that identifies this name form;
<numericoid> is object identifier which identifies this name form;
NAME <qdescrs> are short names (descriptors) identifying this name NAME <qdescrs> are short names (descriptors) identifying this name
form; form;
DESC <qdstring> is a short descriptive string; DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this name form is not active; OBSOLETE indicates this name form is not active;
OC identifies the structural object class this rule applies to, OC identifies the structural object class this rule applies to,
MUST and MAY specify the sets of required and allowed, respectively, MUST and MAY specify the sets of required and allowed,
naming attributes for this name form; and respectively, naming attributes for this name form; and
<extensions> describe extensions. <extensions> describe extensions.
All attribute types in the required ("MUST") and allowed ("MAY") lists All attribute types in the required ("MUST") and allowed ("MAY")
shall be different. lists shall be different.
4.2. Subschema Subentries 4.2. Subschema Subentries
Subschema (sub)entries are used for administering information about Subschema (sub)entries are used for administering information about
the directory schema. A single subschema (sub)entry contains all the directory schema. A single subschema (sub)entry contains all
schema definitions (see Section 4.1) used by entries in a particular schema definitions (see Section 4.1) used by entries in a particular
part of the directory tree. part of the directory tree.
Servers which follow X.500(93) models SHOULD implement subschema using Servers that follow X.500(93) models SHOULD implement subschema using
the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]), the X.500 subschema mechanisms (as detailed in Section 12 of
and so these are not ordinary object entries but subentries (see [X.501]), so these are not ordinary object entries but subentries
Section 3.2). LDAP clients SHOULD NOT assume that servers implement (see Section 3.2). LDAP clients SHOULD NOT assume that servers
any of the other aspects of X.500 subschema. implement any of the other aspects of X.500 subschema.
Servers MAY allow subschema modification. Procedures for subschema Servers MAY allow subschema modification. Procedures for subschema
modification are discussed in Section 14.5 of [X.501]. modification are discussed in Section 14.5 of [X.501].
A server which masters entries and permits clients to modify these A server that masters entries and permits clients to modify these
entries SHALL implement and provide access to these subschema entries SHALL implement and provide access to these subschema
(sub)entries including providing a 'subschemaSubentry' attribute in (sub)entries including providing a 'subschemaSubentry' attribute in
each modifiable entry. This is so clients may discover the attributes each modifiable entry. This is so clients may discover the
and object classes which are permitted to be present. It is strongly attributes and object classes that are permitted to be present. It
RECOMMENDED that all other servers implement this as well. is strongly RECOMMENDED that all other servers implement this as
well.
The value of the 'subschemaSubentry' attribute is the name of the The value of the 'subschemaSubentry' attribute is the name of the
subschema (sub)entry holding the subschema controlling the entry. subschema (sub)entry holding the subschema controlling the entry.
( 2.5.18.10 NAME 'subschemaSubentry' ( 2.5.18.10 NAME 'subschemaSubentry'
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
NO-USER-MODIFICATION SINGLE-VALUE SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
Subschema is held in (sub)entries belonging to the subschema auxiliary Subschema is held in (sub)entries belonging to the subschema
object class. auxiliary object class.
( 2.5.20.1 NAME 'subschema' AUXILIARY ( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $ MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $ objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) ) matchingRuleUse ) )
The 'ldapSyntaxes' operational attribute may also be present in The 'ldapSyntaxes' operational attribute may also be present in
subschema entries. subschema entries.
Servers MAY provide additional attributes (described in other Servers MAY provide additional attributes (described in other
documents) in subschema (sub)entries. documents) in subschema (sub)entries.
Servers SHOULD provide the attributes 'createTimestamp' and Servers SHOULD provide the attributes 'createTimestamp' and
'modifyTimestamp' in subschema (sub)entries, in order to allow clients 'modifyTimestamp' in subschema (sub)entries, in order to allow
to maintain their caches of schema information. clients to maintain their caches of schema information.
The following subsections provide attribute type definitions for each The following subsections provide attribute type definitions for each
of schema definition attribute types. of schema definition attribute types.
4.2.1. 'objectClasses' 4.2.1. 'objectClasses'
This attribute holds definitions of object classes. This attribute holds definitions of object classes.
( 2.5.21.6 NAME 'objectClasses' ( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation ) USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
defined in [Syntaxes]. defined in [RFC4517].
4.2.2. 'attributeTypes' 4.2.2. 'attributeTypes'
This attribute holds definitions of attribute types. This attribute holds definitions of attribute types.
( 2.5.21.5 NAME 'attributeTypes' ( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation ) USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
defined in [Syntaxes]. defined in [RFC4517].
4.2.3. 'matchingRules' 4.2.3. 'matchingRules'
This attribute holds definitions of matching rules. This attribute holds definitions of matching rules.
( 2.5.21.4 NAME 'matchingRules' ( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
USAGE directoryOperation ) USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
defined in [Syntaxes]. defined in [RFC4517].
4.2.4 'matchingRuleUse' 4.2.4 'matchingRuleUse'
This attribute holds definitions of matching rule uses. This attribute holds definitions of matching rule uses.
( 2.5.21.8 NAME 'matchingRuleUse' ( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation ) USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
defined in [Syntaxes]. defined in [RFC4517].
4.2.5. 'ldapSyntaxes' 4.2.5. 'ldapSyntaxes'
This attribute holds definitions of LDAP syntaxes. This attribute holds definitions of LDAP syntaxes.
( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
USAGE directoryOperation ) USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
in [Syntaxes]. in [RFC4517].
4.2.6. 'dITContentRules' 4.2.6. 'dITContentRules'
This attribute lists DIT Content Rules which are present in the This attribute lists DIT Content Rules that are present in the
subschema. subschema.
( 2.5.21.2 NAME 'dITContentRules' ( 2.5.21.2 NAME 'dITContentRules'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation ) USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
defined in [Syntaxes]. defined in [RFC4517].
4.2.7. 'dITStructureRules' 4.2.7. 'dITStructureRules'
This attribute lists DIT Structure Rules which are present in the This attribute lists DIT Structure Rules that are present in the
subschema. subschema.
( 2.5.21.1 NAME 'dITStructureRules' ( 2.5.21.1 NAME 'dITStructureRules'
EQUALITY integerFirstComponentMatch EQUALITY integerFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
USAGE directoryOperation ) USAGE directoryOperation )
The 'integerFirstComponentMatch' matching rule and the The 'integerFirstComponentMatch' matching rule and the
DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax
defined in [Syntaxes]. are defined in [RFC4517].
4.2.8 'nameForms' 4.2.8 'nameForms'
This attribute lists Name Forms which are in force. This attribute lists Name Forms that are in force.
( 2.5.21.7 NAME 'nameForms' ( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation ) USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are
in [Syntaxes]. defined in [RFC4517].
4.3. 'extensibleObject' object class 4.3. 'extensibleObject' object class
The 'extensibleObject' auxiliary object class allows entries that The 'extensibleObject' auxiliary object class allows entries that
belong to it to hold any user attribute. The set of allowed attribute belong to it to hold any user attribute. The set of allowed
types of this object class is implicitly the set of all attribute attribute types of this object class is implicitly the set of all
types of userApplications usage. attribute types of userApplications usage.
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY ) SUP top AUXILIARY )
The mandatory attributes of the other object classes of this entry are
still required to be present and any precluded attributes are still The mandatory attributes of the other object classes of this entry
not allowed to be present. are still required to be present, and any precluded attributes are
still not allowed to be present.
4.4. Subschema Discovery 4.4. Subschema Discovery
To discover the DN of the subschema (sub)entry holding the subschema To discover the DN of the subschema (sub)entry holding the subschema
controlling a particular entry, a client reads that entry's controlling a particular entry, a client reads that entry's
'subschemaSubentry' operational attribute. To read schema attributes 'subschemaSubentry' operational attribute. To read schema attributes
from the subschema (sub)entry, clients MUST issue a Search operation from the subschema (sub)entry, clients MUST issue a Search operation
[Protocol] where baseObject is the DN of the subschema (sub)entry, [RFC4511] where baseObject is the DN of the subschema (sub)entry,
scope is baseObject, filter is "(objectClass=subschema)" [Filters], scope is baseObject, filter is "(objectClass=subschema)" [RFC4515],
and attributes field lists the names of the desired schema attributes and the attributes field lists the names of the desired schema
(as they are operational). Note: the "(objectClass=subschema)" filter attributes (as they are operational). Note: the
allows LDAP servers which gateway to X.500 to detect that subentry "(objectClass=subschema)" filter allows LDAP servers that gateway to
information is being requested. X.500 to detect that subentry information is being requested.
Clients SHOULD NOT assume a published subschema is complete nor assume Clients SHOULD NOT assume that a published subschema is complete,
the server supports all of the schema elements it publishes nor assume that the server supports all of the schema elements it publishes, or
the server does not support an unpublished element. that the server does not support an unpublished element.
5. DSA (Server) Informational Model 5. DSA (Server) Informational Model
The LDAP protocol assumes there are one or more servers which jointly The LDAP protocol assumes there are one or more servers that jointly
provide access to a Directory Information Tree (DIT). The server provide access to a Directory Information Tree (DIT). The server
holding the original information is called the "master" (for that holding the original information is called the "master" (for that
information). Servers which hold copies of the original information information). Servers that hold copies of the original information
are referred to as "shadowing" or "caching" servers. are referred to as "shadowing" or "caching" servers.
As defined in [X.501]: As defined in [X.501]:
context prefix: The sequence of RDNs leading from the Root of the context prefix: The sequence of RDNs leading from the Root of the
DIT to the initial vertex of a naming context; corresponds to DIT to the initial vertex of a naming context; corresponds to
the distinguished name of that vertex. the distinguished name of that vertex.
and:
naming context: A subtree of entries held in a single master DSA. naming context: A subtree of entries held in a single master DSA.
That is, a naming context is the largest collection of entries, That is, a naming context is the largest collection of entries,
starting at an entry that is mastered by a particular server, and starting at an entry that is mastered by a particular server, and
including all its subordinates and their subordinates, down to the including all its subordinates and their subordinates, down to the
entries which are mastered by different servers. The context prefix entries that are mastered by different servers. The context prefix
is the name of the initial entry. is the name of the initial entry.
The root of the DIT is a DSA-specific Entry (DSE) and not part of any The root of the DIT is a DSA-specific Entry (DSE) and not part of any
naming context (or any subtree); each server has different attribute naming context (or any subtree); each server has different attribute
values in the root DSE. values in the root DSE.
5.1. Server-specific Data Requirements 5.1. Server-Specific Data Requirements
An LDAP server SHALL provide information about itself and other An LDAP server SHALL provide information about itself and other
information that is specific to each server. This is represented as a information that is specific to each server. This is represented as
group of attributes located in the root DSE, which is named with the a group of attributes located in the root DSE, which is named with
DN with zero RDNs (whose [LDAPDN] representation is as the zero-length the DN with zero RDNs (whose [RFC4514] representation is as the
string). zero-length string).
These attributes are retrievable, subject to access control and other These attributes are retrievable, subject to access control and other
restrictions, if a client performs a Search operation [Protocol] with restrictions, if a client performs a Search operation [RFC4511] with
an empty baseObject, scope of baseObject, the filter "(objectClass=*)" an empty baseObject, scope of baseObject, the filter
[Filters], and with the attributes field listing the names of the "(objectClass=*)" [RFC4515], and the attributes field listing the
desired attributes. It is noted that root DSE attributes are names of the desired attributes. It is noted that root DSE
operational, and like other operational attributes, are not returned attributes are operational and, like other operational attributes,
in search requests unless requested by name. are not returned in search requests unless requested by name.
The root DSE SHALL NOT be included if the client performs a subtree The root DSE SHALL NOT be included if the client performs a subtree
search starting from the root. search starting from the root.
Servers may allow clients to modify attributes of the root DSE where Servers may allow clients to modify attributes of the root DSE, where
appropriate. appropriate.
The following attributes of the root DSE are defined in [Syntaxes]. The following attributes of the root DSE are defined below.
Additional attributes may be defined in other documents. Additional attributes may be defined in other documents.
- altServer: alternative servers; - altServer: alternative servers;
- namingContexts: naming contexts; - namingContexts: naming contexts;
- supportedControl: recognized LDAP controls; - supportedControl: recognized LDAP controls;
- supportedExtension: recognized LDAP extended operations; - supportedExtension: recognized LDAP extended operations;
- supportedFeatures: recognized LDAP features; - supportedFeatures: recognized LDAP features;
- supportedLDAPVersion: LDAP versions supported; and - supportedLDAPVersion: LDAP versions supported; and
- supportedSASLMechanisms: recognized Simple Authentication and - supportedSASLMechanisms: recognized Simple Authentication and
Security Layers (SASL) [SASL] mechanisms. Security Layers (SASL) [RFC4422] mechanisms.
The values provided for these attributes may depend on The values provided for these attributes may depend on session-
session-specific and other factors. For example, a server supporting specific and other factors. For example, a server supporting the
the SASL EXTERNAL mechanism might only list "EXTERNAL" when the SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's
client's identity has been established by a lower level. See identity has been established by a lower level. See [RFC4513].
[AuthMeth].
The root DSE may also include a 'subschemaSubentry' attribute. If so, The root DSE may also include a 'subschemaSubentry' attribute. If it
it refers to the subschema (sub)entry holding the schema controlling does, the attribute refers to the subschema (sub)entry holding the
the root DSE. Clients SHOULD NOT assume that this subschema schema controlling the root DSE. Clients SHOULD NOT assume that this
(sub)entry controls other entries held by the server. General subschema (sub)entry controls other entries held by the server.
subschema discovery procedures are provided in Section 4.4. General subschema discovery procedures are provided in Section 4.4.
5.1.1. 'altServer' 5.1.1. 'altServer'
The 'altServer' attribute lists URIs referring to alternative servers The 'altServer' attribute lists URIs referring to alternative servers
which may be contacted when this server becomes unavailable. URIs for that may be contacted when this server becomes unavailable. URIs for
servers implementing the LDAP are written according to [LDAPURL]. servers implementing the LDAP are written according to [RFC4516].
Other kinds of URIs may be provided. If the server does not know of Other kinds of URIs may be provided. If the server does not know of
any other servers which could be used this attribute will be absent. any other servers that could be used, this attribute will be absent.
Clients may cache this information in case their preferred server Clients may cache this information in case their preferred server
later becomes unavailable. later becomes unavailable.
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE dSAOperation ) USAGE dSAOperation )
The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
[Syntaxes]. [RFC4517].
5.1.2. 'namingContexts' 5.1.2. 'namingContexts'
The 'namingContexts' attribute lists the context prefixes of the The 'namingContexts' attribute lists the context prefixes of the
naming contexts the server masters or shadows (in part or in whole). naming contexts the server masters or shadows (in part or in whole).
If the server is a first-level DSA [X.501], it should list (in If the server is a first-level DSA [X.501], it should list (in
addition) an empty string (indicating the root of the DIT). If the addition) an empty string (indicating the root of the DIT). If the
server does not master or shadow any information (e.g. it is an LDAP server does not master or shadow any information (e.g., it is an LDAP
gateway to a public X.500 directory) this attribute will be absent. gateway to a public X.500 directory) this attribute will be absent.
If the server believes it masters or shadows the entire directory, the If the server believes it masters or shadows the entire directory,
attribute will have a single value, and that value will be the empty the attribute will have a single value, and that value will be the
string (indicating the root of the DIT). empty string (indicating the root of the DIT).
This attribute may be used, for example, to select a suitable entry This attribute may be used, for example, to select a suitable entry
name for subsequent operations with this server. name for subsequent operations with this server.
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE dSAOperation ) USAGE dSAOperation )
The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
defined in [Syntaxes]. defined in [RFC4517].
5.1.3. 'supportedControl' 5.1.3. 'supportedControl'
The 'supportedControl' attribute lists object identifiers identifying The 'supportedControl' attribute lists object identifiers identifying
the request controls [Protocol] the server supports. If the server the request controls [RFC4511] the server supports. If the server
does not support any request controls, this attribute will be absent. does not support any request controls, this attribute will be absent.
Object identifiers identifying response controls need not be listed. Object identifiers identifying response controls need not be listed.
Procedures for registering object identifiers used to discovery of Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in BCP 64 [BCP64bis]. protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation ) USAGE dSAOperation )
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
defined in [Syntaxes]. defined in [RFC4517].
5.1.4. 'supportedExtension' 5.1.4. 'supportedExtension'
The 'supportedExtension' attribute lists object identifiers The 'supportedExtension' attribute lists object identifiers
identifying the extended operations [Protocol] which the server identifying the extended operations [RFC4511] that the server
supports. If the server does not support any extended operations, supports. If the server does not support any extended operations,
this attribute will be absent. this attribute will be absent.
An extended operation generally consists of an extended request and an An extended operation generally consists of an extended request and
extended response but may also include other protocol data units (such an extended response but may also include other protocol data units
as intermediate responses). The object identifier assigned to the (such as intermediate responses). The object identifier assigned to
extended request is used to identify the extended operation. Other the extended request is used to identify the extended operation.
object identifiers used in the extended operation need not be listed Other object identifiers used in the extended operation need not be
as values of this attribute. listed as values of this attribute.
Procedures for registering object identifiers used to discovery of Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in BCP 64 [BCP64bis]. protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation ) USAGE dSAOperation )
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
defined in [Syntaxes]. defined in [RFC4517].
5.1.5. 'supportedFeatures' 5.1.5. 'supportedFeatures'
The 'supportedFeatures' attribute lists object identifiers identifying
elective features which the server supports. If the server does not The 'supportedFeatures' attribute lists object identifiers
support any discoverable elective features, this attribute will be identifying elective features that the server supports. If the
absent. server does not support any discoverable elective features, this
attribute will be absent.
( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures' ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
EQUALITY objectIdentifierMatch EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation ) USAGE dSAOperation )
Procedures for registering object identifiers used to discovery of Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in BCP 64 [BCP64bis]. protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
objectIdentifierMatch matching rule are defined in [Syntaxes]. objectIdentifierMatch matching rule are defined in [RFC4517].
5.1.6. 'supportedLDAPVersion' 5.1.6. 'supportedLDAPVersion'
The 'supportedLDAPVersion' attribute lists the versions of LDAP which The 'supportedLDAPVersion' attribute lists the versions of LDAP that
the server supports. the server supports.
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
USAGE dSAOperation ) USAGE dSAOperation )
The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in
[Syntaxes]. [RFC4517].
5.1.7. 'supportedSASLMechanisms' 5.1.7. 'supportedSASLMechanisms'
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
[SASL] which the server recognizes and/or supports [AuthMeth]. The [RFC4422] that the server recognizes and/or supports [RFC4513]. The
contents of this attribute may depend on the current session state. contents of this attribute may depend on the current session state.
If the server does not support any SASL mechanisms this attribute will If the server does not support any SASL mechanisms, this attribute
not be present. will not be present.
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE dSAOperation ) USAGE dSAOperation )
The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is
in [Syntaxes]. defined in [RFC4517].
6. Other Considerations 6. Other Considerations
6.1. Preservation of User Information 6.1. Preservation of User Information
Syntaxes may be defined which have specific value and/or value form Syntaxes may be defined that have specific value and/or value form
(representation) preservation requirements. For example, a syntax (representation) preservation requirements. For example, a syntax
containing digitally signed data can mandate the server preserve both containing digitally signed data can mandate that the server preserve
the value and form of value presented to ensure signature is not both the value and form of value presented to ensure that the
invalidated. signature is not invalidated.
Where such requirements have not been explicitly stated, servers Where such requirements have not been explicitly stated, servers
SHOULD preserve the value of user information but MAY return the value SHOULD preserve the value of user information but MAY return the
in a different form. And where a server is unable (or unwilling) to value in a different form. And where a server is unable (or
preserve the value of user information, the server SHALL ensure that unwilling) to preserve the value of user information, the server
an equivalent value (per Section 2.3) is returned. SHALL ensure that an equivalent value (per Section 2.3) is returned.
6.2. Short Names 6.2. Short Names
Short names, also known as descriptors, are used as more readable Short names, also known as descriptors, are used as more readable
aliases for object identifiers and are used to identify various schema aliases for object identifiers and are used to identify various
elements. However, it is not expected that LDAP implementations with schema elements. However, it is not expected that LDAP
human user interface would display these short names (nor the object implementations with human user interface would display these short
identifiers they refer to) to the user, but would most likely be names (or the object identifiers they refer to) to the user.
performing translations (such as expressing the short name in one of Instead, they would most likely be performing translations (such as
the local national languages). For example, the short name "st" expressing the short name in one of the local national languages).
(stateOrProvinceName) might be displayed to a German-speaking user as For example, the short name "st" (stateOrProvinceName) might be
"Land". displayed to a German-speaking user as "Land".
The same short name might have different meaning in different The same short name might have different meaning in different
subschemas and, within a particular subschema, the same short name subschemas, and, within a particular subschema, the same short name
might refer to different object identifiers each identifying a might refer to different object identifiers each identifying a
different kind of schema element. different kind of schema element.
Implementations MUST be prepared that the same short name might be Implementations MUST be prepared that the same short name might be
used in a subschema to refer to the different kinds of schema used in a subschema to refer to the different kinds of schema
elements. That is, there might be an object class 'x-fubar' and an elements. That is, there might be an object class 'x-fubar' and an
attribute type 'x-fubar' in a subschema. attribute type 'x-fubar' in a subschema.
Implementations MUST be prepared that the same short name might be Implementations MUST be prepared that the same short name might be
used in the different subschemas to refer to the different schema used in the different subschemas to refer to the different schema
elements. That is, there might be two matching rules 'x-fubar', each elements. That is, there might be two matching rules 'x-fubar', each
in different subschemas. in different subschemas.
Procedures for registering short names (descriptors) are detailed in Procedures for registering short names (descriptors) are detailed in
BCP 64 [BCP64bis]. BCP 64, RFC 4520 [RFC4520].
6.3. Cache and Shadowing 6.3. Cache and Shadowing
Some servers may hold cache or shadow copies of entries, which can be Some servers may hold cache or shadow copies of entries, which can be
used to answer search and comparison queries, but will return used to answer search and comparison queries, but will return
referrals or contact other servers if modification operations are referrals or contact other servers if modification operations are
requested. Servers that perform shadowing or caching MUST ensure that requested. Servers that perform shadowing or caching MUST ensure
they do not violate any access control constraints placed on the data that they do not violate any access control constraints placed on the
by the originating server. data by the originating server.
7. Implementation Guidelines 7. Implementation Guidelines
7.1 Server Guidelines 7.1. Server Guidelines
Servers MUST recognize all names of attribute types and object classes Servers MUST recognize all names of attribute types and object
defined in this document but, unless stated otherwise, need not classes defined in this document but, unless stated otherwise, need
support the associated functionality. Servers SHOULD recognize all not support the associated functionality. Servers SHOULD recognize
the names of attribute types and object classes defined in Section 3 all the names of attribute types and object classes defined in
and 4, respectively, of [Schema]. Section 3 and 4, respectively, of [RFC4519].
Servers MUST ensure that entries conform to user and system schema Servers MUST ensure that entries conform to user and system schema
rules or other data model constraints. rules or other data model constraints.
Servers MAY support DIT Content Rules. Servers MAY support DIT Servers MAY support DIT Content Rules. Servers MAY support DIT
Structure Rules and Name Forms. Structure Rules and Name Forms.
Servers MAY support alias entries. Servers MAY support alias entries.
Servers MAY support the 'extensibleObject' object class. Servers MAY support the 'extensibleObject' object class.
Servers MAY support subentries. If so, they MUST do so in accordance Servers MAY support subentries. If so, they MUST do so in accordance
with [RFC3672]. Servers which do not support subentries SHOULD use with [RFC3672]. Servers that do not support subentries SHOULD use
object entries to mimic subentries as detailed in Section 3.2. object entries to mimic subentries as detailed in Section 3.2.
Servers MAY implement additional schema elements. Servers SHOULD Servers MAY implement additional schema elements. Servers SHOULD
provide definitions of all schema elements they support in subschema provide definitions of all schema elements they support in subschema
(sub)entries. (sub)entries.
7.2 Client Guidelines 7.2. Client Guidelines
In the absence of prior agreements with servers, clients SHOULD NOT In the absence of prior agreements with servers, clients SHOULD NOT
assume that servers support any particular schema elements beyond assume that servers support any particular schema elements beyond
those referenced in Section 7.1. The client can retrieve subschema those referenced in Section 7.1. The client can retrieve subschema
information as described in Section 4.4. information as described in Section 4.4.
Clients MUST NOT display nor attempt to decode as ASN.1, a value if Clients MUST NOT display or attempt to decode a value as ASN.1 if the
its syntax is not known. Clients MUST NOT assume the LDAP-specific value's syntax is not known. Clients MUST NOT assume the LDAP-
string encoding is restricted to a UTF-8 encoded string of Unicode specific string encoding is restricted to a UTF-8 encoded string of
characters or any particular subset of Unicode (such as a printable Unicode characters or any particular subset of Unicode (such as a
subset) unless such restriction is explicitly stated. Clients SHOULD printable subset) unless such restriction is explicitly stated.
NOT send attribute values in a request that are not valid according to Clients SHOULD NOT send attribute values in a request that are not
the syntax defined for the attributes. valid according to the syntax defined for the attributes.
8. Security Considerations 8. 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.
General security considerations for accessing directory information General security considerations for accessing directory information
with LDAP are discussed in [Protocol] and [AuthMeth]. with LDAP are discussed in [RFC4511] and [RFC4513].
9. IANA Considerations 9. 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 comment
Object Identifier: see comment Object Identifier: see comment
Person & email address to contact for further information: Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org> Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see comment Usage: see comment
Specification: RFC XXXX Specification: RFC 4512
Author/Change Controller: IESG Author/Change Controller: IESG
Comments: Comments:
The following descriptors (short names) should be added to The following descriptors (short names) has been added to
the registry. the registry.
NAME Type OID NAME Type OID
------------------------ ---- ----------------- ------------------------ ---- -----------------
governingStructureRule A 2.5.21.10 governingStructureRule A 2.5.21.10
structuralObjectClass A 2.5.21.9 structuralObjectClass A 2.5.21.9
The following descriptors (short names) should be updated to The following descriptors (short names) have been updated to
refer to this RFC. refer to this RFC.
NAME Type OID NAME Type OID
------------------------ ---- ----------------- ------------------------ ---- -----------------
alias O 2.5.6.1 alias O 2.5.6.1
aliasedObjectName A 2.5.4.1 aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6 altServer A 1.3.6.1.4.1.1466.101.120.6
attributeTypes A 2.5.21.5 attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1 createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3 creatorsName A 2.5.18.3
skipping to change at page 44, line 28 skipping to change at page 44, line 21
objectClasses A 2.5.21.6 objectClasses A 2.5.21.6
subschema O 2.5.20.1 subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10 subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13 supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7 supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedFeatures A 1.3.6.1.4.1.4203.1.3.5 supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15 supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14 supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0 top O 2.5.6.0
10. Acknowledgments 10. Acknowledgements
This document is based in part on RFC 2251 by M. Wahl, T. Howes, and This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
RFC 2556 by M. Wahl, all products of the IETF Access, Searching and RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
Indexing of Directories (ASID) Working Group. This document is also Indexing of Directories (ASID) Working Group. This document is also
based in part on "The Directory: Models" [X.501], a product of the based in part on "The Directory: Models" [X.501], a product of the
International Telephone Union (ITU). Additional text was borrowed International Telephone Union (ITU). Additional text was borrowed
from RFC 2253 by M. Wahl, T. Howes, and S. Kille. from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
This document is a product of the IETF LDAP Revision (LDAPBIS) Working This document is a product of the IETF LDAP Revision (LDAPBIS)
Group. Working Group.
11. Editor's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
12. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
12.1. Normative References 11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629 (also STD 63), November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671, [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
December 2003. Directory Access Protocol (LDAP)", RFC 3671, December
2003.
[RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
3672, December 2003. Access Protocol (LDAP)", RFC 3672, December 2003.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. Specifications: ABNF", RFC 4234, October 2005.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in Authentication and Security Layer (SASL)", RFC 4422,
progress. June 2006.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
draft-ietf-ldapbis-protocol-xx.txt, a work in progress. Protocol (LDAP): Technical Specification Road Map", RFC
4510, June 2006.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Connection Level Security Mechanisms", Protocol (LDAP): The Protocol", RFC 4511, June 2006.
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
Representation of Search Filters", Protocol (LDAP): Authentication Methods and Security
draft-ietf-ldapbis-filter-xx.txt, a work in progress. Mechanisms", RFC 4513, June 2006.
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a Protocol (LDAP): String Representation of Distinguished
work in progress. Names", RFC 4514, June 2006.
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
draft-ietf-ldapbis-url-xx.txt, a work in progress. Access Protocol (LDAP): String Representation of Search
Filters", RFC 4515, June 2006.
[SASL] Melnikov, A. (Editor), "Simple Authentication and [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
Security Layer (SASL)", Access Protocol (LDAP): Uniform Resource Locator", RFC
draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 4516, June 2006.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. (LDAP): Syntaxes and Matching Rules", RFC 4517, June
2006.
[Schema] Dally, K. (editor), "LDAP: User Schema", [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
draft-ietf-ldapbis-user-schema-xx.txt, a work in Protocol (LDAP): Schema for User Applications", RFC
progress. 4519, June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
(IANA) Considerations for the Lightweight Directory
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version [Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0" 3.2.0" is defined by "The Unicode Standard, Version
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
as amended by the "Unicode Standard Annex #27: Unicode 61633-5), as amended by the "Unicode Standard Annex
3.1" (http://www.unicode.org/reports/tr27/) and by the #27: Unicode 3.1"
(http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2" "Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/). (http://www.unicode.org/reports/tr28/).
[X.500] International Telecommunication Union - [X.500] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory Telecommunication Standardization Sector, "The
-- Overview of concepts, models and services," Directory -- Overview of concepts, models and
X.500(1993) (also ISO/IEC 9594-1:1994). services," X.500(1993) (also ISO/IEC 9594-1:1994).
[X.501] International Telecommunication Union - [X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory Telecommunication Standardization Sector, "The
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994). Directory -- Models," X.501(1993) (also ISO/IEC 9594-
2:1994).
[X.680] International Telecommunication Union - [X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(2002) (also ISO/IEC 8824-1:2002). Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
12.2. Informative References
None.
Appendix A. Changes Appendix A. Changes
This appendix is non-normative. This appendix is non-normative.
This document amounts to nearly a complete rewrite of portions of RFC This document amounts to nearly a complete rewrite of portions of RFC
2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
overall clarity of technical specification. This appendix provides a overall clarity of technical specification. This appendix provides a
summary of substantive changes made to the portions of these documents summary of substantive changes made to the portions of these
incorporated into this document. Readers should consult [Roadmap], documents incorporated into this document. Readers should consult
[Protocol], [Syntaxes], and [Schema] for summaries of remaining [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of
portions of these documents. remaining portions of these documents.
A.1 Changes to RFC 2251 A.1. Changes to RFC 2251
This document incorporates from RFC 2251 sections 3.2 and 3.4, This document incorporates from RFC 2251, Sections 3.2 and 3.4, and
portions of Section 4 and 6 as summarized below. portions of Sections 4 and 6 as summarized below.
A.1.1 Section 3.2 of RFC 2251 A.1.1. Section 3.2 of RFC 2251
Section 3.2 of RFC 2251 provided a brief introduction to the X.500 Section 3.2 of RFC 2251 provided a brief introduction to the X.500
data model, as used by LDAP. The previous specification relied on data model, as used by LDAP. The previous specification relied on
[X.501] but lacked clarity in how X.500 models are adapted for use by [X.501] but lacked clarity in how X.500 models are adapted for use by
LDAP. This document describes the X.500 data models, as used by LDAP LDAP. This document describes the X.500 data models, as used by
in greater detail, especially in areas where adaptation is needed. LDAP, in greater detail, especially in areas where adaptation is
needed.
Section 3.2.1 of RFC 2251 described an attribute as "a type with one Section 3.2.1 of RFC 2251 described an attribute as "a type with one
or more associated values." In LDAP, an attribute is better described or more associated values". In LDAP, an attribute is better
as an attribute description, a type with zero or more options, and one described as an attribute description, a type with zero or more
or more associated values. options, and one or more associated values.
Section 3.2.2 of RFC 2251 mandated that subschema subentries contain Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
objectClasses and attributeTypes attributes, yet X.500(93) treats objectClasses and attributeTypes attributes, yet X.500(93) treats
these attributes as optional. While generally all implementations these attributes as optional. While generally all implementations
that support X.500(93) subschema mechanisms will provide both of these that support X.500(93) subschema mechanisms will provide both of
attributes, it is not absolutely required for interoperability that these attributes, it is not absolutely required for interoperability
all servers do. The mandate was removed for consistency with that all servers do. The mandate was removed for consistency with
X.500(93). The subschema discovery mechanism was also clarified to X.500(93). The subschema discovery mechanism was also clarified to
indicate that subschema controlling an entry is obtained by reading indicate that subschema controlling an entry is obtained by reading
the (sub)entry referred to by that entry's 'subschemaSubentry' the (sub)entry referred to by that entry's 'subschemaSubentry'
attribute. attribute.
A.1.2 Section 3.4 of RFC 2251 A.1.2. Section 3.4 of RFC 2251
Section 3.4 of RFC 2251 provided "Server-specific Data Requirements". Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
This material, with changes, was incorporated in Section 5.1 of this This material, with changes, was incorporated in Section 5.1 of this
document. document.
Changes: Changes:
- Clarify that attributes of the root DSE are subject to "other - Clarify that attributes of the root DSE are subject to "other
restrictions" in addition to access controls. restrictions" in addition to access controls.
- Clarify that only recognized extended requests need to be enumerated - Clarify that only recognized extended requests need to be
'supportedExtension'. enumerated 'supportedExtension'.
- Clarify that only recognized request controls need to be enumerated - Clarify that only recognized request controls need to be enumerated
'supportedControl'. 'supportedControl'.
- Clarify that root DSE attributes are operational and, like other - Clarify that root DSE attributes are operational and, like other
operational attributes, will not be returned in search requests operational attributes, will not be returned in search requests
unless requested by name. unless requested by name.
- Clarify that not all root DSE attributes are user modifiable. - Clarify that not all root DSE attributes are user modifiable.
- Remove inconsistent text regarding handling of the - Remove inconsistent text regarding handling of the
'subschemaSubentry' attribute within the root DSE. The previous 'subschemaSubentry' attribute within the root DSE. The previous
specification stated that the 'subschemaSubentry' attribute held in specification stated that the 'subschemaSubentry' attribute held in
the root DSE referred to "subschema entries (or subentries) known by the root DSE referred to "subschema entries (or subentries) known
this server." This is inconsistent with the attribute intended use by this server". This is inconsistent with the attribute's
as well as its formal definition as a single valued attribute intended use as well as its formal definition as a single valued
[X.501]. It is also noted that a simple (possibly incomplete) list attribute [X.501]. It is also noted that a simple (possibly
of subschema (sub)entries is not terrible useful. This document (in incomplete) list of subschema (sub)entries is not terribly useful.
section 5.1) specifies that the 'subschemaSubentry' attribute of the This document (in Section 5.1) specifies that the
root DSE refers to the subschema controlling the root DSE. It is 'subschemaSubentry' attribute of the root DSE refers to the
noted that the general subschema discovery mechanism remains subschema controlling the root DSE. It is noted that the general
available (see Section 4.4 of this document). subschema discovery mechanism remains available (see Section 4.4 of
this document).
A.1.2 Section 4 of RFC 2251
Portions of Section 4 of RFC 2251 detailing aspects of the information A.1.3. Section 4 of RFC 2251
model used by LDAP were incorporated in this document, including:
- Restriction of distinguished values to attributes whose descriptions Portions of Section 4 of RFC 2251 detailing aspects of the
have no options (from Section 4.1.3); information model used by LDAP were incorporated in this document,
including:
- Restriction of distinguished values to attributes whose
descriptions have no options (from Section 4.1.3);
- Data model aspects of Attribute Types (from Section 4.1.4), - Data model aspects of Attribute Types (from Section 4.1.4),
Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8), Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
Matching Rule Identifier (from 4.1.9); and Matching Rule Identifier (from 4.1.9); and
- User schema requirements (from Section 4.1.6, 4.5.1, and 4.7). - User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
Clarifications to these portions include: Clarifications to these portions include:
- Subtyping and AttributeDescriptions with options. - Subtyping and AttributeDescriptions with options.
A.1.3 Section 6 of RFC 2251 A.1.4. Section 6 of RFC 2251
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
where incorporated into this document. where incorporated into this document.
A.2 Changes to RFC 2252 A.2. Changes to RFC 2252
This document incorporates Sections 4, 5 and 7 from RFC 2252. This document incorporates Sections 4, 5, and 7 from RFC 2252.
A.2.1 Section 4 of RFC 2252 A.2.1. Section 4 of RFC 2252
The specification was updated to use Augmented BNF [RFC2234]. The The specification was updated to use Augmented BNF [RFC4234]. The
string representation of an OBJECT IDENTIFIER was tighten to string representation of an OBJECT IDENTIFIER was tightened to
disallow leading zeros as described in RFC 2252 text. disallow leading zeros as described in RFC 2252.
The <descr> syntax was changed to disallow semicolon (U+003B) The <descr> syntax was changed to disallow semicolon (U+003B)
characters to appear to be consistent its natural language characters in order to appear to be consistent its natural language
specification "descr is the syntactic representation of an object specification "descr is the syntactic representation of an object
descriptor, which consists of letters and digits, starting with a descriptor, which consists of letters and digits, starting with a
letter." In a related change, the statement "an letter". In a related change, the statement "an AttributeDescription
AttributeDescription can be used as the value in a NAME part of an can be used as the value in a NAME part of an
AttributeTypeDescription" was deleted. RFC 2252 provided no AttributeTypeDescription" was deleted. RFC 2252 provided no
specification of the semantics of attribute options appearing in specification of the semantics of attribute options appearing in NAME
NAME fields. fields.
RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
over the <numericoid> form. However, <descr> form can be ambiguous. over the <numericoid> form. However, <descr> form can be ambiguous.
To address this issue, the imperative was replaced with a statement To address this issue, the imperative was replaced with a statement
(in Section 1.4) that while the <descr> form is generally preferred, (in Section 1.4) that while the <descr> form is generally preferred,
<numericoid> should be used where an unambiguous <descr> is not <numericoid> should be used where an unambiguous <descr> is not
available. Additionally, an expanded discussion of descriptor available. Additionally, an expanded discussion of descriptor issues
issues is discussed in Section 6.2 (Short Names). is in Section 6.2 ("Short Names").
The ABNF for a quoted string (qdstring) was updated to reflect The ABNF for a quoted string (qdstring) was updated to reflect
support for the escaping mechanism described in 4.3 of RFC 2252. support for the escaping mechanism described in Section 4.3 of RFC
2252.
A.2.2 Section 5 of RFC 2252 A.2.2. Section 5 of RFC 2252
Definitions of operational attributes provided in Section 5 of RFC Definitions of operational attributes provided in Section 5 of RFC
2252 where incorporated into this document. 2252 where incorporated into this document.
The 'namingContexts' description was clarified. A first-level DSA The 'namingContexts' description was clarified. A first-level DSA
should publish, in addition to other values, "" indicating the root should publish, in addition to other values, "" indicating the root
of the DIT. of the DIT.
The 'altServer' description was clarified. It may hold any URI. The 'altServer' description was clarified. It may hold any URI.
The 'supportedExtension' description was clarified. A server need The 'supportedExtension' description was clarified. A server need
only list the OBJECT IDENTIFIERs associated with the extended only list the OBJECT IDENTIFIERs associated with the extended
requests of the extended operations it recognizes. requests of the extended operations it recognizes.
The 'supportedControl' description was clarified. A server need The 'supportedControl' description was clarified. A server need only
only list the OBJECT IDENTIFIERs associated with the request list the OBJECT IDENTIFIERs associated with the request controls it
controls it recognizes. recognizes.
Descriptions for the 'structuralObjectClass' and Descriptions for the 'structuralObjectClass' and
'governingStructureRule' operational attribute types were added. 'governingStructureRule' operational attribute types were added.
A.2.3 Section 7 of RFC 2252 The attribute definition of 'subschemaSubentry' was corrected to list
the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.
A.2.3. Section 7 of RFC 2252
Section 7 of RFC 2252 provides definitions of the 'subschema' and Section 7 of RFC 2252 provides definitions of the 'subschema' and
'extensibleObject' object classes. These definitions where 'extensibleObject' object classes. These definitions where
integrated into Section 4.2 and Section 4.3 of this document, integrated into Section 4.2 and Section 4.3 of this document,
respectively. Section 7 of RFC 2252 also contained the object class respectively. Section 7 of RFC 2252 also contained the object class
implementation requirement. This was incorporated into Section 7 of implementation requirement. This was incorporated into Section 7 of
this document. this document.
The specification of 'extensibleObject' was clarified of how it The specification of 'extensibleObject' was clarified regarding how
interacts with precluded attributes. it interacts with precluded attributes.
A.3 Changes to RFC 2256 A.3. Changes to RFC 2256
This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
2256. 2256.
Section 5.1 of RFC 2256 provided the definition of the 'objectClass' Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
attribute type. This was integrated into Section 2.4.1 of this attribute type. This was integrated into Section 2.4.1 of this
document. The statement "One of the values is either 'top' or document. The statement "One of the values is either 'top' or
'alias'" was replaced with statement that one of the values is 'top' 'alias'" was replaced with statement that one of the values is 'top'
as entries belonging to 'alias' also belong to 'top'. as entries belonging to 'alias' also belong to 'top'.
Section 5.2 of RFC 2256 provided the definition of the Section 5.2 of RFC 2256 provided the definition of the
'aliasedObjectName' attribute type. This was integrated into 'aliasedObjectName' attribute type. This was integrated into Section
Section 2.6.2 of this document. 2.6.2 of this document.
Section 7.1 of RFC 2256 provided the definition of the 'top' object Section 7.1 of RFC 2256 provided the definition of the 'top' object
class. This was integrated into Section 2.4.1 of this document. class. This was integrated into Section 2.4.1 of this document.
Section 7.2 of RFC 2256 provided the definition of the 'alias' Section 7.2 of RFC 2256 provided the definition of the 'alias' object
object class. This was integrated into Section 2.6.1 of this class. This was integrated into Section 2.6.1 of this document.
document.
A.4 Changes to RFC 3674 A.4. Changes to RFC 3674
This document made no substantive change to the 'supportedFeatures' This document made no substantive change to the 'supportedFeatures'
technical specification provided in RFC 3674. technical specification provided in RFC 3674.
Intellectual Property Rights Editor's Address
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found on the procedures with respect to rights in RFC documents can be
in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification such proprietary rights by implementers or users of this
can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Acknowledgement
Copyright (C) The Internet Society (2005). 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 Funding for the RFC Editor function is provided by the IETF
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Administrative Support Activity (IASA).
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.
 End of changes. 266 change blocks. 
617 lines changed or deleted 615 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/