draft-ietf-ldapbis-models-04.txt   draft-ietf-ldapbis-models-05.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 3 December 2002 Expires in six months 10 December 2002
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-04.txt> <draft-ietf-ldapbis-models-05.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 2, line 17 skipping to change at page 2, line 17
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. Conventions 4
1.3. Common ABNF Productions 1.3. 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 2.3. Structure of an Entry 8
2.4. Object Classes 8 2.4. Object Classes
2.5. Attribute Descriptions 10 2.5. Attribute Descriptions 11
2.6. Alias Entries 14 2.6. Alias Entries 15
3. Directory Administrative and Operational Information 15 3. Directory Administrative and Operational Information 16
3.1. Subtrees 3.1. Subtrees
3.2. Subentries 3.2. Subentries
3.3. The 'objectClass' attribute 3.3. The 'objectClass' attribute 17
3.4. Operational attributes 17 3.4. Operational attributes 18
4. Directory Schema 19 4. Directory Schema 20
4.1. Schema Definitions 20 4.1. Schema Definitions 21
4.2. Subschema Subentries 28 4.2. Subschema Subentries 30
4.3. 'extensibleObject' 32 4.3. 'extensibleObject' 33
4.4. Subschema Discovery 4.4. Subschema Discovery 34
5. DSA (Server) Informational Model 33 5. DSA (Server) Informational Model
5.1. Server-specific Data Requirements 5.1. Server-specific Data Requirements
6. Other Considerations 36 6. Other Considerations 38
6.1. Preservation of User Information 6.1. Preservation of User Information
6.2. Short Names 37 6.2. Short Names
6.3. Cache and Shadowing 6.3. Cache and Shadowing 39
7. Implementation Guidelines 38 7. Implementation Guidelines
7.1. Server Guidelines 7.1. Server Guidelines
7.2. Client Guidelines 7.2. Client Guidelines 40
8. Security Considerations 39 8. Security Considerations
9. IANA Considerations 9. IANA Considerations
10. Acknowledgments 40 10. Acknowledgments 41
11. Author's Address 11. Author's Address
12. References 12. References
12.1. Normative References 12.1. Normative References
12.2. Informative References 41 12.2. Informative References 43
Appendix A. Changes Appendix A. Changes
A.1 Changes to RFC 2251 42 A.1 Changes to RFC 2251
A.2 Changes to RFC 2252 44 A.2 Changes to RFC 2252 45
A.3 Changes to RFC 2256 45 A.3 Changes to RFC 2256 46
Copyright Copyright
1. Introduction 1. Introduction
This document discusses the X.500 Directory Information Models This document discusses the X.500 Directory Information Models
[X.501], as used by the Lightweight Directory Access Protocol (LDAP) [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
[Roadmap]. [Roadmap].
The Directory is "a collection of open systems cooperating to provide The Directory is "a collection of open systems cooperating to provide
directory services" [X.500]. The information held in the Directory is directory services" [X.500]. The information held in the Directory is
skipping to change at page 5, line 40 skipping to change at page 5, line 40
UTF6 = %xFC-FD 5(UTF0) UTF6 = %xFC-FD 5(UTF0)
; Any octet ; Any octet
OCTET = %x00-FF OCTET = %x00-FF
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, known as descriptors, are used as more readable aliases Short names, also known as descriptors, are used as more readable
for object identifiers. Descriptors are case insensitive and conform aliases for object identifiers. Short names are case insensitive and
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 The <descr> form is preferred. When a production <oid> is encoded (in
a value, the <descr> encoding option SHOULD be used instead of the a protocol field, attribute value, assertion value, or elsewhere), the
<numericoid> encoding option. <descr> encoding option SHOULD be used instead of the <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. There are multiple kinds
a particular object. An alias entry provides alternative naming. A of directory entries.
subentry holds administrative and/or operational information.
An object entry represents a particular object. An alias entry
provides alternative naming. A subentry holds administrative and/or
operational information.
The set of entries representing the DIB are organized hierarchically The set of entries representing the DIB are organized hierarchically
in a tree structure known as the Directory Information Tree (DIT). in a tree structure known as the Directory Information Tree (DIT).
Section 2.1 describes the Directory Information Tree Section 2.1 describes the Directory Information Tree
Section 2.2 discusses 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 attribute descriptions. Section 2.5 discusses attribute descriptions.
Section 2.6 discusses alias entries. Section 2.6 discusses alias entries.
2.1. The Directory Information Tree 2.1. The Directory Information Tree
As noted above, the DIB is composed of a set of entries organized As noted above, the DIB is composed of a set of entries organized
hierarchically in a tree structure known as the Directory Information hierarchically in a tree structure known as the Directory Information
Tree (DIT). Specifically, a tree where vertices are the entries. Tree (DIT). Specifically, a tree where vertices are the entries.
The arcs between vertices define relations between entries. If an arc The arcs between vertices define relations between entries. If an 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 are the
entry's immediate superior and its superiors. An entry's subordinates entry's immediate superior and its superiors. An entry's subordinates
is 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 structural 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
parent and an entry's immediate subordinate is also known as the
entry's child.
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 an unordered set of one or more attribute value assertions
an attribute description with zero options and an attribute value. An (AVA) consisting of an attribute description with zero options and an
entry's relative distinguished name must be unique among all its attribute value. These AVAs are chosen from the attributes of the
siblings. entry.
An entry's relative distinguished name must be unique among all
immediate subordinates of the entry's immediate superior (i.e., all
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
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
skipping to change at page 7, line 48 skipping to change at page 8, line 13
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
2.2.3. Alias Names 2.2.3. Alias Names
An alias, or alias name, is "an name for an object, provided by the An alias, or alias name, is "an name for an object, provided by the
use of alias entries" [X.501]. Alias entries are described in Section use of alias entries" [X.501]. Alias entries are described in Section
2.6. 2.6.
2.3. Structure of an Entry 2.3. Structure of an Entry
An entry consist of a set of attributes which hold information about An entry consists of a set of attributes which hold information about
the object which entry represents. the object which entry represents. Some attributes represent user
information and are called user attributes. Other attributes
represent operational and/or administrative information and are called
operational attributes.
An attribute is an attribute description, a type and one or more An attribute is an attribute description (a type and zero or more
options, with one or more associated values. The attribute type options) with one or more associated values. An attribute is often
governs whether the attribute can have multiple values, the syntax and referred to by its attribute description. For example, the
matching rules used to construct and compare values of that attribute, 'givenName' attribute is the attribute which consists of the attribute
and other functions. Options indicate subtypes and other functions. description 'givenName' (the 'givenName' attribute type [Schema] and
No two values of an attribute may be equivalent. zero options) and one or more associated values.
The attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used to construct and compare
values of that attribute, and other functions. Options indicate
subtypes and other functions. No two values of an attribute may be
equivalent.
Two values are considered equivalent if they would match according to Two values are considered equivalent if they would match according to
the equality matching rule of the associated attribute type. If the the equality matching rule of the attribute type. If the attribute
attribute type is defined with no equality matching rule, two values type is defined with no equality matching rule, two values are
are equivalent if and only if they are identical. equivalent if and only if they are identical.
An example of an attribute is 'givenName'. As described in [Schema] For example, the 'givenName' attribute can have can have more than one
and [Syntaxes], there can be one or more values of this attribute, value, they must be Directory Strings, and they are case insensitive.
they must be Directory Strings, and they are case insensitive (e.g. The 'givenName' attribute cannot hold both "John" and "JOHN" as these
"John" will match "JOHN"). are equivalent values per the equality matching rule of the attribute
type.
2.4. Object Classes 2.4. Object Classes
An object class is "an identified family of objects (or conceivable An object class is "an identified family of objects (or conceivable
objects) which share certain characteristics" [X.501]. objects) which share certain characteristics" [X.501].
As defined in [X.501]: As defined in [X.501]:
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 9, line 22 skipping to change at page 9, line 42
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 a subclass as being required. If an attribute is
a member of both sets, it is required to be present. 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, and Auxiliary.
Each object 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 known as 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 only abstract object classes. inherit from. An entry cannot belong to an abstract object class
unless it belongs to a structural or auxiliary class which inherits
from that abstract class.
Abstract object classes can not derive from structural nor auxiliary Abstract object classes can not derive from structural nor auxiliary
object classes. object classes.
All structural object classes derive (directly or indirectly) from the All structural object classes derive (directly or indirectly) from the
'top' abstract object class. Auxiliary object classes do not 'top' abstract object class. Auxiliary object classes do not
necessarily derive from 'top'. necessarily derive from 'top'.
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
All entries belong to the 'top' abstract class. All entries belong to the 'top' abstract object class.
2.4.2. Structural Object Classes 2.4.2. Structural Object Classes
As stated in [X.501]: As stated in [X.501]:
An object class defined for use in the structural specification of An object class defined for use in the structural specification of
the DIT is termed a structural object class. Structural object the DIT is termed a structural object class. Structural object
classes are used in the definition of the structure of the names classes are used in the definition of the structure of the names
of the objects for compliant entries. of the objects for compliant entries.
skipping to change at page 11, line 44 skipping to change at page 12, line 17
tagging option (see Section 2.5.2.1). 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 The attribute type indicates whether the attribute is a user attribute
attribute type has one of three usages: directoryOperation, or an operational attribute. If operational, the attribute type
distributedOperation, or dSAOperation which mean the attribute type is indicates the operational usage and whether the attribute can
a directory, distributed, or DSA operational, respectively. modifiable by users or not. Operational attributes discussed in
Section 3.4.
An operational attribute type may be defined as not modifiable by
users.
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. An attribute type cannot be a subtype of an syntax of its supertype. An attribute type cannot be a subtype of an
attribute of different usage. attribute of different usage.
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 (descriptors).
2.5.2. Attribute Options 2.5.2. Attribute Options
There are multiple kinds of attribute description options. The LDAP There are multiple kinds of attribute description options. The LDAP
technical specification details one kind: tagging options. technical specification details one kind: tagging options.
Not all options can be associated with attributes held in the Not all options can be associated with attributes held in the
directory. Tagging options can be. directory. Tagging options can be.
Not all options can be use in conjunction with all attribute types. Not all options can be use in conjunction with all attribute types.
skipping to change at page 13, line 7 skipping to change at page 13, line 26
document. document.
Procedures for registering options are detailed in BCP 64 [RFC3383]. Procedures for registering options are detailed in BCP 64 [RFC3383].
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 considered 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
skipping to change at page 16, line 30 skipping to change at page 17, line 4
A subtree begins at some vertex and extends to some identifiable A subtree begins at some vertex and extends to some identifiable
lower boundary, possibly extending to leaves. A subtree is always lower boundary, possibly extending to leaves. A subtree is always
defined within a context which implicitly bounds the subtree. For defined within a context which implicitly bounds the subtree. For
example, the vertex and lower boundaries of a subtree defining a example, the vertex and lower boundaries of a subtree defining a
replicated area are bounded by a naming context. Similarly, the replicated area are bounded by a naming context. Similarly, the
scope of a subtree defining a specific administrative area is scope of a subtree defining a specific administrative area is
limited to the context of an enclosing autonomous administrative limited to the context of an enclosing autonomous administrative
area. area.
3.2. Subentries 3.2. Subentries
A subentry is a "special sort of entry, known by the Directory, used A subentry is a "special sort of entry, known by the Directory, used
to hold information associated with a subtree or subtree refinement" to hold information associated with a subtree or subtree refinement"
[X.501]. Subentries are used in Directory to hold for administrative [X.501]. Subentries are used in Directory to hold for administrative
and operational purposes as defined in [X.501]. Their use in LDAP is and operational purposes as defined in [X.501]. Their use in LDAP is
not detailed in this technical specification, but may be detailed in 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 that other implementing X.500(93) models are, in accordance with X.500(93), to
servers use an object entry belonging to the appropriate auxiliary use a subentry and that other servers are to use an object entry
class normally used with the subentry (e.g., 'subschema' for subschema belonging to the appropriate auxiliary class normally used with the
subentries) to mimic the subentry. This object entry's RDN SHALL be subentry (e.g., 'subschema' for subschema subentries) to mimic the
formed from a value of the 'cn' (commonName) attribute [Schema]. 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 The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
skipping to change at page 17, line 23 skipping to change at page 17, line 43
this attribute can be modified by clients, but the 'objectClass' this attribute can be modified by clients, but the 'objectClass'
attribute cannot be removed. attribute cannot be removed.
Servers which follow X.500(93) models SHALL restrict modifications of Servers which follow X.500(93) models SHALL restrict modifications of
this attribute to prevent the basic structural class of the entry from this attribute to prevent the basic structural class of the entry from
being changed. That is, one cannot change a 'person' into a being changed. That is, one cannot change a 'person' into a
'country'. 'country'.
When creating an entry or adding an 'objectClass' value to an entry, When creating an entry or adding an 'objectClass' value to an entry,
all superclasses of the named classes SHALL be implicitly added as all superclasses of the named classes SHALL be implicitly added as
well if not already present, and the client must supply values for any well if not already present. That is, if the auxiliary class 'x-a' is
mandatory attributes of new superclasses. That is, if the auxiliary a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
class 'x-a' is a subclass of the class 'x-b', adding 'x-a' to 'x-b' to added (if is not already present).
'objectClass' causes '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 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- That is, if the auxiliary class 'x-a' is a subclass of the class 'x-b'
b', attempting to deleting 'x-b' to 'objectClass' is an error. and the 'objectClass' attribute contains 'x-a', an attempt to delete
'x-b' from the 'objectClass' attribute is an error.
3.4. Operational attributes 3.4. Operational attributes
Some attributes, termed operational attributes (as defined in Section Some attributes, termed operational attributes, are used or maintained
12.4.1 of [X.501]), are used or maintained by servers for by servers for administrative and operational purposes. As stated in
administrative and operational purposes. Not all operational [X.501]: "There are three varieties of operational attributes:
attributes are user modifiable. Directory operational attributes, DSA-shared operational attributes,
and DSA-specific operational attributes."
A directory operational attribute is used to represent operational
and/or administrative information in the Directory Information Model.
This includes operational attributes maintained by the server (e.g.
'subschemaSubentry') as well as operational attributes which hold
values administrated by the user (e.g. 'matchingRuleUse').
A DSA-shared operational attribute is used to represent information of
the DSA Information Model. Its values, if shared between DSAs
(servers) are identical (except during periods of transient
inconsistency).
A DSA-specific operational attribute is used to represent information
of the DSA Information Model. Its values, if shared between DSAs
(servers), need not be identical.
The DSA Information Model operational attributes are detailed in
[X.501].
Operational attributes are not normally visible. They are not Operational attributes are not normally visible. They are not
returned in search results unless explicitly requested by name. returned in search results unless explicitly requested by name.
Not all operational attributes are user modifiable.
Entries may contain, among others, the following operational Entries may contain, among others, the following operational
attributes. attributes.
- creatorsName: the Distinguished Name of the user who added this - creatorsName: the Distinguished Name of the user who added this
entry to the directory. entry to the directory.
- createTimestamp: the time this entry was added to the directory. - createTimestamp: the time this entry was added to the directory.
- modifiersName: the Distinguished Name of the user who last - modifiersName: the Distinguished Name of the user who last
modified this entry. modified this entry.
skipping to change at page 23, line 4 skipping to change at page 23, line 45
[ SP "SUP" SP oid ] ; subtype [ SP "SUP" SP oid ] ; subtype
[ SP "EQUALITY" SP oid ] ; equality matching rule [ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule [ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule [ SP "SUBSTR" SP oid ] ; substrings matching rule
[ SP "SYNTAX" SP noidlen ] ; value syntax [ SP "SYNTAX" SP noidlen ] ; value syntax
[ SP "SINGLE-VALUE" ] ; single-value [ SP "SINGLE-VALUE" ] ; single-value
[ SP "COLLECTIVE" ] ; collective [ SP "COLLECTIVE" ] ; collective
[ 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" /
"directoryOperation" /
"distributedOperation" / ; DSA-shared
"dSAOperation" ; DSA-specific
usage = "userApplications" /
"directoryOperation" / ; directory operational
"distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operational
where: where:
<numericoid> is object identifier assigned to this attribute type; <numericoid> is object identifier assigned to this attribute type;
NAME <qdescrs> are short names (descriptors) identifying this NAME <qdescrs> are short names (descriptors) identifying this
attribute type; attribute type;
DESC <qdstring> is a short descriptive string; DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this attribute type is not active; OBSOLETE indicates this attribute type is not active;
SUP oid specifies the direct subtype of this type; SUP oid specifies the direct supertype of this type;
EQUALITY, ORDERING, SUBSTRING provide the oid of the equality, EQUALITY, ORDERING, SUBSTRING provide the oid of the equality,
ordering, and substrings matching rules, respectively; ordering, and substrings matching rules, respectively;
SYNTAX identifies value syntax by object identifier and suggests a SYNTAX identifies value syntax by object identifier and may suggest
minimum upper bound; a minimum upper bound;
COLLECTIVE indicates this attribute type is collective; COLLECTIVE indicates this attribute type is collective [X.501];
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 Usage of userApplications, the default, indicates that attributes of
userApplications. NO-USER-MODIFICATION requires usage other than this type represent user information. That is, they are user
userApplications. attributes.
COLLECTIVE requires usage userApplications. Use of collective
attribute types in LDAP is not discussed in this technical
specification.
A usage of directoryOperation, distributedOperation, or dSAOperation
indicates that attributes of this type represent operational and/or
administrative information. That is, they are operational attributes.
directoryOperation usage indicates that the attribute of this type is
a directory operational attribute. distributedOperation usage
indicates that the attribute of this DSA-shared usage operational
attribute. dSAOperation usage indicates that the attribute of this
type is a DSA-specific operational attribute.
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 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 minimum bound definition with an optional indication of the suggested minimum bound
skipping to change at page 24, line 18 skipping to change at page 25, line 29
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.
A matching rule specifies the syntax of the assertion value. A matching rule specifies the syntax of the assertion value.
Each matching rule is identified by an object identifier (OID) and, Each matching rule is identified by an object identifier (OID) and,
optionally, one or more short names known as descriptors. optionally, one or more short names (descriptors).
Matching rule definitions are written according to the ABNF: Matching rule definitions are written according to the ABNF:
MatchingRuleDescription = LPAREN WSP MatchingRuleDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ 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
skipping to change at page 25, line 45 skipping to change at page 27, line 10
where: where:
<numericoid> is object identifier assigned to this LDAP syntax; <numericoid> is object identifier assigned to this LDAP syntax;
DESC <qdstring> is a short descriptive string; and DESC <qdstring> is a short descriptive string; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.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 For DIT entries of a particular structural object class, a DIT content
structural object class, which auxiliary object classes the entries rule specifies which auxiliary object classes the entries are allowed
are allowed to belong to and which additional attributes (by type) are to belong to and which additional attributes (by type) are required,
required, allowed or not allowed to appear in the entries. allowed or not allowed to appear in the entries.
The list of precluded attributes cannot include any attribute listed The list of precluded attributes cannot include any attribute listed
as mandatory in rule, the structural object class, or any of the as mandatory in rule, the structural object class, or any of the
allowed auxiliary object classes. allowed auxiliary object classes.
Each content rule is identified by the object identifier, as well as Each content rule is identified by the object identifier, as well as
any short names (descriptors), of the structural rule it applies to. any short names (descriptors), of the structural object class it
applies to.
An entry may only belong to auxiliary object classes listed in the An entry may only belong to auxiliary object classes listed in the
governing content rule. governing content rule.
An entry must contain all attributes required by the object classes An entry must contain all attributes required by the object classes
the entry belongs to as well as all attributed required by the the entry belongs to as well as all attributed required by the
governing content rule. governing content rule.
An entry may contain any non-precluded attributes allowed by the An entry may contain any non-precluded attributes allowed by the
object classes the entry belongs to as well as all attributes allowed object classes the entry belongs to as well as all attributes allowed
skipping to change at page 27, line 11 skipping to change at page 28, line 22
content rule; content rule;
DESC <qdstring> is a short descriptive string; DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this DIT content rule use is not active; OBSOLETE indicates this DIT content rule use is not active;
AUX specifies a list of auxiliary object classes which entries AUX specifies a list of auxiliary object classes 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 Structure 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 structure rule is a "rule governing the structure of the DIT by
specifying a permitted superior to subordinate entry relationship. A specifying a permitted superior to subordinate entry relationship. A
structure rule relates a name form, and therefore a structural object structure rule relates a name form, and therefore a structural object
class, to superior structure rules. This permits entries of the class, to superior structure rules. This permits entries of the
structural object class identified by the name form to exist in the structural object class identified by the name form to exist in the
DIT as subordinates to entries governed by the indicated superior DIT as subordinates to entries governed by the indicated superior
structure rules" [X.501]. structure rules" [X.501].
A name form "specifies a permissible RDN for entries of a particular A name form "specifies a permissible RDN for entries of a particular
structural object class. A name form identifies a named object class structural object class. A name form identifies a named object class
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
skipping to change at page 27, line 40 skipping to change at page 29, line 4
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
attribute types. attribute types.
Each name form is identified by an object identifier (OID) and, Each name form is identified by an object identifier (OID) and,
optionally, one or more short names known as descriptors. optionally, one or more short names (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 (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 "FORM" SP oid ; NameForm SP "FORM" SP oid ; NameForm
[ SP "SUP" ruleids ] ; superior rules [ SP "SUP" ruleids ] ; superior rules
skipping to change at page 34, line 25 skipping to change at page 35, line 34
- supportedControl: recognized LDAP controls; - supportedControl: recognized LDAP controls;
- supportedExtension: recognized LDAP extended operations; - supportedExtension: recognized LDAP extended operations;
- supportedLDAPVersion: LDAP versions supported; and - supportedLDAPVersion: LDAP versions supported; and
- supportedSASLMechanisms: recognized SASL mechnanisms. - supportedSASLMechanisms: recognized SASL mechnanisms.
The values of these attributes provided may depend on session specific The values of these attributes provided may depend on session specific
and other factors. For example, a server supporting the SASL EXTERNAL and other factors. For example, a server supporting the SASL EXTERNAL
mechanism may only list "EXTERNAL" when the client's identity has been mechanism might only list "EXTERNAL" when the client's identity has
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'
skipping to change at page 37, line 17 skipping to change at page 38, line 25
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. And where a server is unable (or unwilling) to different form. And where a server is unable (or unwilling) to
preserve the value of user information, the server SHALL ensure that preserve the value of user information, the server SHALL ensure that
an equivalent value (per Section 2.3) is returned. an equivalent value (per Section 2.3) is returned.
6.2. Short Names 6.2. Short Names
Short names, also known as descriptors, are used as more readable Short names, also known as descriptors, are used as more readable
aliases for object identifiers and are used to identify various schema aliases for object identifiers and are used to identify various schema
elements. The same short name might have different meaning in elements.
different subschemas and, within a particular subschema, the same
short name might refer to different object identifiers each The same short name might have different meaning in different
identifying a different kind of schema element. subschemas and, within a particular subschema, the same short name
might refer to different object identifiers each identifying a
different kind of schema element.
Implementations MUST be prepared that the same short name might be Implementations MUST be prepared that the same short name might be
used in a subschema to refer to the different kinds of schema used in a subschema to refer to the different kinds of schema
elements. That is, there might be an object class 'x-fubar' and an elements. That is, there might be an object class 'x-fubar' and an
attribute type 'x-fubar' in a subschema. attribute type 'x-fubar' in a subschema.
Implementations MUST be prepared that the same short name might be Implementations MUST be prepared that the same short name might be
used in the different subschemas to refer to the different schema used in the different subschemas to refer to the different schema
elements. That is, there might be two matching rules 'x-fubar', each elements. That is, there might be two matching rules 'x-fubar', each
in different subschemas. in different subschemas.
skipping to change at page 38, line 21 skipping to change at page 39, line 30
they do not violate any access control constraints placed on the data they do not violate any access control constraints placed on the data
by the originating server. by the originating server.
7. Implementation Guidelines 7. Implementation Guidelines
7.1 Server Guidelines 7.1 Server Guidelines
Servers MUST recognize all attribute types and object classes 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. Servers SHOULD recognize all the names of associated functionality. Servers SHOULD recognize all the names of
object classes defined in Section 7 of [Schema]. attribute types and object classes defined in Section 3 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 DIT Content Rules, DIT Structural Rules, and/or Servers MAY support DIT Content Rules, DIT Structure Rules, and/or
Name Forms features. Name Forms features.
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 support the 'extensibleObject' object class. Servers MAY support the 'extensibleObject' object class.
Servers MAY implement additional object classes. Servers SHOULD Servers MAY implement additional schema elements. Servers SHOULD
provide the definitions of all object classes they support in provide the definitions of all schema elements 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 the subschema (sub)entry. 'attributeTypes' from the subschema (sub)entry.
Clients MUST NOT assume the LDAP-specific string encoding is Clients MUST NOT assume the LDAP-specific string encoding is
skipping to change at page 39, line 35 skipping to change at page 40, line 46
Subject: Request for LDAP Descriptor Registration Update Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment Descriptor (short name): see comment
Object Identifier: see comment Object Identifier: see comment
Person & email address to contact for further information: Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org> Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see comment Usage: see comment
Specification: RFC XXXX Specification: RFC XXXX
Author/Change Controller: IESG Author/Change Controller: IESG
Comments: Comments:
The following descriptors should be updated to refer to RFC XXXX. The following descriptors (short names) should be updated to refer
to RFC XXXX.
NAME Type OID NAME Type OID
------------------------ ---- ----------------- ------------------------ ---- -----------------
alias O 2.5.6.1 alias O 2.5.6.1
aliasedEntryName A 2.5.4.1 aliasedEntryName A 2.5.4.1
aliasedObjectName A 2.5.4.1 aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6 altServer A 1.3.6.1.4.1.1466.101.120.6
attributeTypes A 2.5.21.5 attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1 createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3 creatorsName A 2.5.18.3
 End of changes. 

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