draft-ietf-ldapbis-models-09.txt   draft-ietf-ldapbis-models-10.txt 
INTERNET-DRAFT Editor: Kurt D. Zeilenga INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 27 October 2003 Expires in six months 15 February 2004
Obsoletes: RFC 2251, RFC 2252, RFC 2256 Obsoletes: RFC 2251, RFC 2252, RFC 2256
LDAP: Directory Information Models LDAP: Directory Information Models
<draft-ietf-ldapbis-models-09.txt> <draft-ietf-ldapbis-models-10.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
This document is intended to be published as a Standard Track RFC. This document is intended to be published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.org>. Please send editorial mailing list <ietf-ldapbis@openldap.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>. comments directly to the editor <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>. <http://www.ietf.org/shadow.html>.
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document Please see the Full Copyright section near the end of this document
for more information. 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 which 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.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2. Model of Directory User Information 6 2. Model of Directory User Information 6
2.1. The Directory Information Tree 7 2.1. The Directory Information Tree 7
2.2. Naming of Entries 2.2. Naming of Entries
2.3. Structure of an Entry 8 2.3. Structure of an Entry 8
2.4. Object Classes 9 2.4. Object Classes 9
2.5. Attribute Descriptions 11 2.5. Attribute Descriptions 11
2.6. Alias Entries 15 2.6. Alias Entries 15
3. Directory Administrative and Operational Information 17 3. Directory Administrative and Operational Information 17
3.1. Subtrees 3.1. Subtrees
3.2. Subentries 3.2. Subentries
3.3. The 'objectClass' attribute 18 3.3. The 'objectClass' attribute
3.4. Operational attributes 3.4. Operational attributes 18
4. Directory Schema 21 4. Directory Schema 21
4.1. Schema Definitions 22 4.1. Schema Definitions 22
4.2. Subschema Subentries 31 4.2. Subschema Subentries 31
4.3. 'extensibleObject' 34 4.3. 'extensibleObject' 35
4.4. Subschema Discovery 35 4.4. Subschema Discovery
5. DSA (Server) Informational Model 5. DSA (Server) Informational Model
5.1. Server-specific Data Requirements 36 5.1. Server-specific Data Requirements 36
6. Other Considerations 39 6. Other Considerations 39
6.1. Preservation of User Information 6.1. Preservation of User Information
6.2. Short Names 6.2. Short Names 40
6.3. Cache and Shadowing 40 6.3. Cache and Shadowing
7. Implementation Guidelines 7. Implementation Guidelines
7.1. Server Guidelines 7.1. Server Guidelines
7.2. Client Guidelines 41 7.2. Client Guidelines 41
8. Security Considerations 8. Security Considerations
9. IANA Considerations 9. IANA Considerations 42
10. Acknowledgments 42 10. Acknowledgments 43
11. Author's Address 11. Editor's Address
12. References 43 12. References
12.1. Normative References 12.1. Normative References
12.2. Informative References 44 12.2. Informative References 45
Appendix A. Changes Appendix A. Changes
A.1 Changes to RFC 2251 44 Intellectual Property Rights 49
A.2 Changes to RFC 2252 46 Full Copyright
A.3 Changes to RFC 2256 48
Intellectual Property Rights
Full Copyright 49
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]. [Roadmap].
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 is
collectively known as the Directory Information Base (DIB). A collectively known as the Directory Information Base (DIB). A
skipping to change at page 3, line 37 skipping to change at page 3, line 36
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 models.
Section 4 discusses the subschema information model and subschema Section 4 discusses the subschema information model and subschema
discovery. Section 5 discusses the DSA (Server) Informational Model. discovery. Section 5 discusses the DSA (Server) Informational Model.
Other X.500 information models, such as access control, collective Other X.500 information models, such as access control distribution
attribute, distribution knowledge, and replication knowledge knowledge, and replication knowledge information models, may be
information models, may be adapted for use in LDAP. Specification of adapted for use in LDAP. Specification of how these models apply to
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 [Roadmap] 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 summaries changes to these portions of sections 4 and 6. Appendix A.1 summaries changes to these
sections. The remainder of RFC 2251 is obsoleted by the [Protocol], sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
skipping to change at page 4, line 17 skipping to change at page 4, line 15
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
summaries changes to these sections. The remainder of RFC 2252 is summaries changes to these sections. The remainder of RFC 2252 is
obsoleted by [Syntaxes]. obsoleted by [Syntaxes].
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 [Schema] and [Syntaxes].
1.2. Relationship to X.501 1.2. Relationship to X.501
This document includes material, with and without adaptation, from the This document includes material, with and without adaptation, from
[X.501]. The material in this document takes precedence over that in [X.501]. The material in this document takes precedence over that in
[X.501]. [X.501].
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
skipping to change at page 4, line 42 skipping to change at page 4, line 40
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) [RFC2234]. 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 = UALPHA / %x61-7A ; "A"-"Z" / "a"-"z"
UALPHA = %x41-5A ; "A"-"Z"
DIGIT = %x30 / LDIGIT ; "0"-"9" DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9" LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
SP = 1*SPACE ; one or more " " SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " " WSP = 0*SPACE ; zero or more " "
NULL = %x00 ; null (0) NULL = %x00 ; null (0)
SPACE = %x20 ; space (" ") SPACE = %x20 ; space (" ")
DQUOTE = %x22 ; quote (""") DQUOTE = %x22 ; quote (""")
SHARP = %x23 ; octothorpe (or sharp sign) ("#") SHARP = %x23 ; octothorpe (or sharp sign) ("#")
DOLLAR = %x24 ; dollar sign ("$") DOLLAR = %x24 ; dollar sign ("$")
SQUOTE = %x27 ; single quote ("'") SQUOTE = %x27 ; single quote ("'")
LPAREN = %x28 ; left paren ("(") LPAREN = %x28 ; left paren ("(")
RPAREN = %x29 ; right paren (")") RPAREN = %x29 ; right paren (")")
PLUS = %x2B ; plus sign ("+") PLUS = %x2B ; plus sign ("+")
COMMA = %x2C ; comma (",") COMMA = %x2C ; comma (",")
skipping to change at page 5, line 25 skipping to change at page 5, line 20
LPAREN = %x28 ; left paren ("(") LPAREN = %x28 ; left paren ("(")
RPAREN = %x29 ; right paren (")") RPAREN = %x29 ; right paren (")")
PLUS = %x2B ; plus sign ("+") PLUS = %x2B ; plus sign ("+")
COMMA = %x2C ; comma (",") COMMA = %x2C ; comma (",")
HYPHEN = %x2D ; hyphen ("-") HYPHEN = %x2D ; hyphen ("-")
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 (">")
X = %x58 ; uppercase x ("X")
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 character ; Any UTF-8 [UTF-8] encoded UCS [ISO10646] 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)
; Any octet OCTET = %x00-FF ; Any octet
OCTET = %x00-FF
Object identifiers (OIDs) [X.680] are represented in LDAP using a dot- Object identifiers (OIDs) [X.680] are represented in LDAP using a dot-
decimal format conforming to the ABNF: decimal format conforming to the ABNF:
numericoid = number *( 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 which
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.
When the <descr> form is used, the representation SHALL be considered Implementations SHOULD treat short names (descriptors) used in an
invalid if the usage is not restricted as discussed above or the unambiguous manner (as discussed above) as unrecognized.
implementation cannot determine unambiguously which object identifier
the <descr> refers to.
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).
skipping to change at page 8, line 5 skipping to change at page 7, line 44
name, known as its Relative Distinguished Name (RDN) [X.501], is name, known as its Relative Distinguished Name (RDN) [X.501], is
composed of an unordered set of one or more attribute value assertions composed of an unordered set of one or more attribute value assertions
(AVA) consisting of an attribute description with zero options and an (AVA) consisting of an attribute description with zero options and an
attribute value. These AVAs are chosen from the attributes of the attribute value. These AVAs are chosen from the attributes of the
entry. 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 example string representations of RDNs [LDAPDN]: The following are examples of string representations of RDNs [LDAPDN]:
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.2.2. Distinguished Names 2.2.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 example string representations of DNs tree. The following are examples of string representations of DNs
[LDAPDN]: [LDAPDN]:
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.2.3. Alias Names 2.2.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 Section
2.6. 2.6.
2.3. Structure of an Entry 2.3. Structure of an Entry
An entry consists of a set of attributes which hold information about An entry consists of a set of attributes which hold information about
the object which entry represents. Some attributes represent user the object which 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 called
operational attributes. 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 which consists of the attribute
description 'givenName' (the 'givenName' attribute type [Schema] and description 'givenName' (the 'givenName' attribute type [Schema] and
zero options) and one or more associated values. zero options) and one or more associated values.
skipping to change at page 9, line 10 skipping to change at page 9, line 5
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. No two values of an attribute may be subtypes and other functions. No two values of an attribute may be
equivalent. equivalent.
Two values are considered equivalent if they would match according to Two values are considered equivalent if they would match according to
the equality matching rule of the attribute type. If the attribute the equality matching rule of the attribute type. If the attribute
type is defined with no equality matching rule, two values are type is defined with no equality matching rule, two values are
equivalent if and only if they are identical. equivalent if and only if they are identical.
For example, the 'givenName' attribute can have can have more than one For example, a 'givenName' attribute can have can have more than one
value, they must be Directory Strings, and they are case insensitive. value, they must be Directory Strings, and they are case insensitive.
The 'givenName' attribute cannot hold both "John" and "JOHN" as these A 'givenName' attribute cannot hold both "John" and "JOHN" as these
are equivalent values per the equality matching rule of the attribute are equivalent values per the equality matching rule of the attribute
type. type.
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) which share certain characteristics" [X.501].
As defined in [X.501]: As defined in [X.501]:
skipping to change at page 10, line 32 skipping to change at page 10, line 27
unless it belongs to a structural or auxiliary class which inherits unless it belongs to a structural or auxiliary class which inherits
from that abstract class. from that abstract class.
Abstract object classes can not derive from structural nor auxiliary Abstract object classes can not derive from structural nor auxiliary
object classes. object classes.
All structural object classes derive (directly or indirectly) from the All structural object classes derive (directly or indirectly) from the
'top' abstract object class. Auxiliary object classes do not '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 '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
skipping to change at page 11, line 27 skipping to change at page 11, line 25
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 the
'top' abstract object class. '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 as
all classes in its structural object class's superclass chain, which all classes in its structural object class's superclass chain.
always includes 'top'.
2.4.3. Auxiliary Object Classes 2.4.3. Auxiliary Object Classes
Auxiliary object classes are used augment the characteristics of Auxiliary object classes are used 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 attributes to be present in an entry. They can required and allowed to be present in an entry. They can be used to
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 structural classes allowed by the DIT content rule associated with the structural
object class of the entry. If no DIT content rule is associated with object class of the entry. If no DIT content rule is associated with
the structural object class of the entry, the entry cannot belong to the structural object class of the entry, the entry cannot belong to
any auxiliary object class. any auxiliary object class.
The set of auxiliary object classes which an entry belongs to can The set of auxiliary object classes which 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 Section
skipping to change at page 12, line 29 skipping to change at page 12, line 24
productions are case insensitive. The order in which <option>s appear productions are case insensitive. The order in which <option>s appear
is irrelevant. That is, any two <attributedescription>s which consist is irrelevant. That is, any two <attributedescription>s which consist
of the same <attributetype> and same set of <option>s are equivalent. 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 which consisting of an unrecognized attribute An attribute description with an unrecognized attribute type is to be
type is to be treated as unrecognized. Servers SHALL treat an treated as unrecognized. Servers SHALL treat an attribute description
attribute description with an unrecognized attribute option as with an unrecognized attribute option as unrecognized. Clients MAY
unrecognized. Clients MAY treat an unrecognized attribute option as a treat an unrecognized attribute option as a tagging option (see
tagging option (see Section 2.5.2.1). 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.
The attribute type indicates whether the attribute is a user attribute The attribute type indicates whether the attribute is a user attribute
or an operational attribute. If operational, the attribute type or an operational attribute. If operational, the attribute type
indicates the operational usage and whether the attribute can indicates the operational usage and whether the attribute is
modifiable by users or not. Operational attributes discussed in modifiable by users or not. Operational attributes are discussed in
Section 3.4. Section 3.4.
An attribute type (a subtype) may derive from another attribute type An attribute type (a subtype) may derive from a more generic attribute
(a direct supertype). The subtype inherits the matching rules and type (a direct supertype). The following restrictions apply to
syntax of its supertype. An attribute type cannot be a subtype of an subtyping:
attribute of different usage. - a subtype must have the same usage as its direct supertype,
- a subtype's syntax must be the same, or a refine of, its
supertype's syntax, and
- a subtype must be collective [RFC3671] if its supertype is
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 the direct description subtype of the attribute description said to be the direct description subtype of the attribute description
consisting of the subtype's direct supertype and no options. 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.
skipping to change at page 14, line 5 skipping to change at page 13, line 49
document. document.
Procedures for registering options are detailed in BCP 64 [BCP64bis]. Procedures for registering options are detailed in BCP 64 [BCP64bis].
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 considered 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 type has a supertype, then the attribute description is also a direct
considered a direct (description) subtype of the attribute description (description) subtype of the attribute description of the supertype
of the supertype and the N tagging options. That is, and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
'cn;lang-de;lang-en' is considered a direct subtype of 'cn;lang-de', (description) subtype of 'cn;lang-de', 'cn;lang-en', and
'cn;lang-en', and 'name;lang-de;lang-en' ('cn' is a subtype of 'name', 'name;lang-de;lang-en' ('cn' is a subtype of 'name', both are defined
both are defined in [Schema]). in [Schema]).
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]:
skipping to change at page 15, line 7 skipping to change at page 15, line 5
of its own attribute description. of its own attribute description.
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 a object or alias entry is of An attribute value stored in a 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 required For the purpose of subschema administration of the entry, a
attribute specification is fulfilled if the entry contains a value of specification that an attribute is required is fulfilled if the entry
an attribute description belonging to an attribute hierarchy if the contains a value of an attribute description belonging to an attribute
attribute type of that description is the same as the required hierarchy where the attribute type of that description is the same as
attribute's type. That is, a "MUST name" specification is fulfilled the required attribute's type. That is, a "MUST name" specification
by 'name' or 'name;x-tag-option', but is not fulfilled by 'CN' nor by is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by
'CN;x-tag-option'. Likewise, an entry may contain a value of an 'CN' nor by 'CN;x-tag-option' (even though 'CN' is a subtype of
attribute description belonging to an attribute hierarchy if the 'name'). Likewise, an entry may contain a value of an attribute
attribute type of that description is either explicitly included in description belonging to an attribute hierarchy where the attribute
the definition of an object class to which the entry belongs or type of that description is either explicitly included in the
allowed by the DIT content rule applicable to that entry. That is, definition of an object class to which the entry belongs or allowed by
'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST the DIT content rule applicable to that entry. That is, 'name' and
name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" 'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but
(nor by "MUST name"). 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (nor 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 model,
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. treated as distinct and unrelated descriptions.
2.5.4. Attribute Values 2.5.4. Attribute Values
Attribute values conform to the defined syntax of the attribute. Attribute values conform to the defined syntax of the attribute.
skipping to change at page 17, line 11 skipping to change at page 17, line 9
The 'aliasedObjectName' attribute holds the name of the entry an alias The 'aliasedObjectName' attribute holds the name of the entry an alias
points to. The 'aliasedObjectName' attribute is known as the 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 is defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
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]:
A subtree is a collection of object and alias entries situated at A subtree is a collection of object and alias entries situated at
the vertices of a tree. Subtrees do not contain subentries. The the vertices of a tree. Subtrees do not contain subentries. The
prefix sub, in subtree, emphasizes that the base (or root) vertex prefix sub, in subtree, emphasizes that the base (or root) vertex
of this tree is usually subordinate to the root of the DIT. of this tree is usually subordinate to the root of the DIT.
A subtree begins at some vertex and extends to some identifiable A subtree begins at some vertex and extends to some identifiable
lower boundary, possibly extending to leaves. A subtree is always lower boundary, possibly extending to leaves. A subtree is always
defined within a context which implicitly bounds the subtree. For defined within a context which implicitly bounds the subtree. For
example, the vertex and lower boundaries of a subtree defining a example, the vertex and lower boundaries of a subtree defining a
replicated area are bounded by a naming context. Similarly, the replicated area are bounded by a naming context.
scope of a subtree defining a specific administrative area is
limited to the context of an enclosing autonomous administrative
area.
3.2. Subentries 3.2. Subentries
A subentry is a "special sort of entry, known by the Directory, used A subentry is a "special sort of entry, known by the Directory, used
to hold information associated with a subtree or subtree refinement" to hold information associated with a subtree or subtree refinement"
[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
not detailed in this technical specification, but may be detailed in detailed in [RFC3672].
future documents.
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), to implementing X.500(93) models are, in accordance with X.500(93) as
use a subentry and that other servers are to use an object entry described in [RFC3672], to use a subentry and that other servers are
belonging to the appropriate auxiliary class normally used with the to use an object entry belonging to the appropriate auxiliary class
subentry (e.g., 'subschema' for subschema subentries) to mimic the normally used with the subentry (e.g., 'subschema' for subschema
subentry. This object entry's RDN SHALL be formed from a value of the subentries) to mimic the subentry. This object entry's RDN SHALL be
'cn' (commonName) attribute [Schema]. formed from a value of the 'cn' (commonName) attribute [Schema] (as
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 OBJECT IDENTIFIER The 'objectIdentifierMatch' matching rule and the 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 are defined in [Syntaxes].
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 user and system which (among other things) is used in conjunction with the controlling
schema to determine the permitted attributes of an entry. Values of schema to determine the permitted attributes of an entry. Values of
this attribute can be modified by clients, but the 'objectClass' this attribute can be modified by clients, but the 'objectClass'
attribute cannot be removed. attribute cannot be removed.
Servers which follow X.500(93) models SHALL restrict modifications of Servers which 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 from
being changed. That is, one cannot change a 'person' into a 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' is
a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
'x-b' to be implicitly added (if is not already present). 'x-b' to be implicitly added (if is not already present).
Servers SHALL restrict modifications of this attribute to prevent a 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 an
error. 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 maintained
by servers for administrative and operational purposes. As stated in by servers for administrative and operational purposes. As stated in
skipping to change at page 19, line 4 skipping to change at page 18, line 47
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 an
error. 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 maintained
by servers for administrative and operational purposes. As stated in by servers for administrative and operational purposes. As stated in
[X.501]: "There are three varieties of operational attributes: [X.501]: "There are three varieties of operational attributes:
Directory operational attributes, DSA-shared operational attributes, Directory operational attributes, DSA-shared operational attributes,
and DSA-specific operational 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 which 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 of
the DSA Information Model. Its values, if shared between DSAs the DSA Information Model which is shared between DSAs.
(servers) are identical (except during periods of transient
inconsistency).
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. Its values, if shared between DSAs of the DSA Information Model which is specific to the DSA (though, in
(servers), need not be identical. some cases, may be derived from information shared between DSAs)
(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
attributes. attributes:
- creatorsName: the Distinguished Name of the user who added this - creatorsName: the Distinguished Name of the user who added this
entry to the directory. entry to the directory,
- createTimestamp: the time this entry was added to the directory. - createTimestamp: the time this entry was added to the directory,
- modifiersName: the Distinguished Name of the user who last - modifiersName: the Distinguished Name of the user who last
modified this entry. 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' for all entries of the DIT. 'modifiersName', and 'modifyTimestamp' attributes for all entries of
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 which 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
skipping to change at page 21, line 16 skipping to change at page 21, line 11
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' matching
rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
are defined in [Syntaxes]. are defined in [Syntaxes].
3.4.5. 'structuralObjectClass'
This attribute indicates the structural object class of the entry.
( 2.5.21.9 NAME 'structuralObjectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
(1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
3.4.6. 'governingStructureRule'
This attribute indicates the structure rule governing the entry.
( 2.5.21.10 NAME 'governingStructureRule'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
The 'integerMatch' matching rule and INTEGER
(1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [Syntaxes].
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
skipping to change at page 22, line 22 skipping to change at page 22, line 47
by which an attribute is known, its syntax, associated matching by which an attribute is known, its syntax, associated matching
rules, whether it is an operational attribute and if so its rules, whether it is an operational attribute and if so its
type, whether it is a collective attribute, whether it is type, whether it is a collective attribute, whether it is
permitted to have multiple values and whether or not it is permitted to have multiple values and whether or not it is
derived from another attribute type; derived from another attribute type;
f) Matching Rule definitions that define matching rules. f) Matching Rule definitions that define matching rules.
And in LDAP: And in LDAP:
g) LDAP Syntaxes definitions that define encodings used in LDAP. g) LDAP Syntax definitions that define encodings used in LDAP.
4.1. Schema Definitions 4.1. Schema Definitions
Schema definitions in this section are described using ABNF and rely Schema definitions in this section are described using ABNF and rely
on the common productions specified in Section 1.2 as well as these: on the common productions specified in Section 1.2 as well as these:
noidlen = numericoid [ LCURLY len RCURLY ] noidlen = numericoid [ LCURLY len RCURLY ]
len = number len = number
oids = oid / ( LPAREN WSP oidlist WSP RPAREN ) oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid ) oidlist = oid *( WSP DOLLAR WSP oid )
extensions = *( SP xstring SP qdstrings ) extensions = *( SP xstring SP qdstrings )
xstring = "X" HYPHEN 1*( UALPHA / 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 UTF8 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 UCS 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) which are
skipping to change at page 25, line 8 skipping to change at page 25, line 23
<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, SUBSTRING provide the oid of the equality, EQUALITY, ORDERING, SUBSTRING 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;
COLLECTIVE indicates this attribute type is collective [X.501]; COLLECTIVE indicates this attribute type is collective
[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
<extensions> describe extensions. <extensions> describe extensions.
Each attribute type description must contain at least one of the SUP Each attribute type description must contain at least one of the SUP
or SYNTAX fields. or SYNTAX fields. If no SYNTAX field is provided, the attribute type
description takes its value from the supertype.
If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
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.
COLLECTIVE requires usage userApplications. Use of collective
attribute types in LDAP is not discussed in this technical
specification.
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 DSA-shared usage operational
attribute. dSAOperation usage indicates that the attribute of this attribute. dSAOperation usage indicates that the attribute of this
type is a DSA-specific operational attribute. type is a DSA-specific operational attribute.
COLLECTIVE requires usage userApplications. Use of collective
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 which can be used with that attribute type in an extensibleMatch
search filter. This is done using the 'matchingRuleUse' attribute search filter [Protocol]. This is done using the 'matchingRuleUse'
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 bound
of a value of this attribute. 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 value
with a string-based syntax, or the number of bytes in a value for all with a string-based syntax, or the number of bytes in a value for all
other syntaxes, may be indicated by appending this bound count inside other syntaxes, may be indicated by appending this bound count inside
of curly braces following the syntax's OBJECT IDENTIFIER in an of curly braces following the syntax's OBJECT IDENTIFIER in an
Attribute Type Description. This bound is not part of the syntax name Attribute Type Description. This bound is not part of the syntax name
itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
implementations should allow a string to be 64 characters long, implementations should allow a string to be 64 characters long,
although they may allow longer strings. Note that a single character although they may allow longer strings. Note that a single character
of the Directory String syntax may be encoded in more than one octet of the Directory String syntax may be encoded in more than one octet
since UTF-8 is a variable-length encoding. since UTF-8 [RFC3629] is a variable-length encoding.
4.1.3. Matching Rules 4.1.3. Matching Rules
Matching rules are used by servers to compare attribute values against Matching rules are used in performance of attribute value assertions,
assertion values when performing Search and Compare operations. They such as in performance of a Compare operation. They are also used in
are also used to identify the value to be added or deleted when evaluation of a Search filters, in determining which individual values
modifying entries, and are used when comparing a purported are be added or deleted during performance of a Modify operation, and
distinguished name with the name of an entry. used in comparison of distinguished names
A matching rule specifies the syntax of the assertion value.
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 26, line 33 skipping to change at page 27, line 4
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
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "SYNTAX" SP numericoid ; assertion syntax SP "SYNTAX" SP numericoid ; assertion syntax
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
<numericoid> is object identifier assigned to this matching rule; <numericoid> is object identifier assigned to this matching rule;
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 by object identifier; and SYNTAX identifies the assertion syntax (the syntax of the assertion
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 attributes which are suitable for use A matching rule use lists the attributes which are suitable for use
with an extensibleMatch search filter. 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:
skipping to change at page 27, line 29 skipping to change at page 27, line 46
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 applies
to; and 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 string of Universal Character Set (UCS) encoding is constrained to string of Unicode [Unicode] characters in
[ISO10646] characters in UTF-8 [UTF-8] form. 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
skipping to change at page 28, line 37 skipping to change at page 29, line 6
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 which 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). system schema). DIT content rules for superclasses of the structural
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
skipping to change at page 29, line 20 skipping to change at page 29, line 38
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 which 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 which are
required, allowed, or precluded, respectively, from appearing in required, allowed, or precluded, respectively, from appearing in
entries subject to this DIT content rule; and 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 entries can be It is sometimes desirable to regulate where object and alias entries
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
A DIT structure rule is a "rule governing the structure of the DIT by A DIT structure rule is a "rule governing the structure of the DIT by
specifying a permitted superior to subordinate entry relationship. A specifying a permitted superior to subordinate entry relationship. A
structure rule relates a name form, and therefore a structural object structure rule relates a name form, and therefore a structural object
class, to superior structure rules. This permits entries of the class, to superior structure rules. This permits entries of the
structural object class identified by the name form to exist in the structural object class identified by the name form to exist in the
DIT as subordinates to entries governed by the indicated superior DIT as subordinates to entries governed by the indicated superior
skipping to change at page 30, line 28 skipping to change at page 30, line 45
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 and one or more attribute types to be used for naming (i.e. class and one or more attribute types to be used for naming (i.e.
for the RDN). Name forms are primitive pieces of specification for the RDN). Name forms are primitive pieces of specification
used in the definition of DIT structure rules" [X.501]. used in the 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 set of required attribute types, and a set of allowed attributes a set of required attribute types, and a set of allowed attribute
types. A particular attribute type cannot be listed 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 33, line 46 skipping to change at page 34, line 17
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 [Syntaxes].
4.2.6. 'dITContentRules' 4.2.6. 'dITContentRules'
This attribute lists DIT Content Rules which are in force. This attribute lists DIT Content Rules which are present in the
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 [Syntaxes].
4.2.7. 'dITStructureRules' 4.2.7. 'dITStructureRules'
This attribute lists DIT Structure Rules which are in force. This attribute lists DIT Structure Rules which present in the
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 are
defined in [Syntaxes]. defined in [Syntaxes].
skipping to change at page 34, line 39 skipping to change at page 35, line 13
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 defined
in [Syntaxes]. in [Syntaxes].
4.3. 'extensibleObject' object class 4.3. 'extensibleObject' object class
The 'extensibleObject auxiliary object class allows entries belong to The 'extensibleObject' auxiliary object class allows entries that
it to hold any attribute type. The set of allowed attributes of this belong to it to hold any user attribute. The set of allowed attribute
class is implicitly the set of all user attributes. types of this object class is implicitly the set of all 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 The mandatory attributes of the other object classes of this entry are
still required to be present and any precluded attributes are still still required to be present and any precluded attributes are still
not allowed to be present. not allowed to be present.
Note that not all servers will implement this object class, and those
which do not will reject requests to add entries which contain this
object class, or modify an entry to add this object class.
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 base object search from the subschema (sub)entry, clients MUST issue a Search operation
where the filter is "(objectClass=subschema)" [Filters] and the list [Protocol] where baseObject is the DN of the subschema (sub)entry,
of attributes includes the names of the desired schema attributes (as scope is baseObject, filter is "(objectClass=subschema)" [Filters],
they are operational). This filter allows LDAP servers which gateway and attributes field lists the names of the desired schema attributes
to X.500 to detect that subentry information is being requested. (as they are operational). Note: the "(objectClass=subschema)" filter
allows LDAP servers which gateway to 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 a published subschema is complete nor assume
the server supports all of the schema elements it publishes nor assume the server supports all of the schema elements it publishes nor assume
the server does not support an unpublished element. 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 which jointly
provide access to a Directory Information Tree (DIT). provide access to a Directory Information Tree (DIT). The server
holding the original information is called the "master" (for that
information). Servers which hold copies of the original information
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.
DIB fragment: The portion of the DIB that is held by one master and:
DSA, comprising one or more naming contexts.
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 which 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 a
group of attributes located in the root DSE (DSA-Specific Entry), group of attributes located in the root DSE, which is named with the
which is named with the zero-length LDAPDN. These attributes are DN with zero RDNs (whose [LDAPDN] representation is as the zero-length
retrievable, subject to access control and other restrictions, if a string).
client performs a base object search of the root with the filter
"(objectClass=*)" [Filters] requesting the desired attributes. It is These attributes are retrievable, subject to access control and other
noted that root DSE attributes are operational, and like other restrictions, if a client performs a Search operation [Protocol] with
operational attributes, are not returned in search requests unless an empty baseObject, scope of baseObject, the filter "(objectClass=*)"
requested by name. [Filters], and with the attributes field listing the names of the
desired attributes. It is noted that root DSE attributes are
operational, and like other operational attributes, 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 in [Syntaxes].
Additional attributes may be defined in other documents. Additional attributes may be defined in other documents.
skipping to change at page 36, line 40 skipping to change at page 37, line 18
- supportedControl: recognized LDAP controls; - supportedControl: recognized LDAP controls;
- supportedExtension: recognized LDAP extended operations; - supportedExtension: recognized LDAP extended operations;
- 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) [SASL] mechanisms.
The values of these attributes provided may depend on session specific The values provided for these attributes may depend on
and other factors. For example, a server supporting the SASL EXTERNAL session-specific and other factors. For example, a server supporting
mechanism might only list "EXTERNAL" when the client's identity has the SASL EXTERNAL mechanism might only list "EXTERNAL" when the
been established by a lower level. See [AuthMeth]. client's identity has been established by a lower level. See
[AuthMeth].
The root DSE may also include a 'subschemaSubentry' attribute. If so, The root DSE may also include a 'subschemaSubentry' attribute. If so,
it refers to the subschema (sub)entry holding schema controlling it refers to the subschema (sub)entry holding the schema controlling
attributes of the root DSE. Client SHOULD NOT assume that the the root DSE. Clients SHOULD NOT assume that this subschema
subschema (sub)entry controlling the root DSE controls any entry held (sub)entry controls other entries held by the server. General
by the server. General subschema discovery procedures are provided in subschema discovery procedures are provided in Section 4.4.
Section 4.4.
5.1.1. 'altServer' 5.1.1. 'altServer'
The 'altServer' attribute lists URLs referring to alternative servers The 'altServer' attribute lists URIs referring to alternative servers
which may be contacted when this server becomes unavailable. If the which may be contacted when this server becomes unavailable. URIs for
server does not know of any other servers which could be used this servers implementing the LDAP are written according to [LDAPURL].
attribute will be absent. Clients may cache this information in case Other kinds of URIs may be provided. If the server does not know of
their preferred server later becomes unavailable. any other servers which could be used this attribute will be absent.
Clients may cache this information in case their preferred server
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]. [Syntaxes].
5.1.2. 'namingContexts' 5.1.2. 'namingContexts'
skipping to change at page 37, line 24 skipping to change at page 38, line 4
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]. [Syntaxes].
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, the
attribute will have a single value, and that value will be the empty attribute will have a single value, and that value will be the empty
string (indicating the root of the DIT). This attribute allows a string (indicating the root of the DIT).
client to choose suitable base objects for searching when it has
contacted a server. This attribute may be used, for example, to select a suitable entry
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 [Syntaxes].
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 the server supports. If the server does not the request controls [Protocol] the server supports. If the server
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 [BCP64bis].
( 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 [Syntaxes].
5.1.4. 'supportedExtension' 5.1.4. 'supportedExtension'
The 'supportedExtension' attribute lists object identifiers The 'supportedExtension' attribute lists object identifiers
identifying the extended operations which the server supports. If the identifying the extended operations [Protocol] which the server
server does not support any extended operations, this attribute will supports. If the server does not support any extended operations,
be absent. this attribute will be absent.
An extended operation comprises a ExtendedRequest, possibly other PDUs An extended operation generally consists of an extended request and an
defined by extension, and an ExtendedResponse [Protocol]. The object extended response but may also include other protocol data units (such
identifier assigned to the ExtendedRequest is used to identify the as intermediate responses). The object identifier assigned to the
extended operation. Other object identifiers associated with the extended request is used to identify the extended operation. Other
extended operation need not be listed. object identifiers used in the extended operation need not be 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 [BCP64bis].
( 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 [Syntaxes].
skipping to change at page 39, line 4 skipping to change at page 39, line 32
( 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 are defined in
[Syntaxes]. [Syntaxes].
5.1.6. 'supportedSASLMechanisms' 5.1.6. 'supportedSASLMechanisms'
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
[RFC2222] which the server recognizes. The contents of this attribute [SASL] which the server recognizes and/or supports [AuthMeth]. The
may depend on the current session state. If the server does not contents of this attribute may depend on the current session state.
support any SASL mechanisms this attribute will not be present. If the server does not support any SASL mechanisms this attribute 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 defined
in [Syntaxes]. in [Syntaxes].
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 which 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 the server preserve both
the value and form of value presented to ensure signature is not the value and form of value presented to ensure signature is not
invalidated. invalidated.
Where such requirements have not be explicitly stated, servers SHOULD Where such requirements have not been explicitly stated, servers
preserve the value of user information but MAY return the value in a SHOULD preserve the value of user information but MAY return the value
different form. And where a server is unable (or unwilling) to in a different form. And where a server is unable (or unwilling) to
preserve the value of user information, the server SHALL ensure that preserve the value of user information, the server SHALL ensure that
an equivalent value (per Section 2.3) is returned. 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 schema
elements. However, it is not expected that LDAP implementations with elements. However, it is not expected that LDAP implementations with
human user interface would display these short names (nor the object human user interface would display these short names (nor the object
identifiers they refer to) to the user, but would most likely be identifiers they refer to) to the user, but would most likely be
skipping to change at page 40, line 28 skipping to change at page 41, line 12
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 that
they do not violate any access control constraints placed on the data they do not violate any access control constraints placed on the data
by the originating server. by the originating server.
7. Implementation Guidelines 7. Implementation Guidelines
7.1 Server Guidelines 7.1 Server Guidelines
Servers MUST recognize all attribute types and object classes names Servers MUST recognize all names of attribute types and object classes
defined in this document but, unless stated otherwise, need not defined in this document but, unless stated otherwise, need not
support the associated functionality. Servers SHOULD recognize all support the associated functionality. Servers SHOULD recognize all
the names of attribute types and object classes defined in Section 3 the names of attribute types and object classes defined in Section 3
and 4, respectively, of [Schema]. and 4, respectively, of [Schema].
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 the 'extensibleObject' object class.
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 subentries. If so, they MUST do so in accordance Servers MAY support subentries. If so, they MUST do so in accordance
with [X.501]. Servers which do not support subentries SHOULD use with [RFC3672]. Servers which 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
Clients MUST NOT display nor attempt to decode as ASN.1, a value if In the absence of prior agreements with servers, clients SHOULD NOT
its syntax is not known. The implementation may attempt to discover assume that servers support any particular schema elements beyond
the subschema of the source entry, and retrieve the values of those referenced in Section 7.1. The client can retrieve subschema
'attributeTypes' from the subschema (sub)entry. information as described in Section 4.4.
Clients MUST NOT assume the LDAP-specific string encoding is
restricted to a UTF-8 encoded string of UCS characters or any
particular subset of particular subset of UCS (such as a printable
subset) unless such restriction is explicitly stated.
Clients MUST NOT send attribute values in a request that are not valid Clients MUST NOT display nor attempt to decode as ASN.1, a value if
according to the syntax defined for the attributes. its syntax is not known. Clients MUST NOT assume the LDAP-specific
string encoding is restricted to a UTF-8 encoded string of Unicode
characters or any particular subset of Unicode (such as a printable
subset) unless such restriction is explicitly stated. Clients SHOULD
NOT send attribute values in a request that are not 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 [Protocol] and [AuthMeth].
skipping to change at page 41, line 47 skipping to change at page 42, line 31
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 XXXX
Author/Change Controller: IESG Author/Change Controller: IESG
Comments: Comments:
The following descriptors (short names) should be updated to refer The following descriptors (short names) should be added to
to RFC XXXX. the registry.
NAME Type OID
------------------------ ---- -----------------
governingStructureRule A 2.5.21.10
structuralObjectClass A 2.5.21.5
The following descriptors (short names) should be updated to
refer to this RFC.
NAME Type OID NAME Type OID
------------------------ ---- ----------------- ------------------------ ---- -----------------
alias O 2.5.6.1 alias O 2.5.6.1
aliasedEntryName A 2.5.4.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
dITContentRules A 2.5.21.2 dITContentRules A 2.5.21.2
dITStructureRules A 2.5.21.1 dITStructureRules A 2.5.21.1
extensibleObject O 1.3.6.1.4.1.1466.101.120.111 extensibleObject O 1.3.6.1.4.1.1466.101.120.111
ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16 ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
matchingRuleUse A 2.5.21.8 matchingRuleUse A 2.5.21.8
skipping to change at page 42, line 42 skipping to change at page 43, line 30
top O 2.5.6.0 top O 2.5.6.0
10. Acknowledgments 10. Acknowledgments
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 Mark Wahl, Tim Howes, and Steve Kille. from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
This document is a product of the IETF LDAP Revison (LDAPBIS) Working This document is a product of the IETF LDAP Revision (LDAPBIS) Working
Group. Group.
11. Author's Address 11. Editor's Address
Kurt Zeilenga Kurt Zeilenga
E-mail: <kurt@openldap.org> E-mail: <kurt@openldap.org>
12. References 12. References
12.1. Normative References 12.1. 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 (also RFC 2119), March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC3639] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3639 (also STD 63), November 2003.
[RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
December 2003.
[RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
3672, December 2003.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
ietf-ldapbis-bcp64-xx.txt, a work in progress. ietf-ldapbis-bcp64-xx.txt, a work in progress.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress. progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress. draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms", Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.
[Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
Representation of Search Filters", Representation of Search Filters",
draft-ietf-ldapbis-filter-xx.txt, a work in progress. draft-ietf-ldapbis-filter-xx.txt, a work in progress.
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress. draft-ietf-ldapbis-url-xx.txt, a work in progress.
[SASL] Melnikov, A. (Editor), "Simple Authentication and [SASL] Melnikov, A. (Editor), "Simple Authentication and
Security Layer (SASL)", Security Layer (SASL)",
draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Schema] Dally, K. (editor), "LDAP: User Schema", [Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress. progress.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO [Unicode] The Unicode Consortium, "The Unicode Standard, Version
10646", draft-yergeau-rfc2279bis-xx.txt, a work in 3.2.0" is defined by "The Unicode Standard, Version 3.0"
progress. (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
as amended by the "Unicode Standard Annex #27: Unicode
[ISO10646] International Organization for Standardization, 3.1" (http://www.unicode.org/reports/tr27/) and by the
"Universal Multiple-Octet Coded Character Set (UCS) - "Unicode Standard Annex #28: Unicode 3.2"
Architecture and Basic Multilingual Plane", ISO/IEC (http://www.unicode.org/reports/tr28/).
10646-1 : 1993.
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[X.500] International Telecommunication Union - [X.500] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory Telecommunication Standardization Sector, "The Directory
-- Overview of concepts, models and services," -- Overview of concepts, models and services,"
X.500(1993) (also ISO/IEC 9594-1:1994). 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 Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994). -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
skipping to change at page 45, line 11 skipping to change at page 46, line 6
This document incorporates from RFC 2251 sections 3.2 and 3.4, This document incorporates from RFC 2251 sections 3.2 and 3.4,
portions of Section 4 and 6 as summarized below. portions of Section 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 LDAP
in greater detail, especially in areas where the models require in greater detail, especially in areas where adaptation is needed.
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 described
as an attribute description, a type with zero or more options, and one as an attribute description, a type with zero or more options, and one
or more associated values. 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 these
skipping to change at page 47, line 9 skipping to change at page 48, line 5
string representation of an OBJECT IDENTIFIER was tighten to string representation of an OBJECT IDENTIFIER was tighten to
disallow leading zeros as described in RFC 2252 text. disallow leading zeros as described in RFC 2252 text.
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 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 can be used as the value in a NAME part of an AttributeDescription 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 as to the semantics of attribute options appearing in specification of the semantics of attribute options appearing in
NAME fields. NAME 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 is discussed in Section 6.2 (Short Names). issues is discussed in Section 6.2 (Short Names).
skipping to change at page 47, line 32 skipping to change at page 48, line 28
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 '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 list the OBJECT IDENTIFIERs associated with the request only list the OBJECT IDENTIFIERs associated with the request
controls it recognizes. controls it recognizes.
Descriptions for the 'structuralObjectClass' and
'governingStructureRule' operational attribute types were added.
A.2.3 Section 7 of RFC 2252 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 of how it
skipping to change at page 49, line 7 skipping to change at page 50, line 8
from the IETF Secretariat. from the IETF Secretariat.
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 which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Full Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed, copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English. or as required to translate it into languages other than English.
 End of changes. 

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