draft-ietf-ldapbis-models-00.txt   draft-ietf-ldapbis-models-01.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: 21 August 2002 21 February 2002 Expires in six months 28 May 2002
Obsoletes: RFC 2251 Obsoletes: RFC 2251, RFC 2252, RFC 2256
LDAP: Directory Information Models LDAP: Directory Information Models
<draft-ietf-ldapbis-models-00.txt> <draft-ietf-ldapbis-models-01.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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Copyright 2002, The Internet Society. All Rights Reserved. Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for Please see the Copyright section near the end of this document for
more information. 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. describes the X.500 Directory Information Models, as used in LDAP.
Table of Contents
Status of this Memo 1
Abstract
Table of Contents 2
1. Introduction 4
1.1. Relationship to Other LDAP Specifications
1.2. Conventions 5
1.3. Common ABNF Productions
2. Model of Directory User Information 7
2.1. The Directory Information Tree
2.2. Naming of Entries 8
2.2.1. Relative Distinguished Names
2.2.2. Distinguished Names
2.2.3. Alias Names
2.3. Structure of an Entry
2.4. Object Classes 9
2.4.1. Abstract Object Classes 10
2.4.2. Structural Object Classes
2.4.3. Auxiliary Object Classes 11
2.5. Attribute Descriptions
2.5.1. Attribute Types 12
2.5.2. Attribute Options 13
2.5.2.1. Tagging Options
2.5.3. Attribute Description Hierarchies 14
2.5.4. Attribute Values 15
2.6. Alias Entries
2.6.1. 'alias' 16
2.6.2. 'aliasObjectName'
3. Directory Administrative and Operational Information
3.1. Subtrees
3.2. Subentries 17
3.3. The ObjectClass attribute
3.4. Operational attributes
3.4.1. 'createTimestamp' 18
3.4.2. 'modifyTimestamp'
3.4.3. 'creatorsName' 19
3.4.4. 'modifiersName'
4. Directory Schema
4.1. Schema Definitions 21
4.1.1. Object Class Definitions 22
4.1.2. Attribute Types
4.1.3. Matching Rules 24
4.1.4. LDAP Syntaxes 25
4.1.5. DIT Content Rules 26
4.1.6. DIT Structural Rules and Name Forms 27
4.2. Subschema Subentries 29
4.2.1. 'objectClasses' 30
4.2.2. 'attributeTypes'
4.2.3. 'matchingRules'
4.2.4. 'matchingRuleUse' 31
4.2.5. 'ldapSyntaxes'
4.2.6. 'dITContentRules'
4.2.7. 'dITStructureRules' 32
4.2.8. 'nameForms'
4.3. 'extensibleObject'
4.4. Subschema Discovery 33
5. DSA (Server) Informational Model
5.1. Server-specific Data Requirements 34
5.1.1. 'altServer'
5.1.2. 'namingContexts' 35
5.1.3. 'supportedControl'
5.1.4. 'supportedExtension' 36
5.1.5. 'supportedLDAPVersion'
5.1.6. 'supportedSASLMechanisms'
6. Other Considerations
6.1. Preservation of User Information 37
6.2. Short Names
6.3. Cache and Shadowing
7. Implementation Guidelines
7.1. Server Guidelines
7.2. Client Guidelines 38
8. Security Considerations
9. IANA Considerations 39
10. Acknowledgments 40
11. Author's Address
12. References
12.1. Normative References
12.2. Informative References 41
Appendix A. Changes
A.1 Changes to RFC 2251 42
A.1.1 Section 3.2 of RFC 2251
A.1.2 Section 3.4 of RFC 2251
A.1.2 Section 4 of RFC 2251 43
A.1.3 Section 6 of RFC 2251
A.2 Changes to RFC 2252 44
A.2.1 Section 4 of RFC 2252
A.2.2 Section 5 of RFC 2252
A.2.2 Section 7 of RFC 2252
A.3 Changes to RFC 2256 45
Copyright
1. Introduction 1. Introduction
This document discusses the X.500 Directory Information Models
[X.501], as used by LDAP.
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
Directory user, which may be a human or other entity, accesses the Directory user, which may be a human or other entity, accesses the
Directory through a client (or Directory User Agent (DUA)). The Directory through a client (or Directory User Agent (DUA)). The
client, on behalf of the directory user, interacts with one or more client, on behalf of the directory user, interacts with one or more
servers (or Directory System Agents (DSA)). A server holds a fragment servers (or Directory System Agents (DSA)). A server holds a fragment
of the Directory Information Base. of the DIB.
The DIB contains two classes of information: The DIB contains two classes of information:
1) user information (e.g., information provided and administrated 1) user information (e.g., information provided and administrated
by users). Section 2 describes the Model of User Information. by users). Section 2 describes the Model of User Information.
2) administrative and operational information (e.g., information 2) administrative and operational information (e.g., information
used to administer and/or operate the directory). Section 3 used to administer and/or operate the directory). Section 3
describes the model of Directory Administrative and Operational describes the model of Directory Administrative and Operational
Information. Information.
skipping to change at page 2, line 43 skipping to change at page 4, line 46
attribute, distribution knowledge, and replication knowledge attribute, distribution knowledge, and replication knowledge
information models, may be adapted for use in LDAP. Specification of information models, may be adapted for use in LDAP. Specification of
how these models are to be used in LDAP is left to future documents. how these models are to be used in 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 entirely the previously defined LDAP [Roadmap] which obsoletes entirely the previously defined LDAP
technical specification [LDAPTS]. technical specification [LDAPTS].
This document replaces 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. sections.
This document replaces RFC 2252 sections 4, 5 and 7 of RFC 2252. This document obsoletes RFC 2252 sections 4, 5 and 7 of RFC 2252.
Appendix A.2 summaries changes to these sections. Appendix A.2 summaries changes to these sections.
This document replaces RFC 2256 Sections 5.1 and portions of Section 7 This document obsoletes RFC 2256 Sections 5.1 and portions of Section
including all of 7.1. Appendix A.3 summarizes changes to these 7 including all of 7.1. Appendix A.3 summarizes changes to these
sections sections.
The remainder of RFC 2251 is obsoleted by the [Protocol], [AuthMeth], The remainder of RFC 2251 is obsoleted by the [Protocol], [AuthMeth],
and [Roadmap] documents. The remainder of RFC 2252 is obsoleted by and [Roadmap] documents. The remainder of RFC 2252 is obsoleted by
[Syntaxes] and [Schema]. The remainder of RFC 2256 is obsoleted by [Syntaxes] and [Schema]. The remainder of RFC 2256 is obsoleted by
[Schema] and [Syntaxes]. [Schema] and [Syntaxes].
1.2. Conventions 1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119].
Schema definitions are provided using LDAP description formats (as Schema definitions are provided using LDAP description formats (as
defined in Section 4.1). Definitions provided here are formatted defined in Section 4.1). Definitions provided here are formatted
(line wrapped) for readability. Matching rules and LDAP syntaxes (line wrapped) for readability. Matching rules and LDAP syntaxes
referenced in these defintions are defined in [Syntaxes]. referenced in these defintions are defined in [Syntaxes].
1.3. Common ABNF Productions 1.3. Common ABNF Productions
A number of syntaxes in this document are described using ABNF A number of syntaxes in this document are described using ABNF
[RFC2234]. These syntaxes rely on the following common productions: [RFC2234]. These syntaxes (as well as a number of syntaxes defined in
other documents) rely on the following common productions:
keystring = leadkeychar *keychar keystring = leadkeychar *keychar
leadkeychar = ALPHA leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT ) number = DIGIT / ( LDIGIT 1*DIGIT )
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9" DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9" LDIGIT = %x31-39 ; "1"-"9"
SP = 1*SPACE HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
WSP = 0*SPACE
DOLLAR = %x24 ; "$" SP = 1*SPACE ; one or more " "
DOT = %x2E ; "." WSP = 0*SPACE ; zero or more " "
HYPHEN = %x2D ; "-"
LCURLY = %x7B ; "{" NULL = %x00 ; null (0)
LPAREN = %x28 ; "(" SPACE = %x20 ; space (" ")
PERIOD = %x2E ; "." DQUOTE = %x22 ; quote (""")
QUOTE = %x27 ; "'" SHARP = %x23 ; octothorpe (or sharp sign) ("#")
RCURLY = %x7D ; "}" DOLLAR = %x24 ; dollar sign ("$")
RPAREN = %x29 ; ")" SQUOTE = %x27 ; single quote ("'")
SEMI = %x3B ; ";" LPAREN = %x28 ; left paren ("(")
SPACE = %x20 ; " " RPAREN = %x29 ; right paren (")")
USCORE = %x5F ; "_" PLUS = %x2B ; plus sign ("+")
X = %x58 ; "X" COMMA = %x2C ; comma (",")
HYPHEN = %x2D ; hypen ("-")
DOT = %x2E ; period (".")
SEMI = %x3B ; semicolon (";")
LANGLE = %x3C ; left angle bracket ("<")
EQUALS = %x3D ; equals sign ("=")
RANGLE = %x3E ; right angle bracket (">")
X = %x58 ; uppercase x ("X")
ESC = %x5C ; backslash ("\")
USCORE = %x5F ; underscore ("_")
LCURLY = %x7B ; left curly brace "{"
RCURLY = %x7D ; right curly brace "}"
; Any UTF-8 character ; Any UTF-8 character
UTF8 = UTF1 / UTF2 / UTF3 / UTF4 / UTF5 / UTF6 UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6
UTF0 = %x80-BF UTF0 = %x80-BF
UTF0 = %x00-7F UTF1 = %x00-7F
UTF2 = %xC0-DF 1(UTF0) UTF2 = %xC0-DF 1(UTF0)
UTF3 = %xE0-EF 2(UTF0) UTF3 = %xE0-EF 2(UTF0)
UTF4 = %xF0-F7 3(UTF0) UTF4 = %xF0-F7 3(UTF0)
UTF5 = %xF8-FB 4(UTF0) UTF5 = %xF8-FB 4(UTF0)
UTF6 = %xFC-FD 5(UTF0) UTF6 = %xFC-FD 5(UTF0)
Object identifiers are represented in LDAP using a dot-decimal format Object identifiers are represented in LDAP using a dot-decimal format
(numericoid) conforming to the ABNF: conforming to the ABNF:
numericoid = number *( DOT number ) numericoid = number *( DOT number )
Short names, known as descriptors (descr), are used as a more readable Short names, known as descriptors, are used as a more readable aliases
aliases for object identifiers. Descriptors are case insensitive and for object identifiers. Descriptors are case insensitive and conform
conform to the the ABNF: to the 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
The descr form is preferred. When a production 'oid' is encoded in a The <descr> form is preferred. When a production <oid> is encoded in
value, the descr encoding option SHOULD be used instead of the a value, the <descr> encoding option SHOULD be used instead of the
numericoid encoding option. <numericoid> encoding option.
2. Model of Directory User Information 2. Model of Directory User Information
As [X.501] states: As [X.501] states:
The purpose of the Directory is to hold, and provide access to, The purpose of the Directory is to hold, and provide access to,
information about objects of interest (objects) in some 'world'. information about objects of interest (objects) in some 'world'.
An object can be anything which is identifiable (can be named). An object can be anything which is identifiable (can be named).
An object class is an identified family of objects, or conceivable An object class is an identified family of objects, or conceivable
objects, which share certain characteristics. Every object belongs objects, which share certain characteristics. Every object belongs
to at least one class. An object class may be a subclass of other to at least one class. An object class may be a subclass of other
object classes, in which case the members of the former class, the object classes, in which case the members of the former class, the
subclass, are also considered to be members of the latter classes, subclass, are also considered to be members of the latter classes,
the superclasses. There may be subclasses of subclasses, etc., to the superclasses. There may be subclasses of subclasses, etc., to
an arbitrary depth. an arbitrary depth.
A directory entry, a named collection of information, is the basic A directory entry, a named collection of information, is the basic
unit of information held in the Directory. An object entry represents unit of information held in the Directory. An object entry represents
a particular object. An alias entry provides alternative naming. A a particular object. An alias entry provides alternative naming. A
subentry is holds administrative and/or operational information. subentry holds administrative and/or operational information.
Alias entries and subentries are not described in this specification.
The set of entries representing the DIB are organized hierarchically The set of entries representing the DIB are organized hierarchically
in a tree structure known as the Directory Information Tree (DIT). in a tree structure known as the Directory Information Tree (DIT).
Section 2.1 describes the component parts of the DIT. Section 2.1 describes the Directory Information Tree
Section 2.2 discusses naming of entries. Section 2.2 discusses naming of entries.
Section 2.3 discusses the structure of entries. Section 2.3 discusses the structure of entries.
Section 2.4 discusses object classes. Section 2.4 discusses object classes.
Section 2.5 discusses attributes Section 2.5 discusses attributes
Section 2.6 discusses alias entries
2.1. The Directory Information Tree 2.1. The Directory Information Tree
As noted above, the DIB is composed of a set of entries organized As noted above, the DIB is composed of a set of entries organized
hierarchically in a tree structure known as the Directory Information hierarchically in a tree structure known as the Directory Information
Tree (DIT). Specifically, a tree where vertices are the entries. Tree (DIT). Specifically, a tree where vertices are the entries.
The arcs between vertices define relations between entries. If an arc The arcs between vertices define relations between entries. If an arc
exists from X to Y, then the entry at X is the immediate superior of Y exists from X to Y, then the entry at X is the immediate superior of Y
and Y is the immediate subordinate of X. An entry's superiors is the and Y is the immediate subordinate of X. An entry's superiors is the
skipping to change at page 5, line 46 skipping to change at page 8, line 12
represent. DIT structural rules can be used to govern relationships represent. DIT structural rules can be used to govern relationships
between objects. between objects.
2.2. Naming of Entries 2.2. Naming of Entries
2.2.1. Relative Distinguished Names 2.2.1. Relative Distinguished Names
Each entry is named relative to its immediate superior. This relative Each entry is named relative to its immediate superior. This relative
name, known as its Relative Distinguished Name (RDN) [X.501], is name, known as its Relative Distinguished Name (RDN) [X.501], is
composed of one or more attribute value assertions (AVA) consisting of composed of one or more attribute value assertions (AVA) consisting of
an attribute description with zero options and an attribute value. an attribute description with zero options and an attribute value. An
entry's relative distinguished name must be unique among all its
siblings.
The following are example string representations of RDNs [LDAPDN]: The following are example 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
An entry's relative distinguished name must be unique among all its
siblings.
The last is an example of a multi-valued RDN. The last is an example of a multi-valued RDN.
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 example 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 Ltd.,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
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
2.6.
2.3. Structure of an Entry 2.3. Structure of an Entry
An entry consist of a set of attributes which hold information about An entry consist of a set of attributes which hold information about
the object which entry represents. the object which entry represents.
An attribute is an attribute description, a type and one or more An attribute is an attribute description, a type and one or more
options, with one or more associated values. The attribute type options, with one or more associated values. The attribute type
governs whether the attribute can have multiple values, the syntax and governs whether the attribute can have multiple values, the syntax and
matching rules used to construct and compare values of that attribute, matching rules used to construct and compare values of that attribute,
and other functions. Options indicate modes of transfer and other and other functions. Options indicate subtypes and other functions.
functions.
An example of an attribute is 'mail'. There can be one or more values An example of an attribute is 'givenName' [Schema]. There can be one
of this attribute, they must be IA5 (ASCII) strings, and they are case or more values of this attribute, they must be directory strings, and
insensitive (e.g. "somebody@example.com" will match they are case insensitive (e.g. "John" will match "JOHN").
"SOMEBODY@EXAMPLE.COM").
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]:
Object classes are used in the Directory for a number of purposes: Object classes are used in the Directory for a number of purposes:
skipping to change at page 7, line 22 skipping to change at page 9, line 36
- regulating, in conjunction with DIT content rule - regulating, in conjunction with DIT content rule
specifications, the attributes that are contained in entries; specifications, the attributes that are contained in entries;
- identifying classes of entry that are to be associated with a - identifying classes of entry that are to be associated with a
particular policy by the appropriate administrative authority. particular policy by the appropriate administrative authority.
An object class (a subclass) may be derived from an object class An object class (a subclass) may be derived from an object class
(its direct superclass) which is itself derived from an even more (its direct superclass) which is itself derived from an even more
generic object class. For structural object classes, this process generic object class. For structural object classes, this process
stops at the most generic object class, 'top'. An ordered set of stops at the most generic object class, 'top' (defined in Section
superclasses up to the most superior object class of an object 2.4.1). An ordered set of superclasses up to the most superior
class is its superclass chain. object class of an object class is its superclass chain.
An object class may be derived from two or more direct An object class may be derived from two or more direct
superclasses (superclasses not part of the same superclass chain). superclasses (superclasses not part of the same superclass chain).
This feature of subclassing is termed multiple inheritance. This feature of subclassing is termed multiple inheritance.
Each object class identifies the set of attributes required to be Each object class identifies the set of attributes required to be
present in entries belonging to the class and the set of attributes present in entries belonging to the class and the set of attributes
allowed to be present in entries belonging to the class. As an entry allowed to be present in entries belonging to the class. As an entry
of a class must meet the requirements of each class it belongs to, it of a class must meet the requirements of each class it belongs to, it
can be said that an object class inherits the sets of allowed and can be said that an object class inherits the sets of allowed and
skipping to change at page 8, line 7 skipping to change at page 10, line 22
2.4.1. Abstract Object Classes 2.4.1. Abstract Object Classes
An Abstract object class, as the name implies, provides a base of An Abstract object class, as the name implies, provides a base of
characteristics from which other object classes can be defined to characteristics from which other object classes can be defined to
inherit from. An entry cannot belong to only abstract object classes. inherit from. An entry cannot belong to only abstract object classes.
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, defined in X.Y. Auxiliary object classes 'top' abstract object class. Auxiliary object classes do not
do not necessarily derive from 'top'. necessarily derive from 'top'.
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
All entries belong to the 'top' abstract class. All entries belong to the 'top' abstract class.
2.4.2. Structural Object Classes 2.4.2. Structural Object Classes
As stated in [X.501]: As stated in [X.501]:
An object class defined for use in the structural specification of An object class defined for use in the structural specification of
the DIT is termed a structural object class. Structural object the DIT is termed a structural object class. Structural object
classes are used in the definition of the structure of the names classes are used in the definition of the structure of the names
of the objects for compliant entries. of the objects for compliant entries.
An object or alias entry is characterised by precisely one An object or alias entry is characterised by precisely one
structural object class superclass chain which has a single structural object class superclass chain which has a single
structural object class as the most subordinate object class. This structural object class as the most subordinate object class.
structural object class is referred to as the structural object This structural object class is referred to as the structural
class of the entry. object class of the entry.
Structural object classes are related to associated entries: Structural object classes are related to associated entries:
- an entry conforming to a structural object class shall - an entry conforming to a structural object class shall
represent the real-world object constrained by the object represent the real-world object constrained by the object
class; class;
- DIT structure rules only refer to structural object classes; - DIT structure rules only refer to structural object classes;
the structural object class of an entry is used to specify the the structural object class of an entry is used to specify the
position of the entry in the DIT; position of the entry in the DIT;
- the structural object class of an entry is used, along with an - the structural object class of an entry is used, along with an
associated DIT content rule, to control the content of an associated DIT content rule, to control the content of an
entry. entry.
The structural object class of an entry shall not be changed. The structural object class of an entry shall not be changed.
skipping to change at page 9, line 20 skipping to change at page 11, line 38
be used to describe entries or classes of entries. be used to describe entries or classes of entries.
Auxiliary object classes cannot subclass structural object classes. Auxiliary object classes cannot subclass structural object classes.
Each entry can belong to any number of auxiliary object classes. The Each entry can belong to any number of auxiliary object classes. The
set of auxiliary object classes which an entry belongs to can change set of auxiliary object classes which an entry belongs to can change
over time. over time.
2.5. Attribute Descriptions 2.5. Attribute Descriptions
An attribute description is composed of an attribute type (2.5.1) and An attribute description is composed of an attribute type (see Section
a set of zero or more attribute options (2.5.2). 2.5.1) and a set of zero or more attribute options (see Section
2.5.2).
An attribute description is represented by the ABNF: An attribute description is represented by the ABNF:
attributedescription = attributetype options attributedescription = attributetype options
attributetype = oid attributetype = oid
options = *( SEMI option ) options = *( SEMI option )
option = 1*keychar option = 1*keychar
where attributetype identifies the attribute type and each option where <attributetype> identifies the attribute type and each <option>
identifies an attribute option. Both attributetype and option identifies an attribute option. Both <attributetype> and <option>
productions are case insensitive. The order in which options appear productions are case insensitive. The order in which <option>s appear
is irrelevant. That is, any two attributedescriptions which consist is irrelevant. That is, any two <attributedescription>s which consist
of the same attribute type and options 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 owner
cn;lang-de;lang-en
owner
An attribute description which consisting of an unrecognized attribute An attribute description which consisting of an unrecognized attribute
type or an unrecongized attribute option is be treated unrecognized. type is to be treated as unrecongized. Servers SHALL treat an
attribute description with an unrecognized attribute option as
unrecongized. Client MAY treat an unrecongized attribute option as
tagging option (see Section 2.5.2.1).
All attributes of an entry must have distinct attribute descriptions. All attributes of an entry must have distinct attribute descriptions.
2.5.1. Attribute Types 2.5.1. Attribute Types
An attribute type governs whether the attribute can have multiple An attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used to construct and compare values, the syntax and matching rules used to construct and compare
values of that attribute, and other functions. values of that attribute, and other functions.
A user attribute type has userApplications usage. An operational A user attribute type has userApplications usage. An operational
attribute type has one of three usages: directoryOperation, attribute type has one of three usages: directoryOperation,
distributedOperation, or dsaOperation. An operational attribute type distributedOperation, or dsaOperation. An operational attribute type
may be defined as not modifiable by users. may be defined as not modifiable by users.
An user attribute type cannot be a subtype of an operational attribute A user attribute type cannot be a subtype of an operational attribute
type. An operational attribute type which is a subtype must be type. An operational attribute type which is a subtype must be
subtype of an operational attribute type of the same usage subtype of an operational attribute type of the same usage
(application). (application).
An attribute type (a subtype) may derive from another attribute type An attribute type (a subtype) may derive from another attribute type
(a direct supertype). The subtype inherits the matching rules and (a direct supertype). The subtype inherits the matching rules and
syntax of its supertype. syntax of its supertype.
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 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 known as descriptors. optionally, one or more short names known as 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 two kinds: technical specification details one kind: tagging options.
- tagging options (such as language tag options), defined below and
- transfer options (such as ;binary), defined in [Protocol].
Not all options can be associated with attributes held in the Not all options can be associated with attributes held in the
directory. Tagging options can be. Transfer options cannot be. directory. Tagging options can be.
Not all options can be use in conjunction with all attribute types.
In such cases, the attribute description is to be treated as
unrecognized.
An attribute description that contains mutually exclusive options An attribute description that contains mutually exclusive options
shall be treated as unrecognized. That is, "cn;binary;gser" (where shall be treated as unrecognized. That is, "cn;x-bar;x-foo" (where
"binary" and "gser" are mutually exclusive) is to be treated as an "x-foo" and "x-bar" are mutually exclusive) is to be treated as
unrecognized attribute. unrecognized.
Other kinds of options may be specified in future documents. These Other kinds of options may be specified in future documents. These
documents must detail how new kinds of options they define relate to documents must detail how new kinds of options they define relate to
tagging and transfer options. In particular, these documents must tagging and transfer options. In particular, these documents must
detail whether or not new kinds of options can be associated with detail whether or not new kinds of options can be associated with
attributes held in the directory, how new kinds of options affect attributes held in the directory, how new kinds of options affect
transfer of attribute values, and how new kinds of options are treated transfer of attribute values, and how new kinds of options are treated
in attribute description hierarchies. in attribute description hierarchies.
Options are represented as short case insensitive textual strings Options are represented as short case insensitive textual strings
conforming to the option production defined in Section 1.2 of this conforming to the <option> production defined in Section 2.5 of this
document. document.
Procedures for registering options are detailed in [LDAPIANA].
Specifications of options should use registered short names to avoid
conflicts.
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
one or more tagging options. Tagging options are never mutually one or more tagging options. Tagging options are never mutually
exclusive. exclusive.
An attribute description with N tagging options is consider a direct An attribute description with N tagging options is consider 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
considered a direct (description) subtype of the attribute description considered a direct (description) subtype of the attribute description
of the supertype and the N tagging options. That is, of the supertype and the N tagging options. That is,
'cn;lang-de;lang-en' is considered a direct subtype of 'cn;lang-de', 'cn;lang-de;lang-en' is considered a direct subtype of 'cn;lang-de',
'cn;lang-en', and 'name;lang-de;lang-en' ('cn' is a subtype of 'name', 'cn;lang-en', and 'name;lang-de;lang-en' ('cn' is a subtype of 'name',
both are defined in [SCHEMA]). both are defined 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 12, line 30 skipping to change at page 15, line 6
For an entry to contain a value of an attribute description For an entry to contain a value of an attribute description
belonging to an attribute hierarchy, the attribute type of that belonging to an attribute hierarchy, the attribute type of that
description must be explicitly included either in the definition description must be explicitly included either in the definition
of an object class to which the entry belongs, or because the DIT of an object class to which the entry belongs, or because the DIT
content rule applicable to that entry permits it. content rule applicable to that entry permits it.
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.
Note that the indicated description may include transfer and other The indicated description may include options not stored with as part
options not stored with as part of the attribute. of the attribute.
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.
When an attribute is used for naming of the entry, one and only one When an attribute is used for naming of the entry, one and only one
value of the attribute is selected to appear in the Relative value of the attribute is selected to appear in the Relative
Distinguished Name. This value is known as a distinguished value. Distinguished Name. This value is known as a distinguished value.
Only attributes whose descriptions have no options can be used for Only attributes whose descriptions have no options can be used for
naming. naming.
2.6. Alias Entries
As adapted from [X.501]:
An alias, or an alias name, for an object is a an alternative name
for an object or object entry which is provided by the use of
alias entries.
Each alias entry contains, within the 'aliasedObjectName'
attribute (known as the 'aliasedEntryName' attribute in X.500]), a
name of some object. The distinguished name of the alias entry is
thus also a name for this object.
NOTE - The name within the 'aliasedObjectName' is said to be
pointed to by the alias. It does not have to be the
distinguished name of any entry.
The conversion of an alias name to an object name is termed
(alias) dereferencing and comprises the systematic replacement of
alias names, where found within a purported name, by the value of
the corresponding 'aliasedObjectName' attribute. The process may
require the examination of more than one alias entry.
Any particular entry in the DIT may have zero or more alias names.
It therefore follows that several alias entries may point to the
same entry. An alias entry may point to an entry that is not a
leaf entry and may point to another alias entry.
An alias entry shall have no subordinates, so that an alias entry
is always a leaf entry.
Every alias entry shall belong to the 'alias' object class.
2.6.1. 'alias' object class
Alias entries belong to the 'alias' object class.
( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )
2.6.2. 'aliasedObjectName' attribute type
The 'aliasedObjectName' attribute holds the name of the entry an alias
points to. The 'aliasedObjectName' attribute is known as the
'aliasedEntryName' attribute in X.500.
( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax is 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]:
skipping to change at page 13, line 34 skipping to change at page 17, line 16
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 not detailed in this technical specification, but may be detailed in
future documents. 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 to use a subentry and other servers implementing X.500(93) models are to use a subentry and other servers
are to mimic a subentry with an object entry. This object entry's RDN use an object entry belonging to the appropriate auxiliary class
shall be formed from values of the 'cn' (commonName) attribute. normally used with the subentry (e.g., 'subschema' for subschema
subentries) to mimic the subentry. This object entry's RDN shall be
formed from a value of the 'cn' (commonName) attribute [Schema].
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
(1.3.6.1.4.1.1466.115.121.1.38) syntax is 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 user and system
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 (e.g. one cannot change a 'person' into a 'country'). being changed (e.g. one cannot change a 'person' into a 'country').
skipping to change at page 14, line 39 skipping to change at page 18, line 25
- 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.
- modifyTimestamp: the time this entry was last modified. - modifyTimestamp: the time this entry was last modified.
Servers SHOULD maintain these attributes for all entries of the DIT. Servers SHOULD maintain these attributes for all entries of the DIT.
3.4.1. createTimestamp 3.4.1. 'createTimestamp'
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 time the entry was (e.g., using the Add operation). The value is the time the entry was
added. added.
( 2.5.18.1 NAME 'createTimestamp' ( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
3.4.2. modifyTimestamp The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
are defined in [Syntaxes].
3.4.2. 'modifyTimestamp'
This attribute appears in entries which have been modified using the This attribute appears in entries which have been modified using the
protocol (e.g., using the Modify operation). The value is the time protocol (e.g., using the Modify operation). The value is the time
the entry was modified. the entry was last modified.
( 2.5.18.2 NAME 'modifyTimestamp' ( 2.5.18.2 NAME 'modifyTimestamp'
EQUALITY generalizedTimeMatch EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
3.4.3. creatorsName The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
are defined in [Syntaxes].
3.4.3. '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 distinguised name (e.g., using the Add operation). The value is the distinguised name
of the creator. of the creator.
( 2.5.18.3 NAME 'creatorsName' ( 2.5.18.3 NAME 'creatorsName'
EQUALITY distinguishedNameMatch EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
3.4.4. modifiersName The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
3.4.4. 'modifiersName'
This attribute appears in entries which have been modified using the This attribute appears in entries which have been modified using the
protocol (e.g., using the Modify operation). The value is the protocol (e.g., using the Modify operation). The value is the
distinguised name of the creator. distinguised name of the last modifier.
( 2.5.18.4 NAME 'modifiersName' ( 2.5.18.4 NAME 'modifiersName'
EQUALITY distinguishedNameMatch EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are 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 17, line 7 skipping to change at page 21, line 9
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 Syntaxes definitions that define encodings used in LDAP.
4.1. Schema Definitions 4.1. Schema Definitions
A schema definitions in this section are described using ABNF Schema definitions in this section are described using ABNF and rely
[RFC2234] and rely on the common productions specified in on the common productions specified in Section 1.2 as well as these:
Section 1.2 as well as these:
noidlen = numericoid [ LCURLY len RCURLY ] noidlen = numericoid [ LCURLY len RCURLY ]
len = number len = number
oids = oid / ( LPAREN SP oidlist SP RPAREN ) oids = oid / ( LPAREN SP oidlist SP RPAREN )
oidlist = oid *( SP DOLLAR SP oid ) oidlist = oid *( SP DOLLAR SP oid )
extensions = *( SP xstring SP qdstrings ) extensions = *( SP xstring SP qdstrings )
xstring = X HYPHEN 1*( ALPHA / HYPHEN / USCORE ) xstring = X HYPHEN 1*( ALPHA / HYPHEN / USCORE )
qdescrs = qdescr / ( LPAREN WHSP qdescrlist WHSP RPAREN ) qdescrs = qdescr / ( LPAREN WHSP qdescrlist WHSP RPAREN )
qdescrlist = [ qdescr *( WHSP qdescr ) ] qdescrlist = [ qdescr *( WHSP qdescr ) ]
qdescr = QUOTE descr QUOTE qdescr = SQUOTE descr SQUOTE
qdstring = QUOTE dstring QUOTE qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF8 string dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF8 string
QQ = %x5C %x35 %x37 ; "\27" QQ = ESC %x32 %x37 ; "\27"
QS = %x5C %x32 ( %x43 / %x63 ) ; "\5C" / "\5C" QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5C"
; Any UTF-8 character except %x27 ("'") ; Any UTF-8 encoded UCS character
QUTF8 = QUTF1 / UTF2 / UTF3 / UTF4 / UTF5 / UTF6 ; except %x27 ("'") and %x5C ("\")
QUTF8 = QUTF1 / UTFMB
; Any ASCII character except %x27 ("'") ; Any ASCII character except %x27 ("'") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F QUTF1 = %x00-26 / %x28-5B / %x5D-7F
Implementors should note that future versions of this document Schema definitions in this section also share a number of common
may expand these definitions to include additional terms. terms.
Terms whose identifier begins with "X-" are reserved for
private experiments, and MUST be followed by a <space> and a The NAME field provides a set of short names (descriptors) which are
<qdstrings> tokens. be used as aliases for the OID.
The DESC field optionally allows a descriptive string to be provided
by the directory administrator and/or implementor. While
specifications may suggest a descriptive string, there is no
requirement that the suggested (or any) descriptive string be used.
Implementors should note that future versions of this document may
expand these definitions to include additional terms. Terms whose
identifier begins with "X-" are reserved for private experiments, and
MUST be followed by a <space> and a <qdstrings> tokens.
4.1.1. Object Class Definitions 4.1.1. Object Class Definitions
Object Class definitions are written according to the ABNF: Object Class definitions are written according to the ABNF:
ObjectClassDescription = RPAREN WSP ObjectClassDescription = RPAREN WSP
numericoid ; object identifer numericoid ; object identifer
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oids ] ; superior object classes [ SP "SUP" SP oids ] ; superior object classes
[ SP kind ] ; kind of class [ SP kind ] ; kind of class
[ SP "MUST" SP oids ] ; attribute types [ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN extensions WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
where: where:
numericoid is object identifier assigned to this object class; <numericoid> is object identifier assigned to this object class;
NAME qdescrs are short names identifying this object class; NAME <qdescrs> are short names identifying this object class;
DESC qdstring are short descriptive strings; DESC <qdstring> is a store descriptive string;
OBSOLETE indicates this object class is not active; OBSOLETE indicates this object class is not active;
SUP oids specifies the direct superclasses of this object class; SUP <oids> specifies the direct superclasses of this object class;
where ABSTRACT, STRUCTURAL, AUXILIARY indicate the kind of object the kind of object class is indicated by one of ABSTRACT,
class this is, default is STRUCTURAL; STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
MUST and MAY specify the sets of required and allowed attribute MUST and MAY specify the sets of required and allowed attribute
types, respectively; and types, respectively; and
extensions describe extensions. <extensions> describe extensions.
4.1.2. Attribute Types 4.1.2. Attribute Types
Attribute Type definitions are written according to the ABNF: Attribute Type definitions are written according to the ABNF:
AttributeTypeDescription = LPAREN WSP AttributeTypeDescription = LPAREN WSP
numericoid ; object identifer numericoid ; object identifer
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
skipping to change at page 19, line 8 skipping to change at page 23, line 22
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
[ SP "USAGE" SP usage ] ; usage [ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
usage = "userApplications" / usage = "userApplications" /
"directoryOperation" / "directoryOperation" /
"distributedOperation" / ; DSA-shared "distributedOperation" / ; DSA-shared
"dsaOperation" ; DSA-specific "dsaOperation" ; DSA-specific
where: where:
numericoid is object identifier assigned to this attribute type; <numericoid> is object identifier assigned to this attribute type;
NAME qdescrs are short names identifying this attribute type; NAME <qdescrs> are short names identifying this attribute type;
DESC qdstring are short descriptive strings; DESC <qdstring> is a store descriptive string;
OBSOLETE indicates this attribute type is not active; OBSOLETE indicates this attribute type is not active;
SUP oid specifies the direct subtype of this type; SUP oid specifies the direct subtype 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 suggests a SYNTAX identifies value syntax by object identifier and suggests a
minimum upper bound; minimum upper bound;
COLLECTIVE indicates this attribute type is collective; COLLECTIVE indicates this attribute type is collective;
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.
The default USAGE is userApplications. COLLECTIVE requires USAGE The default USAGE is userApplications. COLLECTIVE requires USAGE
userApplications. NO-USER_MODIFICATION requires usage other than userApplications. NO-USER_MODIFICATION requires usage other than
userApplications. userApplications.
Note that the AttributeTypeDescription does not list the matching Note that the <AttributeTypeDescription> does not list the matching
rules which can can be used with that attribute type in an rules which can can be used with that attribute type in an
extensibleMatch search filter. This is done using the extensibleMatch search filter. This is done using the
'matchingRuleUse' attribute described in Section 4.1.3. 'matchingRuleUse' attribute described in Section 4.1.3.
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 minimun bound definition with an optional indication of the suggested minimun bound
of a value of this attribute. of a value of this attribute.
A suggested minimum upper bound on the number of characters in 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 byte of the Directory String syntax may be encoded in more than one octet
since UTF-8 is a variable-length encoding. since UTF-8 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 by servers to compare attribute values against
assertion values when performing Search and Compare operations. They assertion values when performing Search and Compare operations. They
are also used to identify the value to be added or deleted when are also used to identify the value to be added or deleted when
modifying entries, and are used when comparing a purported modifying entries, and are used when comparing a purported
distinguished name with the name of an entry. distinguished name with the name of an entry.
skipping to change at page 20, line 29 skipping to change at page 24, line 42
MatchingRuleDescription = LPAREN WSP MatchingRuleDescription = LPAREN WSP
numericoid ; object identifer numericoid ; object identifer
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "SYNTAX" SP numericoid ; oid corrected to numericoid SP "SYNTAX" SP numericoid ; oid corrected to numericoid
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 identifying this matching rule; NAME <qdescrs> are short names identifying this matching rule;
DESC qdstring are short descriptive strings; DESC <qdstring> is a store 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 by object identifier; and
extensions describe extensions. <extensions> describe extensions.
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 extensible matching rule. with an extensible matching rule.
Matching rule use descriptions (see Section 4.1.3) are written Matching rule use descriptions (see Section 4.1.3) are written
according to the following ABNF: according to the following ABNF:
MatchingRuleUseDescription = LPAREN WSP MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifer numericoid ; object identifer
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "APPLIES" SP oids ; attribute types SP "APPLIES" SP oids ; attribute types
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
numericoid is the object identifier of the matching rule associated <numericoid> is the object identifier of the matching rule
with this matching rule use description; associated with this matching rule use description;
NAME qdescrs are short names identifying this matching rule use; NAME <qdescrs> are short names identifying this matching rule use;
DESC qdstring are short descriptive strings; DESC <qdstring> is a store descriptive string;
OBSOLETE indicates this matching rule use is not active; OBSOLETE indicates this matching rule use is not active;
APPLIES provides a list of attribute types the matching rule applies APPLIES provides a list of attribute types the matching rule applies
to; and to; and
extensions describe extensions. <extensions> describe extensions.
4.1.4. LDAP Syntaxes 4.1.4. 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 native encoding. Commonly, the native encoding is known as the LDAP-specific encoding. Commonly, the LDAP-specific
constrained to [UTF-8] encoded [ISO 10646] (a superset of Unicode) encoding is constrained to string of Universal Character Set (UCS)
characters. [ISO10646] characters in UTF-8 [RFC2279] form.
Each LDAP syntax is identified by an object identifier (OID). These Each LDAP syntax is identified by an object identifier (OID). These
are not intended to be displayed to users. are not intended to be displayed to users.
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 identifer numericoid ; object identifer
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
numericoid is object identifier assigned to this LDAP syntax; <numericoid> is object identifier assigned to this LDAP syntax;
DESC qdstring are short descriptive strings; and DESC <qdstring> is a store descriptive string; and
extensions describe extensions. <extensions> describe extensions.
4.1.5. DIT Content Rules 4.1.5. DIT Content Rules
A DIT content rule is a "rule governing the content of entries of a A DIT content rule is a "rule governing the content of entries of a
particular structural object class" [X.501]. particular structural object class" [X.501].
A DIT content rule specifies for DIT entries of a particular A DIT content rule specifies for DIT entries of a particular
structural object class, which auxiliary object classes the entries structural object class, which auxiliary object classes the entries
are allowed to belong to and which additional attributes (by type) are are allowed to belong to and which additional attributes (by type) are
required, allowed or not allowed to appear in the entries. required, allowed or not allowed to appear in the entries.
skipping to change at page 22, line 43 skipping to change at page 27, line 8
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
[ SP "AUX" SP oids ] ; auxiliary object classes [ SP "AUX" SP oids ] ; auxiliary object classes
[ SP "MUST" SP oids ] ; attribute types [ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types
[ SP "NOT" SP oids ] ; attribute types [ SP "NOT" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
numericoid is the object identifier of the structural object class <numericoid> is the object identifier of the structural object class
associated with this DIT content rule; associated with this DIT content rule;
NAME qdescrs are short names identifying this DIT content rule; NAME <qdescrs> are short names identifying this DIT content rule;
DESC qdstring are short descriptive strings; DESC <qdstring> is a store descriptive string;
OBSOLETE indicates this DIT content rule use is not active; OBSOLETE indicates this DIT content rule use is not active;
AUX specifies a list of auxiliary object classes which entries AUX specifies a list of auxiliary object classes 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.6. DIT Structural Rules and Name Forms 4.1.6. DIT Structural Rules and Name Forms
It is sometimes desirable to regulate where object entries can be It is sometimes desirable to regulate where object entries can be
placed in the DIT and how they can be named based upon their placed in the DIT and how they can be named based upon their
structural object class. structural object class.
A DIT structural rule is a "rule governing the structure of the DIT by A DIT structural 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
skipping to change at page 23, line 32 skipping to change at page 27, line 46
and one or more attribute types to be used for naming (i.e. for the and one or more attribute types to be used for naming (i.e. for the
RDN). Name forms are primitive pieces of specification used in the RDN). Name forms are primitive pieces of specification used in the
definition of DIT structure rules" [X.501]. definition of DIT structure rules" [X.501].
Each name form indicates the structural object class to be named, a Each name form indicates the structural object class to be named, a
set of required attribute types, and a set of allowed attributes set of required attribute types, and a set of allowed attributes
types. A particular attribute type cannot be listed in both sets. types. A particular attribute type cannot be listed 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
attriutue 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 known as descriptors. optionally, one or more short names known as descriptors.
DIT structure rule descriptions are written according to the ABNF: DIT structure rule descriptions are written according to the ABNF:
DITStructureRuleDescription = LPAREN WSP DITStructureRuleDescription = LPAREN WSP
ruleid ; rule identifier ruleid ; rule identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
skipping to change at page 24, line 4 skipping to change at page 28, line 19
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "FORM" SP oid ; NameForm SP "FORM" SP oid ; NameForm
[ SP "SUP" ruleids ] ; superior rules [ SP "SUP" ruleids ] ; superior rules
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
ruleids = ruleid / LPAREN WSP ruleidlist WSP RPAREN ruleids = ruleid / LPAREN WSP ruleidlist WSP RPAREN
ruleidlist = [ ruleid *( SP ruleid ) ] ruleidlist = [ ruleid *( SP ruleid ) ]
ruleid = number ruleid = number
where: where:
ruleid is the rule identifier of this DIT structure rule; <ruleid> is the rule identifier of this DIT structure rule;
NAME qdescrs are short names identifying this DIT structure rule; NAME <qdescrs> are short names identifying this DIT structure rule;
DESC qdstring are short descriptive strings; DESC <qdstring> is a store descriptive string;
OBSOLETE indicates this DIT structure rule use is not active; OBSOLETE indicates this DIT structure rule use is not active;
FORM is specifies the name form associated with this DIT strucure rule; FORM is specifies the name form associated with this DIT strucure rule;
SUP identifies superior rules (by rule id); and SUP identifies superior rules (by rule id); and
extensions describe extensions. <extensions> describe extensions.
Name form descriptions are written according to the ABNF: Name form descriptions are written according to the ABNF:
NameFormDescription = LPAREN WSP NameFormDescription = LPAREN WSP
numericoid ; object identifer numericoid ; object identifer
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "OC" SP oid ; structural object class SP "OC" SP oid ; structural object class
SP "MUST" SP oids ; attribute types SP "MUST" SP oids ; attribute types
[ SP "MAY" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
numericoid is object identifier assigned to this name form; <numericoid> is object identifier assigned to this name form;
NAME qdescrs are short names identifying this name form; NAME <qdescrs> are short names identifying this name form;
DESC qdstring are short descriptive strings; DESC <qdstring> is a store descriptive string;
OBSOLETE indicates this name form is not active; OBSOLETE indicates this name form is not active;
OC identifies the structural object class this rule applies to, OC identifies the structural object class this rule applies to,
MUST and MAY specify the sets of required and allowed, respectively, MUST and MAY specify the sets of required and allowed, respectively,
naming attributes for this name form; and naming attributes for this name form; and
extensions describe extensions. <extensions> describe extensions.
4.2. Subschema Subentries 4.2. Subschema Subentries
Subschema (sub)entries are used for administering information about Subschema (sub)entries are used for administering information about
the directory schema. A single subschema (sub)entry contains all the directory schema. A single subschema (sub)entry contains all
schema definitions (see Section 4.1) used by entries in a particular schema definitions (see Section 4.1) used by entries in a particular
part of the directory tree. part of the directory tree.
Servers which follow X.500(93) models SHOULD implement subschema using Servers which follow X.500(93) models SHOULD implement subschema using
the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]), the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
and so these are not ordinary object entries but subentries (see and so these are not ordinary object entries but subentries (see
Section 3.4). LDAP clients SHOULD NOT assume that servers implement Section 3.2). LDAP clients SHOULD NOT assume that servers implement
any of the other aspects of X.500 subschema. any of the other aspects of X.500 subschema.
Servers MAY allow modification of subschema. Procedures for Subschema Servers MAY allow modification of subschema. Procedures for Subschema
Modification are discussed in Section 14.5 of [X.501]. Modification are discussed in Section 14.5 of [X.501].
A server which masters entries and permits clients to modify these A server which masters entries and permits clients to modify these
entries MUST implement and provide access to these subschema entries MUST implement and provide access to these subschema
(sub)entries including providing a 'subschemaSubentry' attribute in (sub)entries including providing a 'subschemaSubentry' attribute in
each modifiable entry. This so clients may discover the attributes each modifiable entry. This so clients may discover the attributes
and object classes which are permitted to be present. It is strongly and object classes which are permitted to be present. It is strongly
RECOMMENDED that all other servers implement this as well. RECOMMENDED that all other servers implement this as well.
The value of the subschemaSubentry attribute is the name of the A server SHALL only publish schema definitions for elements it
supports. It is noted that servers do not necessarily have to support
all schema elements referenced by a published definition.
The value of the 'subschemaSubentry' attribute is the name of the
subschema (sub)entry holding the subschema controlling the entry. subschema (sub)entry holding the subschema controlling the entry.
( 2.5.18.10 NAME 'subschemaSubentry' ( 2.5.18.10 NAME 'subschemaSubentry'
EQUALITY distinguishedNameMatch EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE
USAGE directoryOperation ) USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
Subschema is held in (sub)entries belonging to the subschema auxiliary Subschema is held in (sub)entries belonging to the subschema auxiliary
object class. object class.
( 2.5.20.1 NAME 'subschema' AUXILIARY ( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $ MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $ objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) ) matchingRuleUse ) )
The ldapSyntaxes operational attribute may also be present in The 'ldapSyntaxes' operational attribute may also be present in
subschema entries. subschema entries.
Servers MAY provide other attributes in subschema (sub)entries to Servers MAY provide other attributes in subschema (sub)entries to
reflect additional supported capabilities or for other administrative reflect additional supported capabilities or for other administrative
and operational purposes. and operational purposes.
Servers SHOULD provide the attributes 'createTimestamp' and Servers SHOULD provide the attributes 'createTimestamp' and
'modifyTimestamp' in subschema (sub)entries, in order to allow clients 'modifyTimestamp' in subschema (sub)entries, in order to allow clients
to maintain their caches of schema information. to maintain their caches of schema information.
The following subsections provide attribute type definitions for each The following subsections provide attribute type definitions for each
of schema definition attribute types. of schema definition attribute types.
4.2.1 objectClasses 4.2.1. 'objectClasses'
This attribute holds definitions of object classes supported in the This attribute holds definitions of object classes supported in the
subschema. subschema.
( 2.5.21.6 NAME 'objectClasses' ( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation ) USAGE directoryOperation )
4.2.2 attributeTypes The 'objectIdentifierFirstComponentMatch' matching rule and the
ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
defined in [Syntaxes].
4.2.2. 'attributeTypes'
This attribute holds definitions of attribute types supported in the This attribute holds definitions of attribute types supported in the
subschema. subschema.
( 2.5.21.5 NAME 'attributeTypes' ( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation ) USAGE directoryOperation )
4.2.2 matchingRules The 'objectIdentifierFirstComponentMatch' matching rule and the
AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
defined in [Syntaxes].
4.2.3. 'matchingRules'
This attribute holds definitions of matching rules supported in the This attribute holds definitions of matching rules supported in the
subschema. subschema.
( 2.5.21.4 NAME 'matchingRules' ( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
USAGE directoryOperation ) USAGE directoryOperation )
4.2.3 matchingRuleUse The 'objectIdentifierFirstComponentMatch' matching rule and the
MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
defined in [Syntaxes].
4.2.4 'matchingRuleUse'
This attribute holds definitions of matching rule uses supported in This attribute holds definitions of matching rule uses supported in
the subschema. the subschema.
( 2.5.21.8 NAME 'matchingRuleUse' ( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation ) USAGE directoryOperation )
4.2.4 ldapSyntaxes The 'objectIdentifierFirstComponentMatch' matching rule and the
MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
defined in [Syntaxes].
4.2.5. 'ldapSyntaxes'
This attribute holds definitions of LDAP syntaxes supported in the This attribute holds definitions of LDAP syntaxes supported in the
subschema. subschema.
( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
USAGE directoryOperation ) USAGE directoryOperation )
4.2.4 dITContentRules The 'objectIdentifierFirstComponentMatch' matching rule and the
SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
in [Syntaxes].
4.2.4. 'dITContentRules'
This attribute lists DIT Content Rules which are in force. This attribute lists DIT Content Rules which are in force.
( 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
DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
defined in [Syntaxes].
4.2.5 dITStructureRules 4.2.5. 'dITStructureRules'
This attribute lists DIT Structure Rules which are in force. This attribute lists DIT Structure Rules which are in force.
( 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 )
4.2.6 nameForms The 'integerFirstComponentMatch' matching rule and the
DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
defined in [Syntaxes].
4.2.6 'nameForms'
This attribute lists Name Forms which are in force. This attribute lists Name Forms which are in force.
( 2.5.21.7 NAME 'nameForms' ( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation ) USAGE directoryOperation )
4.3. Subschema Discovery The 'objectIdentifierFirstComponentMatch' matching rule and the
NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
in [Syntaxes].
Clients MAY discover the subschema (sub)entry holding the subschema 4.3. 'extensibleObject' object class
controlling a particular entry (or subentry) by reading that entry's
subschemaSubentry operational attribute.
Clients MUST read retrieve desired attributes from a subschema The 'extensibleObject auxiliary object class allows entries belong to
(sub)entry by requesting a base object search of the (sub)entry, with it to hold any attribute type. The set of allowed attributes of this
the filter "(objectClass=subschema)". This filter allows LDAP servers class is implicitly the set of all user attribute types.
which gateway to X.500 to detect detect that subentry information is
being requested. It is noted that attributes holding schema ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
definitions are operational and like other operational attributes are SUP top AUXILIARY )
be requested by name when desired.
The mandatory attributes of the other object classes of this entry are
still required to be present and any precluded attributes are still
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
To discover the DN of the subschema (sub)entry holding the subschema
controlling a particular entry (or subentry), a client reads that
entry's 'subschemaSubentry' operational attribute. To read schema
attributes from the subschema (sub)entry, clients MUST issue a base
object search where the filter is "(objectClass=subschema)" and the
list of attributes includes the names of the desired schema attributes
(as they are operational). This filter allows LDAP servers which
gateway to X.500 to detect that subentry information is being
requested.
Clients SHOULD NOT assume that server supports all referenced elements
of a particular definition. For example, a client is not to assume
the server supports the EQUALITY matching rule of a listed attribute
unless the server publishes a definition for that matching rule.
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).
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
skipping to change at page 28, line 21 skipping to change at page 33, line 43
DIB fragment: The portion of the DIB that is held by one master DIB fragment: The portion of the DIB that is held by one master
DSA, comprising one or more naming contexts. 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. And the context entries which are mastered by different servers. And the context
prefix is the name of the start entry. prefix 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 MUST provide information about itself and other An LDAP server MUST 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 (DSA-Specific Entry),
skipping to change at page 29, line 4 skipping to change at page 34, line 28
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.
- altServer: alternative servers; - altServer: alternative servers;
- namingContexts: naming contexts; - namingContexts: naming contexts;
- supportedControl: recongized LDAP controls; - supportedControl: recognized LDAP controls;
- supportedExtension: recongized LDAP extended operations; - supportedExtension: recognized LDAP extended operations;
- supportedLDAPVersion: LDAP versions supported; and - supportedLDAPVersion: LDAP versions supported; and
- supportedSASLMechanisms: recongized SASL mechnanisms. - supportedSASLMechanisms: recognized SASL mechnanisms.
The values of these attributes provided may depend on a session The values of these attributes provided may depend on a session
specific and other factors. For example, a server supporting the SASL specific and other factors. For example, a server supporting the SASL
EXTERNAL mechanism may only list "EXTERNAL" when the client's identity EXTERNAL mechanism may only list "EXTERNAL" when the client's identity
has been established by a lower level. See [AuthMeth]. 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 schema controlling
attributes of the root DSE. Client SHOULD NOT assume that the attributes of the root DSE. Client SHOULD NOT assume that the
subschema (sub)entry controlling the root DSE controls any entry held subschema (sub)entry controlling the root DSE controls any entry held
by the server. General subschema discovery procedures are provided in by the server. General subschema discovery procedures are provided in
Section 4.3. Section 4.4.
5.1.1. altServer
5.1.1. 'altServer'
The 'altServer' attribute lists URLs referring to alternative servers The 'altServer' attribute lists URLs referring to alternative servers
which may be contacted when this becomes unavailable. If the server which may be contacted when this server becomes unavailable. If the
does not know of any other servers which could be used this attribute server does not know of any other servers which could be used this
will be absent. Clients may cache this information in case their attribute will be absent. Clients may cache this information in case
preferred LDAP server later becomes unavailable. their preferred LDAP 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 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation )
The IA5 String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in The IA5 String (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 prefixs of the naming The 'namingContexts' attribute lists the context prefixs of the naming
contexts the server masters or shadows (in part or in whole). If the contexts the server masters or shadows (in part or in whole). 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 null DN of the root). This attribute allows a string (indicating the null DN of the root). This attribute allows a
client to choose suitable base objects for searching when it has client to choose suitable base objects for searching when it has
contacted a server. contacted a 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 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )
5.1.3. supportedControl The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
defined in [Syntaxes].
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 the server supports. If the server does not
support any request controls, this attribute will be absent. 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.
( 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 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
5.1.4. supportedExtension The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
defined in [Syntaxes].
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 which the server supports. If the
server does not support any extended operations, this attribute will server does not support any extended operations, this attribute will
be absent. be absent.
An extended operation comprises a ExtendedRequest and an An extended operation comprises a ExtendedRequest, possibly other PDUs
ExtendedResponse [Protocol]. The OID assigned to the ExtendedRequest defined by extension, and an ExtendedResponse [Protocol]. The object
is used to identify the extended operation. The OID of the identifier assigned to the ExtendedRequest is used to identify the
ExtendedResponse, if assigned, need not be listed. extended operation. Other object identifiers associated with the
extended operation need not be listed.
( 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 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
5.1.5. supportedLDAPVersion The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
defined in [Syntaxes].
5.1.5. 'supportedLDAPVersion'
The 'supportedLDAPVersion' attribute lists the versions of LDAP which The 'supportedLDAPVersion' attribute lists the versions of LDAP which
the server supports. the server supports.
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation )
5.1.6. supportedSASLMechanisms The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
[Syntaxes].
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 [RFC2222] which the server recognizes. The contents of this attribute
may depend on the current session state. If the server does support may depend on the current session state. If the server does not
any SASL mechanisms this attribute will not be present. 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 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation )
5. Object Class Definitions The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
in [Syntaxes].
5.1. 'top'
This abstract object class is used as a superclass of all structural
object classes.
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
5.2. 'extensibleObject'
The 'extensibleObject object class allows entries belong to it to
holds any attribute type. The set of allowed attributes of this class
is implicitly the set of all user attribute types.
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )
The mandatory attributes of the other object classes of this entry are
still required to be present and any precluded attributes are still
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.
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 and may be restrict (representation) preservation requirements. For example, a syntax
transfer to applicable modes. For example, a syntax containing containing digitally signed data can mandate the server preserve both
digitally signed data can be defined with mandates requiring values be
transferred using the ;binary option and that 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 be explicitly stated, servers SHOULD
preserve the value of user information but MAY return the value in a preserve the value of user information but MAY return the value in a
different form. Where a server is unable (or unwilling) to preserve different form. Where a server is unable (or unwilling) to preserve
the value of user information, the server SHALL ensure that an the value of user information, the server SHALL ensure that an
equivalent value is returned. Two values are considered equivalent equivalent value is returned. Two values are considered equivalent if
would match according to the equality matching rule of the associated they would match according to the equality matching rule of the
attribute as evaluated (within variances allowed by the rule's associated attribute as evaluated (within variances allowed by the
specification) on that server. If the attribute is defined with no rule's specification) on that server. If the attribute is defined
matching rule, two values are equivalent only if and only if they are with no equality matching rule, two values are equivalent only if and
identical. only if they are identical.
6.2. Short Names 6.2. Short Names
Short names (descriptors) used to identify various schema elements are Short names (descriptors) used to identify various schema elements are
non-unique, as two different specifications (neither in standards non-unique, as two different specifications (neither in Standards
track RFCs) may choose the same name. The client can retrieve the Track RFCs) may choose the same name. The client can retrieve the
subschema (as described above) to determine the element identified (in subschema (as described above) to determine the element identified (in
that subschema) by a particular short name. that subschema) by a particular short name.
Schema designers SHOULD register names they choose [LDAPIANA]. Procedures for registering short names are detailed in [LDAPIANA].
Specifications of schema elements should use registered short names to
avoid conflicts.
6.3. Cache and Shadowing 6.3. Cache and Shadowing
Some servers may hold cache or shadow copies of entries, which can be Some servers may hold cache or shadow copies of entries, which can be
used to answer search and comparison queries, but will return used to answer search and comparison queries, but will return
referrals or contact other servers if modification operations are referrals or contact other servers if modification operations are
requested. requested. Servers that perform shadowing or caching MUST ensure that
they do not violate any access control constraints placed on the data
Servers that perform shadowing or caching MUST ensure that they do not by the originating server.
violate any access control constraints placed on the data 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 defined Servers MUST recognize all attribute types and object classes defined
in this document but, unless stated otherwise, need not support the in this document but, unless stated otherwise, need not support the
associated functionality. associated functionality.
Servers SHOULD recognize all the names of object classes defined in Servers SHOULD recognize all the names of object classes defined in
Section 7 of [Schema]. Section 7 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 DIT Content Rules, DIT Structural Rules, and/or Servers MAY support DIT Content Rules, DIT Structural Rules, and/or
Name Forms. To indicate support, servers MUST provide in the Name Forms. To indicate support, servers SHOULD provide in the
subschema the definitions of attribute types associated with the subschema the definitions of attribute types associated with the
features they support. features they support.
Servers MAY support aliases as defined in [X.501]. Servers MAY support alias entries. To indicate support for alias
entries, servers SHOULD provide definitions for 'alias' and
'aliasedObjectName' in subschema (sub)entries.
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 subenties SHOULD use with [X.501]. Servers which do not support subenties SHOULD use
object entries to mimic subentries as detailed in Section 3.4. object entries to mimic subentries as detailed in Section 3.2.
Servers MAY support the 'extensibleObject' object class. To indicate Servers MAY support the 'extensibleObject' object class. To indicate
support, servers MUST provide the 'extensibleObject' definition in the support for 'extensibleObject', servers SHOULD provide the
subschema. 'extensibleObject' definition in subschema (sub)entries.
Servers MAY implement additional object classes. Servers SHOULD Servers MAY implement additional object classes. Servers SHOULD
provide the definitions of all object classes they support in in provide the definitions of all object classes they support in
subschema (sub)entries. subschema (sub)entries.
7.2 Client Guidelines 7.2 Client Guidelines
Clients MUST NOT display nor attempt to decode as ASN.1, a value if Clients MUST NOT display nor attempt to decode as ASN.1, a value if
its syntax is not known. The implementation may attempt to discover its syntax is not known. The implementation may attempt to discover
the subschema of the source entry, and retrieve the values of the subschema of the source entry, and retrieve the values of
'attributeTypes' from it. 'attributeTypes' from the subschema (sub)entry.
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 send attribute values in a request that are not valid
according to the syntax defined for the attributes. 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.
9. Acknowledgments 9. IANA Considerations
It is requested that IANA update the LDAP descriptors registry as
indicated the following template:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see comment
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
The following descriptors should be updated to refer to RFC XXXX.
NAME Type OID
------------------------ ---- -----------------
alias O 2.5.6.1
aliasedEntryName A 2.5.4.1
aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6
attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3
dITContentRules A 2.5.21.2
dITStructureRules A 2.5.21.1
extensibleObject O 1.3.6.1.4.1.1466.101.120.111
ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
matchingRuleUse A 2.5.21.8
matchingRules A 2.5.21.4
modifiersName A 2.5.18.4
modifyTimestamp A 2.5.18.2
nameForms A 2.5.21.7
namingContexts A 1.3.6.1.4.1.1466.101.120.5
objectClass A 2.5.4.0
objectClasses A 2.5.21.6
subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0
10. Acknowledgments
This document is based, in part, on [RFC2251] by M. Wahl, T. Howes, This document is based, in part, on [RFC2251] by M. Wahl, T. Howes,
and S. Kille and [RFC2252] by M. Wahl, A. Coulbeck, T. Howes, S. and S. Kille and [RFC2252] by M. Wahl, A. Coulbeck, T. Howes, S.
Kille, both products of the IETF ASID Working Group. This document is Kille, both products of the IETF Access, Searching and Indexing of
also based, in part, on "The Directory: Models" [X.501], a product of Directories (ASID) Working Group. This document is also based, in
the ITU. part, on "The Directory: Models" [X.501], a product of the
International Telephone Union (ITU).
10. Author's Address 11. Author's Address
Kurt Zeilenga Kurt Zeilenga
E-mail: <kurt@openldap.org> E-mail: <kurt@openldap.org>
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode and [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
ISO 10646", RFC 2044, October 1996. RFC 2279, January 1998.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", 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.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress. progress.
[Protocol] J. Sermersheim (editor), "LDAP: The Protocol", [Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress. draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
skipping to change at page 35, line 21 skipping to change at page 41, line 36
Models and Service", 1993. Models and Service", 1993.
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993. Definition", 1993.
[X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - [X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", 1994. Specification of Basic Notation", 1994.
11.2. Informative References 12.2. Informative References
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997. Protocol (v3)", RFC 2251, December 1997.
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997. Definitions", RFC 2252, December 1997.
[LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-xx.txt. draft-ietf-ldapbis-ldapv3-ts-xx.txt.
Appendix A. Changes to RFC 2251 / RFC 2252 Appendix A. Changes
This appendix is non-normative. This appendix is non-normative.
NOTE: This section is NOT COMPLETE. This will be corrected in a
subsequent revision.
This document amounts to nearly a complete rewrite of portions of RFC This document amounts to nearly a complete rewrite of portions of RFC
2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
overall clarity of technical specification. This appendix provides a overall clarity of technical specification. This appendix provides a
summary of substantive changes made to the portions of these documents summary of substantive changes made to the portions of these documents
incorporated into this document. Readers should consult [Roadmap], incorporated into this document. Readers should consult [Roadmap],
[Protocol], [Syntaxes], and [Schema] for summaries of remaining [Protocol], [Syntaxes], and [Schema] for summaries of remaining
portions of these documents. portions of these documents.
A.1 Changes to RFC 2251 A.1 Changes to RFC 2251
skipping to change at page 36, line 24 skipping to change at page 42, line 33
[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 the models require
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 options, and one or as an attribute description, a type with zero or options, and one or
more associated values. more associated values.
Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
objectClasses and attributeTypes attributes, yet X.500(93) treats
these attributes as optional. While generally all implementations
support X.500(93) subschema mechanisms will provide both of these
attributes, it is not absolutely required for interoperability that
all servers do. The mandate was removed for consistency with
X.500(93). The subschema discovery mechanism was also clarified to
indicate that subschema controlling an entry is obtained by reading
the (sub)entry referred to by that entry's 'subschemaSubentry'
attribute.
A.1.2 Section 3.4 of RFC 2251 A.1.2 Section 3.4 of RFC 2251
Section 3.4 of RFC 2251 provided "Server-specific Data Requirements". Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
This material, with changes, was incorporated in Section 5.1 of this This material, with changes, was incorporated in Section 5.1 of this
document. document.
Changes: Changes:
- Clarify that attributes of the root DSE are subject to "other - Clarify that attributes of the root DSE are subject to "other
restrictions" in addition to acccess controls. restrictions" in addition to acccess controls.
skipping to change at page 37, line 11 skipping to change at page 43, line 33
'subschemaSubentry' attribute within the root DSE. The previous 'subschemaSubentry' attribute within the root DSE. The previous
specification stated that the 'subschemaSubentry' attribute held in specification stated that the 'subschemaSubentry' attribute held in
the root DSE referred to "subschema entries (or subentries) known by the root DSE referred to "subschema entries (or subentries) known by
this server." This is inconsistent with the attribute intended use this server." This is inconsistent with the attribute intended use
as well as its formal definition as a single valued attribute as well as its formal definition as a single valued attribute
[X.501]. It is also noted that a simple (possibly incomplete) list [X.501]. It is also noted that a simple (possibly incomplete) list
of subschema (sub)entries is not terrible useful. This document (in of subschema (sub)entries is not terrible useful. This document (in
section 5.1) specifies that the 'subschemaSubentry' attribute of the section 5.1) specifies that the 'subschemaSubentry' attribute of the
root DSE refers to the subschema controlling the root DSE. It is root DSE refers to the subschema controlling the root DSE. It is
noted that the general subschema discovery mechanism remains noted that the general subschema discovery mechanism remains
available (see Section 4.3 of this document). available (see Section 4.4 of this document).
A.1.2 Section 4 of RFC 2251 A.1.2 Section 4 of RFC 2251
Portions of Section 4 of RFC 2251 detailing aspects of the information Portions of Section 4 of RFC 2251 detailing aspects of the information
model used by LDAP were incorporated in this document, including: model used by LDAP were incorporated in this document, including:
- Restriction of distinguished values to attributes whose descriptions - Restriction of distinguished values to attributes whose descriptions
have no options (from Section 4.1.3). have no options (from Section 4.1.3).
- Data model aspects of Attribute Types (from Section 4.1.4), - Data model aspects of Attribute Types (from Section 4.1.4),
Attribute Descriptions (from 4.1.4), Attribute (from 4.1.8), Attribute Descriptions (from 4.1.4), Attribute (from 4.1.8),
Matching Rule Identifer (from 4.1.9). Matching Rule Identifer (from 4.1.9).
- User schema requirements (from Section 4.1.6, 4.5.1, and 4.7). - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
A.1.3 Section 6 of RFC 2251 A.1.3 Section 6 of RFC 2251
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
The Section 6.1 and the section paragraph of section 6.2 of RFC 2251
where incorporated into this document. where incorporated into this document.
A.2 Changes to RFC 2252 A.2 Changes to RFC 2252
This document incorporates from RFC 2252 Sections 4, 5 and 7. This document incorporates Sections 4, 5 and 7 from RFC 2252.
A.2.1 Section 4 of RFC 2252 A.2.1 Section 4 of RFC 2252
The specification was updated to use Augmented BNF [RFC2434]. The The specification was updated to use Augmented BNF [RFC2234]. The
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+0003B) The <descr> syntax was changed to disallow semicolon (U+0003B)
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 AttributeDescription letter." In a related change, the statement "an
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 options appearing in NAME specification as to the semantics of attribute options appearing in
fields. NAME fields.
The ABNF for a quoted string (qdstring) was updated to reflect The ABNF for a quoted string (qdstring) was updated to reflect
support for the eescaping mechanism described in 4.3 of RFC 2252. support for the eescaping mechanism described in 4.3 of RFC 2252.
A.2.2 Section 5 of RFC 2252 A.2.2 Section 5 of RFC 2252
Definitions of operational attributes provided in Section 5 of RFC Definitions of operational attributes provided in Section 5 of RFC
2252 where incorporated into this document. 2252 where incorporated into this document.
The 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 recongizes. requests of the extended operations it recognizes.
The supportedControl description was clarified. A server need only The 'supportedControl' description was clarified. A server need
list the OBJECT IDENTIFIERs associated with the request controls it only list the OBJECT IDENTIFIERs associated with the request
recognizes. controls it recognizes.
A.2.2 Section 7 of RFC 2252 A.2.2 Section 7 of RFC 2252
Section 7 of RFC 2252 provides definitions of the 'extensibleObject' Section 7 of RFC 2252 provides definitions of the 'subschema' and
and 'subschema' object classes. These definitions where integrated 'extensibleObject' object classes. These definitions where
into Section 5.2 and Section 4.2 of this document, respectively. integrated into Section 4.2 and Section 4.3 of this document,
Section 7 of RFC 2252 also contained the standard object 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.
A.3 Changes to RFC 2256 A.3 Changes to RFC 2256
This document incorporates Sections 5.1 and 7.1 of RFC 2256. This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
2256.
Section 5.1 of RFC 2256 provided the definition of the 'objectClass' Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
attribute type. This was integrated into Section 3.2 of this attribute type. This was integrated into Section 2.4.1 of this
document. The statement "One of the values is either 'top' or document. The statement "One of the values is either 'top' or
'alias'" was replaced with statement that one of the values is 'top' 'alias'" was replaced with statement that one of the values is 'top'
as entries belonging to 'alias' also belong to 'top'. as entries belonging to 'alias' also belong to 'top'.
Section 5.2 of RFC 2256 provided the definition of the
'aliasedObjectName' attribute type. This was integrated into
Section 2.6.2 of this document.
Section 7.1 of RFC 2256 provided the definition of the 'top' object Section 7.1 of RFC 2256 provided the definition of the 'top' object
class. This was integrated into Section 5.1 of this document. class. This was integrated into Section 2.4.1 of this document.
Section 7.2 of RFC 2256 provided the definition of the 'alias'
object class. This was integrated into Section 2.6.1 of this
document.
Copyright 2002, The Internet Society. All Rights Reserved. Copyright 2002, The Internet Society. 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 implementation 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
 End of changes. 

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