draft-ietf-ldapbis-models-06.txt   draft-ietf-ldapbis-models-07.txt 
INTERNET-DRAFT Editor: Kurt D. Zeilenga INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 16 December 2002 Expires in six months 1 March 2003
Obsoletes: RFC 2251, RFC 2252, RFC 2256 Obsoletes: RFC 2251, RFC 2252, RFC 2256
LDAP: Directory Information Models LDAP: Directory Information Models
<draft-ietf-ldapbis-models-06.txt> <draft-ietf-ldapbis-models-07.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 35 skipping to change at page 1, line 35
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>. <http://www.ietf.org/shadow.html>.
Copyright 2002, The Internet Society. All Rights Reserved. Please Copyright 2003, The Internet Society. All Rights Reserved. Please
see the Copyright section near the end of this document for more see the Copyright section near the end of this document for more
information. information.
Abstract Abstract
The Lightweight Directory Access Protocol (LDAP) is an Internet The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in protocol for accessing distributed directory services which act in
accordance with X.500 data and service models. This document accordance with X.500 data and service models. This document
describes the X.500 Directory Information Models, as used in LDAP. describes the X.500 Directory Information Models, as used in LDAP.
Table of Contents Table of Contents
Status of this Memo 1 Status of this Memo 1
Abstract Abstract
Table of Contents 2 Table of Contents 2
1. Introduction 3 1. Introduction 3
1.1. Relationship to Other LDAP Specifications 1.1. Relationship to Other LDAP Specifications
1.2. Conventions 4 1.2. Relationship to ITU Specifications
1.3. Common ABNF Productions 1.3. Conventions 4
1.4. Common ABNF Productions
2. Model of Directory User Information 6 2. Model of Directory User Information 6
2.1. The Directory Information Tree 2.1. The Directory Information Tree
2.2. Naming of Entries 7 2.2. Naming of Entries 7
2.3. Structure of an Entry 8 2.3. Structure of an Entry 8
2.4. Object Classes 2.4. Object Classes
2.5. Attribute Descriptions 11 2.5. Attribute Descriptions 11
2.6. Alias Entries 15 2.6. Alias Entries 15
3. Directory Administrative and Operational Information 16 3. Directory Administrative and Operational Information 16
3.1. Subtrees 3.1. Subtrees
3.2. Subentries 17 3.2. Subentries 17
skipping to change at page 3, line 39 skipping to change at page 3, line 39
These two models, referred to as the generic Directory Information These two models, referred to as the generic Directory Information
Models, describe how information is represented in the Directory. Models, describe how information is represented in the Directory.
These generic models provide a framework for other information models. These generic models provide a framework for other information models.
Section 4 discusses the subschema information model and subschema Section 4 discusses the subschema information model and subschema
discovery. Section 5 discusses the DSA (Server) Informational Model. discovery. Section 5 discusses the DSA (Server) Informational Model.
Other X.500 information models, such as access control, collective Other X.500 information models, such as access control, collective
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 apply to LDAP is left to future documents.
1.1. Relationship to Other LDAP Specifications 1.1. Relationship to Other LDAP Specifications
This document is a integral part of the LDAP technical specification This document is a integral part of the LDAP technical specification
[Roadmap] which obsoletes the previously defined LDAP technical [Roadmap] which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety. specification, RFC 3377, in its entirety.
This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
portions of sections 4 and 6. Appendix A.1 summaries changes to these portions of sections 4 and 6. Appendix A.1 summaries changes to these
sections. The remainder of RFC 2251 is obsoleted by the [Protocol], sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
[AuthMeth], and [Roadmap] documents. [AuthMeth], and [Roadmap] documents.
This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
summaries changes to these sections. The remainder of RFC 2252 is summaries changes to these sections. The remainder of RFC 2252 is
obsoleted by [Syntaxes] and [Schema]. obsoleted by [Syntaxes] and [Schema].
This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2. This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
Appendix A.3 summarizes changes to these sections. The remainder of Appendix A.3 summarizes changes to these sections. The remainder of
RFC 2256 is obsoleted by [Schema] and [Syntaxes]. RFC 2256 is obsoleted by [Schema] and [Syntaxes].
1.2. Conventions 1.2. Relationship to X.501
This document includes material, with and without adaptation, from the
[X.501]. Due to the adaptation, the material included in this
document takes precedence.
1.3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119].
Schema definitions are provided using LDAP description formats (as Schema definitions are provided using LDAP description formats (as
defined in Section 4.1). Definitions provided here are formatted defined in Section 4.1). Definitions provided here are formatted
(line wrapped) for readability. Matching rules and LDAP syntaxes (line wrapped) for readability. Matching rules and LDAP syntaxes
referenced in these definitions are specified in [Syntaxes]. referenced in these definitions are specified in [Syntaxes].
1.3. Common ABNF Productions 1.4. Common ABNF Productions
A number of syntaxes in this document are described using Augmented A number of syntaxes in this document are described using Augmented
Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
number of syntaxes defined in other documents) rely on the following number of syntaxes defined in other documents) rely on the following
common productions: common productions:
keystring = leadkeychar *keychar keystring = leadkeychar *keychar
leadkeychar = ALPHA leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN keychar = ALPHA / DIGIT / HYPHEN
skipping to change at page 5, line 45 skipping to change at page 6, line 4
Object identifiers are represented in LDAP using a dot-decimal format Object identifiers are represented in LDAP using a dot-decimal format
conforming to the ABNF: conforming to the ABNF:
numericoid = number *( DOT number ) numericoid = number *( DOT number )
Short names, also known as descriptors, are used as more readable Short names, also known as descriptors, are used as more readable
aliases for object identifiers. Short names are case insensitive and aliases for object identifiers. Short names are case insensitive and
conform to the ABNF: conform to the ABNF:
descr = keystring descr = keystring
Where either an object identifier or a short name may be specified, Where either an object identifier or a short name may be specified,
the following production is used: the following production is used:
oid = descr / numericoid oid = descr / numericoid
The <descr> form is preferred. When a production <oid> is encoded (in While the <descr> form is generally preferred when the usage is
a protocol field, attribute value, assertion value, or elsewhere), the restricted to short names referring to object identifiers which
<descr> encoding option SHOULD be used instead of the <numericoid> identify like kinds of objects (e.g., attribute type descriptions,
encoding option. matching rule descriptions, object class descriptions), the
<numericoid> form should be used when the object identifiers may
identify multiple kinds of objects or when an unambiguous short name
(descriptor) is not available.
When the <descr> form is used, the representation SHALL be considered
invalid if the usage is not restricted as discussed above or the
implementation cannot determine unambiguously which object identifier
the <descr> refers to.
Short Names (descriptors) are discussed further in Section 6.2.
2. Model of Directory User Information 2. Model of Directory User Information
As [X.501] states: As [X.501] states:
The purpose of the Directory is to hold, and provide access to, The purpose of the Directory is to hold, and provide access to,
information about objects of interest (objects) in some 'world'. information about objects of interest (objects) in some 'world'.
An object can be anything which is identifiable (can be named). An object can be anything which is identifiable (can be named).
An object class is an identified family of objects, or conceivable An object class is an identified family of objects, or conceivable
skipping to change at page 7, line 15 skipping to change at page 7, line 31
entry's immediate superior and its superiors. An entry's subordinates entry's immediate superior and its superiors. An entry's subordinates
are all of its immediate subordinates and their subordinates. are all of its immediate subordinates and their subordinates.
Similarly, the superior/subordinate relationship between object Similarly, the superior/subordinate relationship between object
entries can be used to derive a relation between the objects they entries can be used to derive a relation between the objects they
represent. DIT structure rules can be used to govern relationships represent. DIT structure rules can be used to govern relationships
between objects. between objects.
Note: An entry's immediate superior is also known as the entry's Note: An entry's immediate superior is also known as the entry's
parent and an entry's immediate subordinate is also known as the parent and an entry's immediate subordinate is also known as the
entry's child. entry's child. Entries which have the same parent are known as
siblings.
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 an unordered set of one or more attribute value assertions composed of an unordered set of one or more attribute value assertions
(AVA) consisting of an attribute description with zero options and an (AVA) consisting of an attribute description with zero options and an
attribute value. These AVAs are chosen from the attributes of the attribute value. These AVAs are chosen from the attributes of the
skipping to change at page 9, line 40 skipping to change at page 10, line 8
An object class may be derived from two or more direct An object class may be derived from two or more direct
superclasses (superclasses not part of the same superclass chain). superclasses (superclasses not part of the same superclass chain).
This feature of subclassing is termed multiple inheritance. This feature of subclassing is termed multiple inheritance.
Each object class identifies the set of attributes required to be Each object class identifies the set of attributes required to be
present in entries belonging to the class and the set of attributes present in entries belonging to the class and the set of attributes
allowed to be present in entries belonging to the class. As an entry allowed to be present in entries belonging to the class. As an entry
of a class must meet the requirements of each class it belongs to, it of a class must meet the requirements of each class it belongs to, it
can be said that an object class inherits the sets of allowed and can be said that an object class inherits the sets of allowed and
required attributes from its superclasses. A subclass can identify an required attributes from its superclasses. A subclass can identify an
attribute allowed by a subclass as being required. If an attribute is attribute allowed by its superclass as being required. If an
a member of both sets, it is required to be present. attribute is a member of both sets, it is required to be present.
Each object class is defined to be one of three kinds of object Each object class is defined to be one of three kinds of object
classes: Abstract, Structural, and Auxiliary. classes: Abstract, Structural, or Auxiliary.
Each object class is identified by an object identifier (OID) and, Each object class is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors). optionally, one or more short names (descriptors).
2.4.1. Abstract Object Classes 2.4.1. Abstract Object Classes
An abstract object class, as the name implies, provides a base of An abstract object class, as the name implies, provides a base of
characteristics from which other object classes can be defined to characteristics from which other object classes can be defined to
inherit from. An entry cannot belong to an abstract object class inherit from. An entry cannot belong to an abstract object class
unless it belongs to a structural or auxiliary class which inherits unless it belongs to a structural or auxiliary class which inherits
skipping to change at page 11, line 23 skipping to change at page 11, line 39
2.4.3. Auxiliary Object Classes 2.4.3. Auxiliary Object Classes
Auxiliary object classes are used augment the characteristics of Auxiliary object classes are used augment the characteristics of
entries. They are commonly used to augment the sets of attributes entries. They are commonly used to augment the sets of attributes
required and allowed attributes to be present in an entry. They can required and allowed attributes to be present in an entry. They can
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 An entry can belong to any subset of the set of auxiliary object
set of auxiliary object classes which an entry belongs to can change classes allowed by the DIT content rule associated with structural
over time. object class of the entry. If no DIT content rule is associated with
the structural object class of the entry, the entry cannot belong to
any auxiliary object class.
The set of auxiliary object classes which an entry belongs to can
change over time.
2.5. Attribute Descriptions 2.5. Attribute Descriptions
An attribute description is composed of an attribute type (see Section An attribute description is composed of an attribute type (see Section
2.5.1) and a set of zero or more attribute options (see Section 2.5.1) and a set of zero or more attribute options (see Section
2.5.2). 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
skipping to change at page 16, line 5 skipping to change at page 16, line 25
Any particular entry in the DIT may have zero or more alias names. Any particular entry in the DIT may have zero or more alias names.
It therefore follows that several alias entries may point to the It therefore follows that several alias entries may point to the
same entry. An alias entry may point to an entry that is not a same entry. An alias entry may point to an entry that is not a
leaf entry and may point to another alias entry. leaf entry and may point to another alias entry.
An alias entry shall have no subordinates, so that an alias entry An alias entry shall have no subordinates, so that an alias entry
is always a leaf entry. is always a leaf entry.
Every alias entry shall belong to the 'alias' object class. Every alias entry shall belong to the 'alias' object class.
An entry with the 'alias' object class must also belong to an object
class (or classes), or be governed by a DIT content rule, which allows
suitable naming attributes to be present.
Example:
dn: cn=bar,dc=example,dc=com
objectClass: top
objectClass: alias
objectClass: extensibleObject
cn: bar
aliasedObjectName: cn=foo,dc=example,dc=com
2.6.1. 'alias' object class 2.6.1. 'alias' object class
Alias entries belong to the 'alias' object class. Alias entries belong to the 'alias' object class.
( 2.5.6.1 NAME 'alias' ( 2.5.6.1 NAME 'alias'
SUP top STRUCTURAL SUP top STRUCTURAL
MUST aliasedObjectName ) MUST aliasedObjectName )
2.6.2. 'aliasedObjectName' attribute type 2.6.2. 'aliasedObjectName' attribute type
skipping to change at page 18, line 5 skipping to change at page 18, line 36
this attribute to prevent the basic structural class of the entry from this attribute to prevent the basic structural class of the entry from
being changed. That is, one cannot change a 'person' into a being changed. That is, one cannot change a 'person' into a
'country'. 'country'.
When creating an entry or adding an 'objectClass' value to an entry, When creating an entry or adding an 'objectClass' value to an entry,
all superclasses of the named classes SHALL be implicitly added as all superclasses of the named classes SHALL be implicitly added as
well if not already present. That is, if the auxiliary class 'x-a' is well if not already present. That is, if the auxiliary class 'x-a' is
a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
'x-b' to added (if is not already present). 'x-b' to added (if is not already present).
Servers SHALL restrict modifications of this attribute to to prevent a Servers SHALL restrict modifications of this attribute to prevent a
superclasses of remaining 'objectClass' values from being deleted. superclasses of remaining 'objectClass' values from being deleted.
That is, if the auxiliary class 'x-a' is a subclass of the class 'x-b' That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
and the 'objectClass' attribute contains 'x-a', an attempt to delete class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
'x-b' from the 'objectClass' attribute is an error. an attempt to delete only 'x-b' from the 'objectClass' attribute is an
error.
3.4. Operational attributes 3.4. Operational attributes
Some attributes, termed operational attributes, are used or maintained Some attributes, termed operational attributes, are used or maintained
by servers for administrative and operational purposes. As stated in by servers for administrative and operational purposes. As stated in
[X.501]: "There are three varieties of operational attributes: [X.501]: "There are three varieties of operational attributes:
Directory operational attributes, DSA-shared operational attributes, Directory operational attributes, DSA-shared operational attributes,
and DSA-specific operational attributes." and DSA-specific operational attributes."
A directory operational attribute is used to represent operational A directory operational attribute is used to represent operational
and/or administrative information in the Directory Information Model. and/or administrative information in the Directory Information Model.
This includes operational attributes maintained by the server (e.g. This includes operational attributes maintained by the server (e.g.
'subschemaSubentry') as well as operational attributes which hold 'createTimeStamp') as well as operational attributes which hold values
values administrated by the user (e.g. 'matchingRuleUse'). administrated by the user (e.g. 'ditContentRules').
A DSA-shared operational attribute is used to represent information of A DSA-shared operational attribute is used to represent information of
the DSA Information Model. Its values, if shared between DSAs the DSA Information Model. Its values, if shared between DSAs
(servers) are identical (except during periods of transient (servers) are identical (except during periods of transient
inconsistency). inconsistency).
A DSA-specific operational attribute is used to represent information A DSA-specific operational attribute is used to represent information
of the DSA Information Model. Its values, if shared between DSAs of the DSA Information Model. Its values, if shared between DSAs
(servers), need not be identical. (servers), need not be identical.
skipping to change at page 22, line 49 skipping to change at page 23, line 35
The DESC field optionally allows a descriptive string to be provided The DESC field optionally allows a descriptive string to be provided
by the directory administrator and/or implementor. While by the directory administrator and/or implementor. While
specifications may suggest a descriptive string, there is no specifications may suggest a descriptive string, there is no
requirement that the suggested (or any) descriptive string be used. requirement that the suggested (or any) descriptive string be used.
The OBSOLETE field, if present, indicates the element is not active. The OBSOLETE field, if present, indicates the element is not active.
Implementors should note that future versions of this document may Implementors should note that future versions of this document may
expand these definitions to include additional terms. Terms whose expand these definitions to include additional terms. Terms whose
identifier begins with "X-" are reserved for private experiments, and identifier begins with "X-" are reserved for private experiments, and
MUST be followed by <SP> and <qdstrings> tokens. are followed by <SP> and <qdstrings> tokens.
4.1.1. Object Class Definitions 4.1.1. Object Class Definitions
Object Class definitions are written according to the ABNF: Object Class definitions are written according to the ABNF:
ObjectClassDescription = LPAREN WSP ObjectClassDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
skipping to change at page 25, line 6 skipping to change at page 25, line 38
directoryOperation usage indicates that the attribute of this type is directoryOperation usage indicates that the attribute of this type is
a directory operational attribute. distributedOperation usage a directory operational attribute. distributedOperation usage
indicates that the attribute of this DSA-shared usage operational indicates that the attribute of this DSA-shared usage operational
attribute. dSAOperation usage indicates that the attribute of this attribute. dSAOperation usage indicates that the attribute of this
type is a DSA-specific operational attribute. type is a DSA-specific operational attribute.
NO-USER-MODIFICATION requires an operational usage. NO-USER-MODIFICATION requires an operational usage.
Note that the <AttributeTypeDescription> does not list the matching Note that the <AttributeTypeDescription> does not list the matching
rules which can can be used with that attribute type in an rules which can be used with that attribute type in an extensibleMatch
extensibleMatch search filter. This is done using the search filter. This is done using the 'matchingRuleUse' attribute
'matchingRuleUse' attribute described in Section 4.1.4. described in Section 4.1.4.
This document refines the schema description of X.501 by requiring This document refines the schema description of X.501 by requiring
that the SYNTAX field in an <AttributeTypeDescription> be a string that the SYNTAX field in an <AttributeTypeDescription> be a string
representation of an object identifier for the LDAP string syntax representation of an object identifier for the LDAP string syntax
definition with an optional indication of the suggested minimum bound definition with an optional indication of the suggested minimum bound
of a value of this attribute. of a value of this attribute.
A suggested minimum upper bound on the number of characters in a value A suggested minimum upper bound on the number of characters in a value
with a string-based syntax, or the number of bytes in a value for all with a string-based syntax, or the number of bytes in a value for all
other syntaxes, may be indicated by appending this bound count inside other syntaxes, may be indicated by appending this bound count inside
skipping to change at page 26, line 14 skipping to change at page 26, line 46
NAME <qdescrs> are short names (descriptors) identifying this NAME <qdescrs> are short names (descriptors) identifying this
matching rule; matching rule;
DESC <qdstring> is a short descriptive string; DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this matching rule is not active; OBSOLETE indicates this matching rule is not active;
SYNTAX identifies the assertion syntax by object identifier; and SYNTAX identifies the assertion syntax by object identifier; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.4. Matching Rule Uses 4.1.4. Matching Rule Uses
A matching rule use lists the attributes which are suitable for use A matching rule use lists the attributes which are suitable for use
with an extensible matching rule. with an extensibleMatch search filter.
Matching rule use descriptions are written according to the following Matching rule use descriptions are written according to the following
ABNF: ABNF:
MatchingRuleUseDescription = LPAREN WSP MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "APPLIES" SP oids ; attribute types SP "APPLIES" SP oids ; attribute types
skipping to change at page 30, line 49 skipping to change at page 31, line 35
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.2). 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 subschema modification. Procedures for subschema Servers MAY allow subschema modification. Procedures for subschema
modification are discussed in Section 14.5 of [X.501]. modification are discussed in Section 14.5 of [X.501].
A server which masters entries and permits clients to modify these A server which masters entries and permits clients to modify these
entries MUST implement and provide access to these subschema entries SHALL implement and provide access to these subschema
(sub)entries including providing a 'subschemaSubentry' attribute in (sub)entries including providing a 'subschemaSubentry' attribute in
each modifiable entry. This 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 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
skipping to change at page 31, line 43 skipping to change at page 32, line 28
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.
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 )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
defined in [Syntaxes]. defined in [Syntaxes].
4.2.2. 'attributeTypes' 4.2.2. 'attributeTypes'
This attribute holds definitions of attribute types supported in the This attribute holds definitions of attribute types.
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 )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
defined in [Syntaxes]. defined in [Syntaxes].
4.2.3. 'matchingRules' 4.2.3. 'matchingRules'
This attribute holds definitions of matching rules supported in the This attribute holds definitions of matching rules.
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 )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
defined in [Syntaxes]. defined in [Syntaxes].
4.2.4 'matchingRuleUse' 4.2.4 'matchingRuleUse'
This attribute holds definitions of matching rule uses supported in This attribute holds definitions of matching rule uses.
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 )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
defined in [Syntaxes]. defined in [Syntaxes].
4.2.5. 'ldapSyntaxes' 4.2.5. 'ldapSyntaxes'
This attribute holds definitions of LDAP syntaxes supported in the This attribute holds definitions of LDAP syntaxes.
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 )
The 'objectIdentifierFirstComponentMatch' matching rule and the The 'objectIdentifierFirstComponentMatch' matching rule and the
SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
in [Syntaxes]. in [Syntaxes].
skipping to change at page 34, line 40 skipping to change at page 35, line 20
To discover the DN of the subschema (sub)entry holding the subschema To discover the DN of the subschema (sub)entry holding the subschema
controlling a particular entry, a client reads that entry's controlling a particular entry, a client reads that entry's
'subschemaSubentry' operational attribute. To read schema attributes 'subschemaSubentry' operational attribute. To read schema attributes
from the subschema (sub)entry, clients MUST issue a base object search from the subschema (sub)entry, clients MUST issue a base object search
where the filter is "(objectClass=subschema)" [Filters] and the list where the filter is "(objectClass=subschema)" [Filters] and the list
of attributes includes the names of the desired schema attributes (as of attributes includes the names of the desired schema attributes (as
they are operational). This filter allows LDAP servers which gateway they are operational). This filter allows LDAP servers which gateway
to X.500 to detect that subentry information is being requested. to X.500 to detect that subentry information is being requested.
Clients SHOULD NOT assume a published subschema is complete nor assume
the server supports all of the schema elements it publishes nor assume
the server does not support an unpublished element.
5. DSA (Server) Informational Model 5. DSA (Server) Informational Model
The LDAP protocol assumes there are one or more servers which jointly The LDAP protocol assumes there are one or more servers which jointly
provide access to a Directory Information Tree (DIT). provide access to a Directory Information Tree (DIT).
As defined in [X.501]: As defined in [X.501]:
context prefix: The sequence of RDNs leading from the Root of the context prefix: The sequence of RDNs leading from the Root of the
DIT to the initial vertex of a naming context; corresponds to DIT to the initial vertex of a naming context; corresponds to
the distinguished name of that vertex. the distinguished name of that vertex.
skipping to change at page 35, line 23 skipping to change at page 36, line 7
including all its subordinates and their subordinates, down to the including all its subordinates and their subordinates, down to the
entries which are mastered by different servers. The context prefix entries which are mastered by different servers. The context prefix
is the name of the initial entry. is the name of the initial entry.
The root of the DIT is a DSA-specific Entry (DSE) and not part of any The root of the DIT is a DSA-specific Entry (DSE) and not part of any
naming context (or any subtree); each server has different attribute naming context (or any subtree); each server has different attribute
values in the root DSE. values in the root DSE.
5.1. Server-specific Data Requirements 5.1. Server-specific Data Requirements
An LDAP server MUST provide information about itself and other An LDAP server SHALL provide information about itself and other
information that is specific to each server. This is represented as a information that is specific to each server. This is represented as a
group of attributes located in the root DSE (DSA-Specific Entry), group of attributes located in the root DSE (DSA-Specific Entry),
which is named with the zero-length LDAPDN. These attributes are which is named with the zero-length LDAPDN. These attributes are
retrievable, subject to access control and other restrictions, if a retrievable, subject to access control and other restrictions, if a
client performs a base object search of the root with the filter client performs a base object search of the root with the filter
"(objectClass=*)" [Filters] requesting the desired attributes. It is "(objectClass=*)" [Filters] requesting the desired attributes. It is
noted that root DSE attributes are operational, and like other noted that root DSE attributes are operational, and like other
operational attributes, are not returned in search requests unless operational attributes, are not returned in search requests unless
requested by name. requested by name.
skipping to change at page 36, line 21 skipping to change at page 37, line 4
been established by a lower level. See [AuthMeth]. 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.4. Section 4.4.
5.1.1. 'altServer' 5.1.1. 'altServer'
The 'altServer' attribute lists URLs referring to alternative servers The 'altServer' attribute lists URLs referring to alternative servers
which may be contacted when this server becomes unavailable. If the which may be contacted when this server becomes unavailable. If the
server does not know of any other servers which could be used this server does not know of any other servers which could be used this
attribute will be absent. Clients may cache this information in case attribute will be absent. Clients may cache this information in case
their preferred LDAP server later becomes unavailable. their preferred server later becomes unavailable.
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE dSAOperation ) USAGE dSAOperation )
The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
[Syntaxes]. [Syntaxes].
5.1.2. 'namingContexts' 5.1.2. 'namingContexts'
The 'namingContexts' attribute lists the context prefixes of the The 'namingContexts' attribute lists the context prefixes of the
naming contexts the server masters or shadows (in part or in whole). naming contexts the server masters or shadows (in part or in whole).
If the server does not master or shadow any information (e.g. it is an If the server is a first-level DSA [X.501], it should list (in
LDAP gateway to a public X.500 directory) this attribute will be addition) an empty string (indicating the root of the DIT). If the
absent. If the server believes it masters or shadows the entire server does not master or shadow any information (e.g. it is an LDAP
directory, the attribute will have a single value, and that value will gateway to a public X.500 directory) this attribute will be absent.
be the empty string (indicating the null DN of the root). This If the server believes it masters or shadows the entire directory, the
attribute allows a client to choose suitable base objects for attribute will have a single value, and that value will be the empty
searching when it has contacted a server. string (indicating the root of the DIT). This attribute allows a
client to choose suitable base objects for searching when it has
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 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE dSAOperation ) USAGE dSAOperation )
The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
defined in [Syntaxes]. defined in [Syntaxes].
5.1.3. 'supportedControl' 5.1.3. 'supportedControl'
The 'supportedControl' attribute lists object identifiers identifying The 'supportedControl' attribute lists object identifiers identifying
the request controls the server supports. If the server does not the request controls 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.
skipping to change at page 39, line 35 skipping to change at page 40, line 20
Procedures for registering short names (descriptors) are detailed in Procedures for registering short names (descriptors) are detailed in
BCP 64 [RFC3383bis]. BCP 64 [RFC3383bis].
[[The remainder of this subsection will be included a subsequent [[The remainder of this subsection will be included a subsequent
revision of RFC 3383.]] revision of RFC 3383.]]
To avoid interoperability problems, the following additional To avoid interoperability problems, the following additional
considerations are stated: considerations are stated:
Descriptors used to identify various schema SHOULD be registered Descriptors used to identify various schema elements SHOULD be
unless in private-use name space (e.g., they begin with "x-"). registered unless in private-use name space (e.g., they begin with
Descriptors defined in RFCs MUST be registered. "x-"). Descriptors defined in RFCs MUST be registered.
While the protocol allows the same descriptor to refer to While the protocol allows the same descriptor to refer to
different object identifiers in certain cases and the registry different object identifiers in certain cases and the registry
supports multiple registrations of the same descriptor (each supports multiple registrations of the same descriptor (each
indicating a different kind of schema element and different object indicating a different kind of schema element and different object
identifier), multiple registrations of the same descriptor are to identifier), multiple registrations of the same descriptor are to
be avoided. All such registration requests require Expert Review. be avoided. All such registration requests require Expert Review.
6.3. Cache and Shadowing 6.3. Cache and Shadowing
skipping to change at page 40, line 24 skipping to change at page 41, line 11
support the associated functionality. Servers SHOULD recognize all support the associated functionality. Servers SHOULD recognize all
the names of attribute types and object classes defined in Section 3 the names of attribute types and object classes defined in Section 3
and 4, respectively, of [Schema]. and 4, respectively, of [Schema].
Servers MUST ensure that entries conform to user and system schema Servers MUST ensure that entries conform to user and system schema
rules or other data model constraints. rules or other data model constraints.
Servers MAY support the 'extensibleObject' object class. Servers MAY support the 'extensibleObject' object class.
Servers MAY support DIT Content Rules. Servers MAY support DIT Servers MAY support DIT Content Rules. Servers MAY support DIT
Structure Rules, and Name Forms. Structure Rules and Name Forms.
Servers MAY support alias entries. Servers MAY support alias entries.
Servers MAY support subentries. If so, they MUST do so in accordance Servers MAY support subentries. If so, they MUST do so in accordance
with [X.501]. Servers which do not support subentries SHOULD use with [X.501]. Servers which do not support subentries SHOULD use
object entries to mimic subentries as detailed in Section 3.2. object entries to mimic subentries as detailed in Section 3.2.
Servers MAY implement additional schema elements. Servers SHOULD Servers MAY implement additional schema elements. Servers SHOULD
provide definitions of all schema elements they support in subschema provide definitions of all schema elements they support in subschema
(sub)entries. (sub)entries.
skipping to change at page 46, line 15 skipping to change at page 46, line 47
A.2 Changes to RFC 2252 A.2 Changes to RFC 2252
This document incorporates Sections 4, 5 and 7 from RFC 2252. This document incorporates Sections 4, 5 and 7 from RFC 2252.
A.2.1 Section 4 of RFC 2252 A.2.1 Section 4 of RFC 2252
The specification was updated to use Augmented BNF [RFC2234]. The The specification was updated to use Augmented BNF [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+003B)
characters to appear to be consistent its natural language characters to appear to be consistent its natural language
specification "descr is the syntactic representation of an object specification "descr is the syntactic representation of an object
descriptor, which consists of letters and digits, starting with a descriptor, which consists of letters and digits, starting with a
letter." In a related change, the statement "an letter." In a related change, the statement "an
AttributeDescription can be used as the value in a NAME part of an AttributeDescription can be used as the value in a NAME part of an
AttributeTypeDescription" was deleted. RFC 2252 provided no AttributeTypeDescription" was deleted. RFC 2252 provided no
specification as to the semantics of attribute options appearing in specification as to the semantics of attribute options appearing in
NAME fields. NAME fields.
RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
over the <numericoid> form. However, <descr> form can be ambiguous.
To address this issue, the imperative was replaced with a statement
(in Section 1.4) that while the <descr> form is generally preferred,
<numericoid> should be used where an unambiguous <descr> is not
available. Additionally, an expanded discussion of descriptor
issues is discussed in Section 6.2 (Short Names).
The ABNF for a quoted string (qdstring) was updated to reflect The ABNF for a quoted string (qdstring) was updated to reflect
support for the escaping mechanism described in 4.3 of RFC 2252. support for the escaping mechanism described in 4.3 of RFC 2252.
A.2.2 Section 5 of RFC 2252 A.2.2 Section 5 of RFC 2252
Definitions of operational attributes provided in Section 5 of RFC Definitions of operational attributes provided in Section 5 of RFC
2252 where incorporated into this document. 2252 where incorporated into this document.
The 'namingContexts' description was clarified. A first-level DSA
should publish, in addition to other values, "" indicating the root
of the DIT.
The 'supportedExtension' description was clarified. A server need The 'supportedExtension' description was clarified. A server need
only list the OBJECT IDENTIFIERs associated with the extended only list the OBJECT IDENTIFIERs associated with the extended
requests of the extended operations it recognizes. requests of the extended operations it recognizes.
The 'supportedControl' description was clarified. A server need The 'supportedControl' description was clarified. A server need
only list the OBJECT IDENTIFIERs associated with the request only list the OBJECT IDENTIFIERs associated with the request
controls it recognizes. controls it recognizes.
A.2.3 Section 7 of RFC 2252 A.2.3 Section 7 of RFC 2252
skipping to change at page 47, line 30 skipping to change at page 48, line 28
'aliasedObjectName' attribute type. This was integrated into 'aliasedObjectName' attribute type. This was integrated into
Section 2.6.2 of this document. 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 2.4.1 of this document. class. This was integrated into Section 2.4.1 of this document.
Section 7.2 of RFC 2256 provided the definition of the 'alias' Section 7.2 of RFC 2256 provided the definition of the 'alias'
object class. This was integrated into Section 2.6.1 of this object class. This was integrated into Section 2.6.1 of this
document. document.
Copyright 2002, The Internet Society. All Rights Reserved. Copyright 2003, 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
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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