mirror/openldap
2
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-01-24 13:24:56 +08:00
Code Issues Packages Projects Releases Wiki Activity
b6835be962
openldap/doc/drafts/draft-ietf-ldapbis-models-xx.txt

2748 lines
99 KiB
Plaintext
Raw Normal View History

Update drafts
2003-06-01 06:47:07 +08:00
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 1 March 2003
Obsoletes: RFC 2251, RFC 2252, RFC 2256
LDAP: Directory Information Models
<draft-ietf-ldapbis-models-07.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved. Please
see the Copyright section near the end of this document for more
information.
Abstract
The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in
accordance with X.500 data and service models. This document
describes the X.500 Directory Information Models, as used in LDAP.
Zeilenga LDAP Models [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Table of Contents
Status of this Memo 1
Abstract
Table of Contents 2
1. Introduction 3
1.1. Relationship to Other LDAP Specifications
1.2. Relationship to ITU Specifications
1.3. Conventions 4
1.4. Common ABNF Productions
2. Model of Directory User Information 6
2.1. The Directory Information Tree
2.2. Naming of Entries 7
2.3. Structure of an Entry 8
2.4. Object Classes
2.5. Attribute Descriptions 11
2.6. Alias Entries 15
3. Directory Administrative and Operational Information 16
3.1. Subtrees
3.2. Subentries 17
3.3. The 'objectClass' attribute
3.4. Operational attributes 18
4. Directory Schema 20
4.1. Schema Definitions 21
4.2. Subschema Subentries 30
4.3. 'extensibleObject' 34
4.4. Subschema Discovery
5. DSA (Server) Informational Model
5.1. Server-specific Data Requirements 35
6. Other Considerations 38
6.1. Preservation of User Information
6.2. Short Names
6.3. Cache and Shadowing 39
7. Implementation Guidelines 40
7.1. Server Guidelines
7.2. Client Guidelines
8. Security Considerations 41
9. IANA Considerations
10. Acknowledgments 42
11. Author's Address
12. References
12.1. Normative References
12.2. Informative References 43
Appendix A. Changes
A.1 Changes to RFC 2251 44
A.2 Changes to RFC 2252 46
A.3 Changes to RFC 2256 47
Copyright
Zeilenga LDAP Models [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
1. Introduction
This document discusses the X.500 Directory Information Models
[X.501], as used by the Lightweight Directory Access Protocol (LDAP)
[Roadmap].
The Directory is "a collection of open systems cooperating to provide
directory services" [X.500]. The information held in the Directory is
collectively known as the Directory Information Base (DIB). A
Directory user, which may be a human or other entity, accesses the
Directory through a client (or Directory User Agent (DUA)). The
client, on behalf of the directory user, interacts with one or more
servers (or Directory System Agents (DSA)). A server holds a fragment
of the DIB.
The DIB contains two classes of information:
1) user information (e.g., information provided and administrated
by users). Section 2 describes the Model of User Information.
2) administrative and operational information (e.g., information
used to administer and/or operate the directory). Section 3
describes the model of Directory Administrative and Operational
Information.
These two models, referred to as the generic Directory Information
Models, describe how information is represented in the Directory.
These generic models provide a framework for other information models.
Section 4 discusses the subschema information model and subschema
discovery. Section 5 discusses the DSA (Server) Informational Model.
Other X.500 information models, such as access control, collective
attribute, distribution knowledge, and replication knowledge
information models, may be adapted for use in LDAP. Specification of
how these models apply to LDAP is left to future documents.
1.1. Relationship to Other LDAP Specifications
This document is a integral part of the LDAP technical specification
[Roadmap] which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety.
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
sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
[AuthMeth], and [Roadmap] documents.
Zeilenga LDAP Models [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
summaries changes to these sections. The remainder of RFC 2252 is
obsoleted by [Syntaxes] and [Schema].
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
RFC 2256 is obsoleted by [Schema] and [Syntaxes].
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
Schema definitions are provided using LDAP description formats (as
defined in Section 4.1). Definitions provided here are formatted
(line wrapped) for readability. Matching rules and LDAP syntaxes
referenced in these definitions are specified in [Syntaxes].
1.4. Common ABNF Productions
A number of syntaxes in this document are described using Augmented
Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
number of syntaxes defined in other documents) rely on the following
common productions:
keystring = leadkeychar *keychar
leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT )
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
SP = 1*SPACE ; one or more " "
Zeilenga LDAP Models [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
WSP = 0*SPACE ; zero or more " "
NULL = %x00 ; null (0)
SPACE = %x20 ; space (" ")
DQUOTE = %x22 ; quote (""")
SHARP = %x23 ; octothorpe (or sharp sign) ("#")
DOLLAR = %x24 ; dollar sign ("$")
SQUOTE = %x27 ; single quote ("'")
LPAREN = %x28 ; left paren ("(")
RPAREN = %x29 ; right paren (")")
PLUS = %x2B ; plus sign ("+")
COMMA = %x2C ; comma (",")
HYPHEN = %x2D ; hyphen ("-")
DOT = %x2E ; period (".")
SEMI = %x3B ; semicolon (";")
LANGLE = %x3C ; left angle bracket ("<")
EQUALS = %x3D ; equals sign ("=")
RANGLE = %x3E ; right angle bracket (">")
X = %x58 ; uppercase x ("X")
ESC = %x5C ; backslash ("\")
USCORE = %x5F ; underscore ("_")
LCURLY = %x7B ; left curly brace "{"
RCURLY = %x7D ; right curly brace "}"
; Any UTF-8 character
UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6
UTF0 = %x80-BF
UTF1 = %x00-7F
UTF2 = %xC0-DF 1(UTF0)
UTF3 = %xE0-EF 2(UTF0)
UTF4 = %xF0-F7 3(UTF0)
UTF5 = %xF8-FB 4(UTF0)
UTF6 = %xFC-FD 5(UTF0)
; Any octet
OCTET = %x00-FF
Object identifiers are represented in LDAP using a dot-decimal format
conforming to the ABNF:
numericoid = number *( DOT number )
Short names, also known as descriptors, are used as more readable
aliases for object identifiers. Short names are case insensitive and
conform to the ABNF:
descr = keystring
Zeilenga LDAP Models [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Where either an object identifier or a short name may be specified,
the following production is used:
oid = descr / numericoid
While the <descr> form is generally preferred when the usage is
restricted to short names referring to object identifiers which
identify like kinds of objects (e.g., attribute type descriptions,
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
As [X.501] states:
The purpose of the Directory is to hold, and provide access to,
information about objects of interest (objects) in some 'world'.
An object can be anything which is identifiable (can be named).
An object class is an identified family of objects, or conceivable
objects, which share certain characteristics. Every object belongs
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
subclass, are also considered to be members of the latter classes,
the superclasses. There may be subclasses of subclasses, etc., to
an arbitrary depth.
A directory entry, a named collection of information, is the basic
unit of information held in the Directory. There are multiple kinds
of directory entries.
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
in a tree structure known as the Directory Information Tree (DIT).
Zeilenga LDAP Models [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Section 2.1 describes the Directory Information Tree
Section 2.2 discusses naming of entries.
Section 2.3 discusses the structure of entries.
Section 2.4 discusses object classes.
Section 2.5 discusses attribute descriptions.
Section 2.6 discusses alias entries.
2.1. The Directory Information Tree
As noted above, the DIB is composed of a set of entries organized
hierarchically in a tree structure known as the Directory Information
Tree (DIT). Specifically, a tree where vertices are the entries.
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
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
are all of its immediate subordinates and their subordinates.
Similarly, the superior/subordinate relationship between object
entries can be used to derive a relation between the objects they
represent. DIT structure rules can be used to govern relationships
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. Entries which have the same parent are known as
siblings.
2.2. Naming of Entries
2.2.1. Relative Distinguished Names
Each entry is named relative to its immediate superior. This relative
name, known as its Relative Distinguished Name (RDN) [X.501], is
composed of an unordered set of one or more attribute value assertions
(AVA) consisting of an attribute description with zero options and an
attribute value. These AVAs are chosen from the attributes of the
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]:
Zeilenga LDAP Models [Page 7]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
The last is an example of a multi-valued RDN. That is, an RDN
composed of multiple AVAs.
2.2.2. Distinguished Names
An entry's fully qualified name, known as its Distinguished Name (DN)
[X.501], is the concatenation of its RDN and its immediate superior's
DN. A Distinguished Name unambiguously refers to an entry in the
tree. The following are example string representations of DNs
[LDAPDN]:
UID=nobody@example.com,DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
2.2.3. Alias Names
An alias, or alias name, is "an name for an object, provided by the
use of alias entries" [X.501]. Alias entries are described in Section
2.6.
2.3. Structure of an Entry
An entry consists of a set of attributes which hold information about
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 zero or more
options) with one or more associated values. An attribute is often
referred to by its attribute description. For example, the
'givenName' attribute is the attribute which consists of the attribute
description 'givenName' (the 'givenName' attribute type [Schema] and
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.
Zeilenga LDAP Models [Page 8]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Two values are considered equivalent if they would match according to
the equality matching rule of the attribute type. If the attribute
type is defined with no equality matching rule, two values are
equivalent if and only if they are identical.
For example, the 'givenName' attribute can have can have more than one
value, they must be Directory Strings, and they are case insensitive.
The 'givenName' attribute cannot hold both "John" and "JOHN" as these
are equivalent values per the equality matching rule of the attribute
type.
2.4. Object Classes
An object class is "an identified family of objects (or conceivable
objects) which share certain characteristics" [X.501].
As defined in [X.501]:
Object classes are used in the Directory for a number of purposes:
- describing and categorising objects and the entries that
correspond to these objects;
- where appropriate, controlling the operation of the Directory;
- regulating, in conjunction with DIT structure rule
specifications, the position of entries in the DIT;
- regulating, in conjunction with DIT content rule
specifications, the attributes that are contained in entries;
- identifying classes of entry that are to be associated with a
particular policy by the appropriate administrative authority.
An object class (a subclass) may be derived from an object class
(its direct superclass) which is itself derived from an even more
generic object class. For structural object classes, this process
stops at the most generic object class, 'top' (defined in Section
2.4.1). An ordered set of superclasses up to the most superior
object class of an object class is its superclass chain.
An object class may be derived from two or more direct
superclasses (superclasses not part of the same superclass chain).
This feature of subclassing is termed multiple inheritance.
Each object class identifies the set of attributes required to be
present in entries belonging to the class and the set of attributes
Zeilenga LDAP Models [Page 9]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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
can be said that an object class inherits the sets of allowed and
required attributes from its superclasses. A subclass can identify an
attribute allowed by its superclass as being required. If an
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
classes: Abstract, Structural, or Auxiliary.
Each object class is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
2.4.1. Abstract Object Classes
An abstract object class, as the name implies, provides a base of
characteristics from which other object classes can be defined to
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
object classes.
All structural object classes derive (directly or indirectly) from the
'top' abstract object class. Auxiliary object classes do not
necessarily derive from 'top'.
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
All entries belong to the 'top' abstract object class.
2.4.2. Structural Object Classes
As stated in [X.501]:
An object class defined for use in the structural specification of
the DIT is termed a structural object class. Structural object
classes are used in the definition of the structure of the names
of the objects for compliant entries.
An object or alias entry is characterised by precisely one
structural object class superclass chain which has a single
structural object class as the most subordinate object class.
This structural object class is referred to as the structural
object class of the entry.
Zeilenga LDAP Models [Page 10]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Structural object classes are related to associated entries:
- an entry conforming to a structural object class shall
represent the real-world object constrained by the object
class;
- DIT structure rules only refer to structural object classes;
the structural object class of an entry is used to specify the
position of the entry in the DIT;
- the structural object class of an entry is used, along with an
associated DIT content rule, to control the content of an
entry.
The structural object class of an entry shall not be changed.
Each structural object class is a (direct or indirect) subclass of the
'top' abstract object class.
Structural object classes cannot subclass auxiliary object classes.
Each entry is said to belong to its structural object class as well as
all classes in its structural object class's superclass chain, which
always includes 'top'.
2.4.3. Auxiliary Object Classes
Auxiliary object classes are used augment the characteristics of
entries. They are commonly used to augment the sets of attributes
required and allowed attributes to be present in an entry. They can
be used to describe entries or classes of entries.
Auxiliary object classes cannot subclass structural object classes.
An entry can belong to any subset of the set of auxiliary object
classes allowed by the DIT content rule associated with structural
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
An attribute description is composed of an attribute type (see Section
Zeilenga LDAP Models [Page 11]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
2.5.1) and a set of zero or more attribute options (see Section
2.5.2).
An attribute description is represented by the ABNF:
attributedescription = attributetype options
attributetype = oid
options = *( SEMI option )
option = 1*keychar
where <attributetype> identifies the attribute type and each <option>
identifies an attribute option. Both <attributetype> and <option>
productions are case insensitive. The order in which <option>s appear
is irrelevant. That is, any two <attributedescription>s which consist
of the same <attributetype> and same set of <option>s are equivalent.
Examples of valid attribute descriptions:
2.5.4.0
cn;lang-de;lang-en
owner
An attribute description which consisting of an unrecognized attribute
type is to be treated as unrecognized. Servers SHALL treat an
attribute description with an unrecognized attribute option as
unrecognized. Clients MAY treat an unrecognized attribute option as a
tagging option (see Section 2.5.2.1).
All attributes of an entry must have distinct attribute descriptions.
2.5.1. Attribute Types
An 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.
The attribute type indicates whether the attribute is a user attribute
or an operational attribute. If operational, the attribute type
indicates the operational usage and whether the attribute can
modifiable by users or not. Operational attributes discussed in
Section 3.4.
An attribute type (a subtype) may derive from another attribute type
(a direct supertype). The subtype inherits the matching rules and
Zeilenga LDAP Models [Page 12]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
syntax of its supertype. An attribute type cannot be a subtype of an
attribute of different usage.
An attribute description consisting of a subtype and no options is
said to the direct description subtype of the attribute description
consisting of the subtype's direct supertype and no options.
Each attribute type is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
2.5.2. Attribute Options
There are multiple kinds of attribute description options. The LDAP
technical specification details one kind: tagging options.
Not all options can be associated with attributes held in the
directory. Tagging options can be.
Not all options can be use in conjunction with all attribute types.
In such cases, the attribute description is to be treated as
unrecognized.
An attribute description that contains mutually exclusive options
shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
"x-foo" and "x-bar" are mutually exclusive, is to be treated as
unrecognized.
Other kinds of options may be specified in future documents. These
documents must detail how new kinds of options they define relate to
tagging options. In particular, these documents must detail whether
or not new kinds of options can be associated with attributes held in
the directory, how new kinds of options affect transfer of attribute
values, and how new kinds of options are treated in attribute
description hierarchies.
Options are represented as short case insensitive textual strings
conforming to the <option> production defined in Section 2.5 of this
document.
Procedures for registering options are detailed in BCP 64 [RFC3383].
2.5.2.1. Tagging Options
Attributes held in the directory can have attribute descriptions with
any number of tagging options. Tagging options are never mutually
exclusive.
Zeilenga LDAP Models [Page 13]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
An attribute description with N tagging options is considered a direct
(description) subtype of all attribute descriptions of the same
attribute type and all but one of the N options. If the attribute
type has a supertype, then the attribute description is also
considered a direct (description) subtype of the attribute description
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-en', and 'name;lang-de;lang-en' ('cn' is a subtype of 'name',
both are defined in [Schema]).
2.5.3. Attribute Description Hierarchies
An attribute description can be the direct subtype of zero or more
other attribute descriptions as indicated by attribute type subtyping
(as described in Section 2.5.1) or attribute tagging option subtyping
(as described in Section 2.5.2.1). These subtyping relationships are
used to form hierarchies of attribute descriptions and attributes.
As adapted from [X.501]:
Attribute hierarchies allow access to the DIB with varying degrees
of granularity. This is achieved by allowing the value components
of attributes to be accessed by using either their specific
attribute description (a direct reference to the attribute) or by
a more generic attribute description (an indirect reference).
Semantically related attributes may be placed in a hierarchical
relationship, the more specialized being placed subordinate to the
more generalized. Searching for, or retrieving attributes and
their values is made easier by quoting the more generalized
attribute description; a filter item so specified is evaluated for
the more specialized descriptions as well as for the quoted
description.
Where subordinate specialized descriptions are selected to be
returned as part of a search result these descriptions shall be
returned if available. Where the more general descriptions are
selected to be returned as part of a search result both the
general and the specialized descriptions shall be returned, if
available. An attribute value shall always be returned as a value
of its own attribute description.
All of the attribute descriptions in an attribute hierarchy are
treated as distinct and unrelated descriptions for user
modification of entry content.
An attribute value stored in a object or alias entry is of
Zeilenga LDAP Models [Page 14]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
precisely one attribute description. The description is indicated
when the value is originally added to the entry.
For the purpose of subschema administration of the entry, a required
attribute specification is fulfilled if the entry contains a value of
an attribute description belonging to an attribute hierarchy if the
attribute type of that description is the same as the required
attribute's type. That is, a "MUST name" specification is fulfilled
by 'name' or 'name;x-tag-option', but is not fulfilled by 'CN' nor by
'CN;x-tag-option'. Likewise, an entry may contain a value of an
attribute description belonging to an attribute hierarchy if the
attribute type of that description is either explicitly included in
the definition of an object class to which the entry belongs or
allowed by the DIT content rule applicable to that entry. That is,
'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
(nor by "MUST name").
For the purposes of other policy administration, unless stated
otherwise in the specification of the particular administrative model,
all of the attribute descriptions in an attribute hierarchy are
treated as distinct and unrelated descriptions.
2.5.4. Attribute Values
Attribute values conform to the defined syntax of the attribute.
When an attribute is used for naming of the entry, one and only one
value of the attribute is selected to appear in the Relative
Distinguished Name. This value is known as a distinguished value.
Only attributes whose descriptions have no options can be used for
naming.
2.6. Alias Entries
As adapted from [X.501]:
An alias, or an alias name, for an object is a an alternative name
for an object or object entry which is provided by the use of
alias entries.
Each alias entry contains, within the 'aliasedObjectName'
attribute (known as the 'aliasedEntryName' attribute in X.500]), a
name of some object. The distinguished name of the alias entry is
thus also a name for this object.
Zeilenga LDAP Models [Page 15]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
NOTE - The name within the 'aliasedObjectName' is said to be
pointed to by the alias. It does not have to be the
distinguished name of any entry.
The conversion of an alias name to an object name is termed
(alias) dereferencing and comprises the systematic replacement of
alias names, where found within a purported name, by the value of
the corresponding 'aliasedObjectName' attribute. The process may
require the examination of more than one alias entry.
Any particular entry in the DIT may have zero or more alias names.
It therefore follows that several alias entries may point to the
same entry. An alias entry may point to an entry that is not a
leaf entry and may point to another alias entry.
An alias entry shall have no subordinates, so that an alias entry
is always a leaf entry.
Every alias entry shall belong to the 'alias' object class.
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
Alias entries belong to the 'alias' object class.
( 2.5.6.1 NAME 'alias'
SUP top STRUCTURAL
MUST aliasedObjectName )
2.6.2. 'aliasedObjectName' attribute type
The 'aliasedObjectName' attribute holds the name of the entry an alias
points to. The 'aliasedObjectName' attribute is known as the
'aliasedEntryName' attribute in X.500.
Zeilenga LDAP Models [Page 16]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
( 2.5.4.1 NAME 'aliasedObjectName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax is defined in [Syntaxes].
3. Directory Administrative and Operational Information
This section discusses select aspects of the X.500 Directory
Administrative and Operational Information model [X.501]. LDAP
implementations MAY support other aspects of this model.
3.1. Subtrees
As defined in [X.501]:
A subtree is a collection of object and alias entries situated at
the vertices of a tree. Subtrees do not contain subentries. The
prefix sub, in subtree, emphasizes that the base (or root) vertex
of this tree is usually subordinate to the root of the DIT.
A subtree begins at some vertex and extends to some identifiable
lower boundary, possibly extending to leaves. A subtree is always
defined within a context which implicitly bounds the subtree. For
example, the vertex and lower boundaries of a subtree defining a
replicated area are bounded by a naming context. Similarly, the
scope of a subtree defining a specific administrative area is
limited to the context of an enclosing autonomous administrative
area.
3.2. Subentries
A subentry is a "special sort of entry, known by the Directory, used
to hold information associated with a subtree or subtree refinement"
[X.501]. Subentries are used in Directory to hold for administrative
and operational purposes as defined in [X.501]. Their use in LDAP is
not detailed in this technical specification, but may be detailed in
future documents.
The term "(sub)entry" in this specification indicates that servers
implementing X.500(93) models are, in accordance with X.500(93), to
use a subentry and that other servers are to use an object entry
belonging to the appropriate auxiliary class normally used with the
Zeilenga LDAP Models [Page 17]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
subentry (e.g., 'subschema' for subschema subentries) to mimic the
subentry. This object entry's RDN SHALL be formed from a value of the
'cn' (commonName) attribute [Schema].
3.3. The 'objectClass' attribute
Each entry in the DIT has an 'objectClass' attribute.
( 2.5.4.0 NAME 'objectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
(1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
The 'objectClass' attribute specifies the object classes of an entry,
which (among other things) is used in conjunction with user and system
schema to determine the permitted attributes of an entry. Values of
this attribute can be modified by clients, but the 'objectClass'
attribute cannot be removed.
Servers which follow X.500(93) models SHALL restrict modifications of
this attribute to prevent the basic structural class of the entry from
being changed. That is, one cannot change a 'person' into a
'country'.
When creating an entry or adding an 'objectClass' value to an entry,
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
a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
'x-b' to added (if is not already present).
Servers SHALL restrict modifications of this attribute to prevent a
superclasses of remaining 'objectClass' values from being deleted.
That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
an attempt to delete only 'x-b' from the 'objectClass' attribute is an
error.
3.4. Operational attributes
Some attributes, termed operational attributes, are used or maintained
by servers for administrative and operational purposes. As stated in
[X.501]: "There are three varieties of operational attributes:
Directory operational attributes, DSA-shared operational attributes,
and DSA-specific operational attributes."
Zeilenga LDAP Models [Page 18]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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.
'createTimeStamp') as well as operational attributes which hold values
administrated by the user (e.g. 'ditContentRules').
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
returned in search results unless explicitly requested by name.
Not all operational attributes are user modifiable.
Entries may contain, among others, the following operational
attributes.
- creatorsName: the Distinguished Name of the user who added this
entry to the directory.
- createTimestamp: the time this entry was added to the directory.
- modifiersName: the Distinguished Name of the user who last
modified this entry.
- modifyTimestamp: the time this entry was last modified.
Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
'modifiersName', and 'modifyTimestamp' for all entries of the DIT.
3.4.1. 'creatorsName'
This attribute appears in entries which were added using the protocol
(e.g., using the Add operation). The value is the distinguished name
of the creator.
( 2.5.18.3 NAME 'creatorsName'
EQUALITY distinguishedNameMatch
Zeilenga LDAP Models [Page 19]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
3.4.2. 'createTimestamp'
This attribute appears in entries which were added using the protocol
(e.g., using the Add operation). The value is the time the entry was
added.
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
are defined in [Syntaxes].
3.4.3. 'modifiersName'
This attribute appears in entries which have been modified using the
protocol (e.g., using Modify operation). The value is the
distinguished name of the last modifier.
( 2.5.18.4 NAME 'modifiersName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
3.4.4. 'modifyTimestamp'
This attribute appears in entries which have been modified using the
protocol (e.g., using the Modify operation). The value is the time
the entry was last modified.
Zeilenga LDAP Models [Page 20]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
( 2.5.18.2 NAME 'modifyTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
are defined in [Syntaxes].
4. Directory Schema
As defined in [X.501]:
The Directory Schema is a set of definitions and constraints
concerning the structure of the DIT, the possible ways entries are
named, the information that can be held in an entry, the
attributes used to represent that information and their
organization into hierarchies to facilitate search and retrieval
of the information and the ways in which values of attributes may
be matched in attribute value and matching rule assertions.
NOTE 1 - The schema enables the Directory system to, for example:
- prevent the creation of subordinate entries of the wrong
object-class (e.g. a country as a subordinate of a person);
- prevent the addition of attribute-types to an entry
inappropriate to the object-class (e.g. a serial number to a
person's entry);
- prevent the addition of an attribute value of a syntax not
matching that defined for the attribute-type (e.g. a printable
string to a bit string).
Formally, the Directory Schema comprises a set of:
a) Name Form definitions that define primitive naming relations
for structural object classes;
b) DIT Structure Rule definitions that define the names that
entries may have and the ways in which the entries may be
related to one another in the DIT;
c) DIT Content Rule definitions that extend the specification of
allowable attributes for entries beyond those indicated by the
Zeilenga LDAP Models [Page 21]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
structural object classes of the entries;
d) Object Class definitions that define the basic set of mandatory
and optional attributes that shall be present, and may be
present, respectively, in an entry of a given class, and which
indicate the kind of object class that is being defined;
e) Attribute Type definitions that identify the object identifier
by which an attribute is known, its syntax, associated matching
rules, whether it is an operational attribute and if so its
type, whether it is a collective attribute, whether it is
permitted to have multiple values and whether or not it is
derived from another attribute type;
f) Matching Rule definitions that define matching rules.
And in LDAP:
g) LDAP Syntaxes definitions that define encodings used in LDAP.
4.1. Schema Definitions
Schema definitions in this section are described using ABNF and rely
on the common productions specified in Section 1.2 as well as these:
noidlen = numericoid [ LCURLY len RCURLY ]
len = number
oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid )
extensions = *( SP xstring SP qdstrings )
xstring = X HYPHEN 1*( ALPHA / HYPHEN / USCORE )
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ]
Zeilenga LDAP Models [Page 22]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF8 string
QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
; Any UTF-8 encoded UCS character
; except %x27 ("'") and %x5C ("\")
QUTF8 = QUTF1 / UTFMB
; Any ASCII character except %x27 ("'") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F
Schema definitions in this section also share a number of common
terms.
The NAME field provides a set of short names (descriptors) which are
be used as aliases for the OID.
The DESC field optionally allows a descriptive string to be provided
by the directory administrator and/or implementor. While
specifications may suggest a descriptive string, there is no
requirement that the suggested (or any) descriptive string be used.
The OBSOLETE field, if present, indicates the element is not active.
Implementors should note that future versions of this document may
expand these definitions to include additional terms. Terms whose
identifier begins with "X-" are reserved for private experiments, and
are followed by <SP> and <qdstrings> tokens.
4.1.1. Object Class Definitions
Object Class definitions are written according to the ABNF:
ObjectClassDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oids ] ; superior object classes
[ SP kind ] ; kind of class
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN
Zeilenga LDAP Models [Page 23]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
where:
<numericoid> is object identifier assigned to this object class;
NAME <qdescrs> are short names (descriptors) identifying this object
class;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this object class is not active;
SUP <oids> specifies the direct superclasses of this object class;
the kind of object class is indicated by one of ABSTRACT,
STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
MUST and MAY specify the sets of required and allowed attribute
types, respectively; and
<extensions> describe extensions.
4.1.2. Attribute Types
Attribute Type definitions are written according to the ABNF:
AttributeTypeDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oid ] ; subtype
[ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule
[ SP "SYNTAX" SP noidlen ] ; value syntax
[ SP "SINGLE-VALUE" ] ; single-value
[ SP "COLLECTIVE" ] ; collective
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable
[ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions
usage = "userApplications" / ; user
"directoryOperation" / ; directory operational
"distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operational
where:
<numericoid> is object identifier assigned to this attribute type;
NAME <qdescrs> are short names (descriptors) identifying this
attribute type;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this attribute type is not active;
SUP oid specifies the direct supertype of this type;
Zeilenga LDAP Models [Page 24]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
EQUALITY, ORDERING, SUBSTRING provide the oid of the equality,
ordering, and substrings matching rules, respectively;
SYNTAX identifies value syntax by object identifier and may suggest
a minimum upper bound;
COLLECTIVE indicates this attribute type is collective [X.501];
NO-USER-MODIFICATION indicates this attribute type is not user
modifiable;
USAGE indicates the application of this attribute type; and
<extensions> describe extensions.
Each attribute type description must contain at least one of the SUP
or SYNTAX fields.
Usage of userApplications, the default, indicates that attributes of
this type represent user information. That is, they are user
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
rules which can be used with that attribute type in an extensibleMatch
search filter. This is done using the 'matchingRuleUse' attribute
described in Section 4.1.4.
This document refines the schema description of X.501 by requiring
that the SYNTAX field in an <AttributeTypeDescription> be a string
representation of an object identifier for the LDAP string syntax
definition with an optional indication of the suggested minimum bound
of a value of this attribute.
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
other syntaxes, may be indicated by appending this bound count inside
of curly braces following the syntax's OBJECT IDENTIFIER in an
Zeilenga LDAP Models [Page 25]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Attribute Type Description. This bound is not part of the syntax name
itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
implementations should allow a string to be 64 characters long,
although they may allow longer strings. Note that a single character
of the Directory String syntax may be encoded in more than one octet
since UTF-8 is a variable-length encoding.
4.1.3. Matching Rules
Matching rules are used by servers to compare attribute values against
assertion values when performing Search and Compare operations. They
are also used to identify the value to be added or deleted when
modifying entries, and are used when comparing a purported
distinguished name with the name of an entry.
A matching rule specifies the syntax of the assertion value.
Each matching rule is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
Matching rule definitions are written according to the ABNF:
MatchingRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "SYNTAX" SP numericoid ; assertion syntax
extensions WSP RPAREN ; extensions
where:
<numericoid> is object identifier assigned to this matching rule;
NAME <qdescrs> are short names (descriptors) identifying this
matching rule;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this matching rule is not active;
SYNTAX identifies the assertion syntax by object identifier; and
<extensions> describe extensions.
4.1.4. Matching Rule Uses
A matching rule use lists the attributes which are suitable for use
with an extensibleMatch search filter.
Matching rule use descriptions are written according to the following
ABNF:
Zeilenga LDAP Models [Page 26]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "APPLIES" SP oids ; attribute types
extensions WSP RPAREN ; extensions
where:
<numericoid> is the object identifier of the matching rule
associated with this matching rule use description;
NAME <qdescrs> are short names (descriptors) identifying this
matching rule use;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this matching rule use is not active;
APPLIES provides a list of attribute types the matching rule applies
to; and
<extensions> describe extensions.
4.1.5. LDAP Syntaxes
LDAP Syntaxes of (attribute and assertion) values are described in
terms of ASN.1 [X.680] and, optionally, have an octet string encoding
known as the LDAP-specific encoding. Commonly, the LDAP-specific
encoding is constrained to string of Universal Character Set (UCS)
[ISO10646] characters in UTF-8 [RFC2279] form.
Each LDAP syntax is identified by an object identifier (OID).
LDAP syntax definitions are written according to the ABNF:
SyntaxDescription = LPAREN WSP
numericoid ; object identifier
[ SP "DESC" SP qdstring ] ; description
extensions WSP RPAREN ; extensions
where:
<numericoid> is object identifier assigned to this LDAP syntax;
DESC <qdstring> is a short descriptive string; and
<extensions> describe extensions.
4.1.6. DIT Content Rules
A DIT content rule is a "rule governing the content of entries of a
particular structural object class" [X.501].
Zeilenga LDAP Models [Page 27]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
For DIT entries of a particular structural object class, a DIT content
rule specifies which auxiliary object classes the entries are allowed
to belong to and which additional attributes (by type) are required,
allowed or not allowed to appear in the entries.
The list of precluded attributes cannot include any attribute listed
as mandatory in rule, the structural object class, or any of the
allowed auxiliary object classes.
Each content rule is identified by the object identifier, as well as
any short names (descriptors), of the structural object class it
applies to.
An entry may only belong to auxiliary object classes listed in the
governing content rule.
An entry must contain all attributes required by the object classes
the entry belongs to as well as all attributed required by the
governing content rule.
An entry may contain any non-precluded attributes allowed by the
object classes the entry belongs to as well as all attributes allowed
by the governing content rule.
An entry cannot include any attribute precluded by the governing
content rule.
An entry is governed by (if present and active in the subschema) the
DIT content rule which applies to the structural object class of the
entry (see Section 2.4.2). If no active rule is present for the
entry's structural object class, the entry's content is governed by
the structural object class (and possibly other aspects of user and
system schema).
DIT content rule descriptions are written according to the ABNF:
DITContentRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "AUX" SP oids ] ; auxiliary object classes
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
[ SP "NOT" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions
where:
Zeilenga LDAP Models [Page 28]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
<numericoid> is the object identifier of the structural object class
associated with this DIT content rule;
NAME <qdescrs> are short names (descriptors) identifying this DIT
content rule;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this DIT content rule use is not active;
AUX specifies a list of auxiliary object classes which entries
subject to this DIT content rule may belong to;
MUST, MAY, and NOT specify lists of attribute types which are
required, allowed, or precluded, respectively, from appearing in
entries subject to this DIT content rule; and
<extensions> describe extensions.
4.1.7. DIT Structure Rules and Name Forms
It is sometimes desirable to regulate where object entries can be
placed in the DIT and how they can be named based upon their
structural object class.
4.1.7.1. DIT Structure Rules
A DIT structure rule is a "rule governing the structure of the DIT by
specifying a permitted superior to subordinate entry relationship. A
structure rule relates a name form, and therefore a structural object
class, to superior structure rules. This permits entries of the
structural object class identified by the name form to exist in the
DIT as subordinates to entries governed by the indicated superior
structure rules" [X.501].
DIT structure rule descriptions are written according to the ABNF:
DITStructureRuleDescription = LPAREN WSP
ruleid ; rule identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "FORM" SP oid ; NameForm
[ SP "SUP" ruleids ] ; superior rules
extensions WSP RPAREN ; extensions
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = number
Zeilenga LDAP Models [Page 29]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
where:
<ruleid> is the rule identifier of this DIT structure rule;
NAME <qdescrs> are short names (descriptors) identifying this DIT
structure rule;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this DIT structure rule use is not active;
FORM is specifies the name form associated with this DIT structure
rule;
SUP identifies superior rules (by rule id); and
<extensions> describe extensions.
If no superior rules are identified, the DIT structure rule applies
to an autonomous administrative point (e.g. the root vertex of the
subtree controlled by the subschema) [X.501].
4.1.7.2. Name Forms
A name form "specifies a permissible RDN for entries of a particular
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 RDN). Name forms are primitive pieces of specification
used in the definition of DIT structure rules" [X.501].
Each name form indicates the structural object class to be named,
a set of required attribute types, and a set of allowed attributes
types. A particular attribute type cannot be listed in both sets.
Entries governed by the form must be named using a value from each
required attribute type and zero or more values from the allowed
attribute types.
Each name form is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
Name form descriptions are written according to the ABNF:
NameFormDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "OC" SP oid ; structural object class
SP "MUST" SP oids ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions
where:
Zeilenga LDAP Models [Page 30]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
<numericoid> is object identifier which identifies this name form;
NAME <qdescrs> are short names (descriptors) identifying this name
form;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this name form is not active;
OC identifies the structural object class this rule applies to,
MUST and MAY specify the sets of required and allowed, respectively,
naming attributes for this name form; and
<extensions> describe extensions.
All attribute types in the required ("MUST") and allowed ("MAY") lists
shall be different.
4.2. Subschema Subentries
Subschema (sub)entries are used for administering information about
the directory schema. A single subschema (sub)entry contains all
schema definitions (see Section 4.1) used by entries in a particular
part of the directory tree.
Servers which follow X.500(93) models SHOULD implement subschema using
the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
and so these are not ordinary object entries but subentries (see
Section 3.2). LDAP clients SHOULD NOT assume that servers implement
any of the other aspects of X.500 subschema.
Servers MAY allow subschema modification. Procedures for subschema
modification are discussed in Section 14.5 of [X.501].
A server which masters entries and permits clients to modify these
entries SHALL implement and provide access to these subschema
(sub)entries including providing a 'subschemaSubentry' attribute in
each modifiable entry. This so clients may discover the attributes
and object classes which are permitted to be present. It is strongly
RECOMMENDED that all other servers implement this as well.
The value of the 'subschemaSubentry' attribute is the name of the
subschema (sub)entry holding the subschema controlling the entry.
( 2.5.18.10 NAME 'subschemaSubentry'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
NO-USER-MODIFICATION SINGLE-VALUE
USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
Zeilenga LDAP Models [Page 31]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Subschema is held in (sub)entries belonging to the subschema auxiliary
object class.
( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )
The 'ldapSyntaxes' operational attribute may also be present in
subschema entries.
Servers MAY provide additional attributes (described in other
documents) in subschema (sub)entries.
Servers SHOULD provide the attributes 'createTimestamp' and
'modifyTimestamp' in subschema (sub)entries, in order to allow clients
to maintain their caches of schema information.
The following subsections provide attribute type definitions for each
of schema definition attribute types.
4.2.1. 'objectClasses'
This attribute holds definitions of object classes.
( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the
ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
defined in [Syntaxes].
4.2.2. 'attributeTypes'
This attribute holds definitions of attribute types.
( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the
AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
defined in [Syntaxes].
Zeilenga LDAP Models [Page 32]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
4.2.3. 'matchingRules'
This attribute holds definitions of matching rules.
( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the
MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
defined in [Syntaxes].
4.2.4 'matchingRuleUse'
This attribute holds definitions of matching rule uses.
( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the
MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
defined in [Syntaxes].
4.2.5. 'ldapSyntaxes'
This attribute holds definitions of LDAP syntaxes.
( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the
SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
in [Syntaxes].
4.2.6. 'dITContentRules'
This attribute lists DIT Content Rules which are in force.
( 2.5.21.2 NAME 'dITContentRules'
EQUALITY objectIdentifierFirstComponentMatch
Zeilenga LDAP Models [Page 33]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the
DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
defined in [Syntaxes].
4.2.7. 'dITStructureRules'
This attribute lists DIT Structure Rules which are in force.
( 2.5.21.1 NAME 'dITStructureRules'
EQUALITY integerFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
USAGE directoryOperation )
The 'integerFirstComponentMatch' matching rule and the
DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
defined in [Syntaxes].
4.2.8 'nameForms'
This attribute lists Name Forms which are in force.
( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation )
The 'objectIdentifierFirstComponentMatch' matching rule and the
NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
in [Syntaxes].
4.3. 'extensibleObject' object class
The 'extensibleObject auxiliary object class allows entries belong to
it to hold any attribute type. The set of allowed attributes of this
class is implicitly the set of all user attributes.
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )
The mandatory attributes of the other object classes of this entry are
still required to be present and any precluded attributes are still
not allowed to be present.
Zeilenga LDAP Models [Page 34]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Note that not all servers will implement this object class, and those
which do not will reject requests to add entries which contain this
object class, or modify an entry to add this object class.
4.4. Subschema Discovery
To discover the DN of the subschema (sub)entry holding the subschema
controlling a particular entry, a client reads that entry's
'subschemaSubentry' operational attribute. To read schema attributes
from the subschema (sub)entry, clients MUST issue a base object search
where the filter is "(objectClass=subschema)" [Filters] and the list
of attributes includes the names of the desired schema attributes (as
they are operational). This filter allows LDAP servers which gateway
to X.500 to detect that subentry information is being requested.
Clients SHOULD NOT assume 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
The LDAP protocol assumes there are one or more servers which jointly
provide access to a Directory Information Tree (DIT).
As defined in [X.501]:
context prefix: The sequence of RDNs leading from the Root of the
DIT to the initial vertex of a naming context; corresponds to
the distinguished name of that vertex.
DIB fragment: The portion of the DIB that is held by one master
DSA, comprising one or more naming contexts.
naming context: A subtree of entries held in a single master DSA.
That is, a naming context is the largest collection of entries,
starting at an entry that is mastered by a particular server, and
including all its subordinates and their subordinates, down to the
entries which are mastered by different servers. The context prefix
is the name of the initial entry.
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
values in the root DSE.
Zeilenga LDAP Models [Page 35]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
5.1. Server-specific Data Requirements
An LDAP server SHALL provide information about itself and other
information that is specific to each server. This is represented as a
group of attributes located in the root DSE (DSA-Specific Entry),
which is named with the zero-length LDAPDN. These attributes are
retrievable, subject to access control and other restrictions, if a
client performs a base object search of the root with the filter
"(objectClass=*)" [Filters] requesting the desired attributes. It is
noted that root DSE attributes are operational, and like other
operational attributes, are not returned in search requests unless
requested by name.
The root DSE SHALL NOT be included if the client performs a subtree
search starting from the root.
Servers may allow clients to modify attributes of the root DSE where
appropriate.
The following attributes of the root DSE are defined in [Syntaxes].
Additional attributes may be defined in other documents.
- altServer: alternative servers;
- namingContexts: naming contexts;
- supportedControl: recognized LDAP controls;
- supportedExtension: recognized LDAP extended operations;
- supportedLDAPVersion: LDAP versions supported; and
- supportedSASLMechanisms: recognized SASL mechnanisms.
The values of these attributes provided may depend on session specific
and other factors. For example, a server supporting the SASL EXTERNAL
mechanism might only list "EXTERNAL" when the client's identity has
been established by a lower level. See [AuthMeth].
The root DSE may also include a 'subschemaSubentry' attribute. If so,
it refers to the subschema (sub)entry holding schema controlling
attributes of the root DSE. Client SHOULD NOT assume that the
subschema (sub)entry controlling the root DSE controls any entry held
by the server. General subschema discovery procedures are provided in
Section 4.4.
5.1.1. 'altServer'
Zeilenga LDAP Models [Page 36]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
The 'altServer' attribute lists URLs referring to alternative servers
which may be contacted when this server becomes unavailable. If the
server does not know of any other servers which could be used this
attribute will be absent. Clients may cache this information in case
their preferred server later becomes unavailable.
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE dSAOperation )
The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
[Syntaxes].
5.1.2. 'namingContexts'
The 'namingContexts' attribute lists the context prefixes of the
naming contexts the server masters or shadows (in part or in whole).
If the server is a first-level DSA [X.501], it should list (in
addition) an empty string (indicating the root of the DIT). If the
server does not master or shadow any information (e.g. it is an LDAP
gateway to a public X.500 directory) this attribute will be absent.
If the server believes it masters or shadows the entire directory, the
attribute will have a single value, and that value will be the empty
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'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE dSAOperation )
The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
defined in [Syntaxes].
5.1.3. 'supportedControl'
The 'supportedControl' attribute lists object identifiers identifying
the request controls the server supports. If the server does not
support any request controls, this attribute will be absent.
Object identifiers identifying response controls need not be listed.
Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in BCP 64 [RFC3383].
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
Zeilenga LDAP Models [Page 37]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
defined in [Syntaxes].
5.1.4. 'supportedExtension'
The 'supportedExtension' attribute lists object identifiers
identifying the extended operations which the server supports. If the
server does not support any extended operations, this attribute will
be absent.
An extended operation comprises a ExtendedRequest, possibly other PDUs
defined by extension, and an ExtendedResponse [Protocol]. The object
identifier assigned to the ExtendedRequest is used to identify the
extended operation. Other object identifiers associated with the
extended operation need not be listed.
Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in BCP 64 [RFC3383].
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
defined in [Syntaxes].
5.1.5. 'supportedLDAPVersion'
The 'supportedLDAPVersion' attribute lists the versions of LDAP which
the server supports.
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
USAGE dSAOperation )
The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
[Syntaxes].
5.1.6. 'supportedSASLMechanisms'
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
[RFC2222] which the server recognizes. The contents of this attribute
Zeilenga LDAP Models [Page 38]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
may depend on the current session state. If the server does not
support any SASL mechanisms this attribute will not be present.
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE dSAOperation )
The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
in [Syntaxes].
6. Other Considerations
6.1. Preservation of User Information
Syntaxes may be defined which have specific value and/or value form
(representation) preservation requirements. For example, a syntax
containing digitally signed data can mandate the server preserve both
the value and form of value presented to ensure signature is not
invalidated.
Where such requirements have not be explicitly stated, servers SHOULD
preserve the value of user information but MAY return the value in a
different form. And where a server is unable (or unwilling) to
preserve the value of user information, the server SHALL ensure that
an equivalent value (per Section 2.3) is returned.
6.2. Short Names
Short names, also known as descriptors, are used as more readable
aliases for object identifiers and are used to identify various schema
elements. However, it is not expected that LDAP implementations with
human user interface would display these short names (nor the object
identifiers they refer to) to the user, but would most likely be
performing translations (such as expressing the short name in one of
the local national languages). For example, the short name "st"
(stateOrProvinceName) might be displayed to a German-speaking user as
"Land".
The same short name might have different meaning in different
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
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
Zeilenga LDAP Models [Page 39]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
attribute type 'x-fubar' in a subschema.
Implementations MUST be prepared that the same short name might be
used in the different subschemas to refer to the different schema
elements. That is, there might be two matching rules 'x-fubar', each
in different subschemas.
Procedures for registering short names (descriptors) are detailed in
BCP 64 [RFC3383bis].
[[The remainder of this subsection will be included a subsequent
revision of RFC 3383.]]
To avoid interoperability problems, the following additional
considerations are stated:
Descriptors used to identify various schema elements SHOULD be
registered unless in private-use name space (e.g., they begin with
"x-"). Descriptors defined in RFCs MUST be registered.
While the protocol allows the same descriptor to refer to
different object identifiers in certain cases and the registry
supports multiple registrations of the same descriptor (each
indicating a different kind of schema element and different object
identifier), multiple registrations of the same descriptor are to
be avoided. All such registration requests require Expert Review.
6.3. Cache and Shadowing
Some servers may hold cache or shadow copies of entries, which can be
used to answer search and comparison queries, but will return
referrals or contact other servers if modification operations are
requested. Servers that perform shadowing or caching MUST ensure that
they do not violate any access control constraints placed on the data
by the originating server.
7. Implementation Guidelines
7.1 Server Guidelines
Servers MUST recognize all attribute types and object classes names
defined in this document but, unless stated otherwise, need not
support the associated functionality. Servers SHOULD recognize all
the names of attribute types and object classes defined in Section 3
and 4, respectively, of [Schema].
Zeilenga LDAP Models [Page 40]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Servers MUST ensure that entries conform to user and system schema
rules or other data model constraints.
Servers MAY support the 'extensibleObject' object class.
Servers MAY support DIT Content Rules. Servers MAY support DIT
Structure Rules and Name Forms.
Servers MAY support alias entries.
Servers MAY support subentries. If so, they MUST do so in accordance
with [X.501]. Servers which do not support subentries SHOULD use
object entries to mimic subentries as detailed in Section 3.2.
Servers MAY implement additional schema elements. Servers SHOULD
provide definitions of all schema elements they support in subschema
(sub)entries.
7.2 Client Guidelines
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
the subschema of the source entry, and retrieve the values of
'attributeTypes' from the subschema (sub)entry.
Clients MUST NOT assume the LDAP-specific string encoding is
restricted to a UTF-8 encoded string of UCS characters or any
particular subset of particular subset of UCS (such as a printable
subset) unless such restriction is explicitly stated.
Clients MUST NOT send attribute values in a request that are not valid
according to the syntax defined for the attributes.
8. Security Considerations
Attributes of directory entries are used to provide descriptive
information about the real-world objects they represent, which can be
people, organizations or devices. Most countries have privacy laws
regarding the publication of information about people.
General security considerations for accessing directory information
with LDAP are discussed in [Protocol] and [AuthMeth].
9. IANA Considerations
Zeilenga LDAP Models [Page 41]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
It is requested that the Internet Assigned Numbers Authority (IANA)
update the LDAP descriptors registry as indicated the following
template:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see comment
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
The following descriptors (short names) should be updated to refer
to RFC XXXX.
NAME Type OID
------------------------ ---- -----------------
alias O 2.5.6.1
aliasedEntryName A 2.5.4.1
aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6
attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3
dITContentRules A 2.5.21.2
dITStructureRules A 2.5.21.1
extensibleObject O 1.3.6.1.4.1.1466.101.120.111
ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
matchingRuleUse A 2.5.21.8
matchingRules A 2.5.21.4
modifiersName A 2.5.18.4
modifyTimestamp A 2.5.18.2
nameForms A 2.5.21.7
namingContexts A 1.3.6.1.4.1.1466.101.120.5
objectClass A 2.5.4.0
objectClasses A 2.5.21.6
subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0
10. Acknowledgments
Zeilenga LDAP Models [Page 42]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
Indexing of Directories (ASID) Working Group. This document is also
based in part on "The Directory: Models" [X.501], a product of the
International Telephone Union (ITU). Additional text was borrowed
from RFC 2253 by Mark Wahl, Tim Howes, and Steve Kille.
This document is a product of the IETF LDAPBIS Working Group.
11. Author's Address
Kurt Zeilenga
E-mail: <kurt@openldap.org>
12. References
12.1. Normative References
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
in progress.
Zeilenga LDAP Models [Page 43]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
[Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation
of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a
work in progress.
[LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Schema] K. Dally (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in progress.
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
: 1993.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
[X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", 1994.
12.2. Informative References
None.
Appendix A. Changes
This appendix is non-normative.
This document amounts to nearly a complete rewrite of portions of RFC
2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
overall clarity of technical specification. This appendix provides a
summary of substantive changes made to the portions of these documents
incorporated into this document. Readers should consult [Roadmap],
[Protocol], [Syntaxes], and [Schema] for summaries of remaining
portions of these documents.
A.1 Changes to RFC 2251
This document incorporates from RFC 2251 sections 3.2 and 3.4,
portions of Section 4 and 6 as summarized below.
Zeilenga LDAP Models [Page 44]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
A.1.1 Section 3.2 of RFC 2251
Section 3.2 of RFC 2251 provided a brief introduction to the X.500
data model, as used by LDAP. The previous specification relied on
[X.501] but lacked clarity in how X.500 models are adapted for use by
LDAP. This document describes the X.500 data models, as used by LDAP
in greater detail, especially in areas where the models require
adaptation is needed.
Section 3.2.1 of RFC 2251 described an attribute as "a type with one
or more associated values." In LDAP, an attribute is better described
as an attribute description, a type with zero or more options, and one
or more associated values.
Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
objectClasses and attributeTypes attributes, yet X.500(93) treats
these attributes as optional. While generally all implementations
that support X.500(93) subschema mechanisms will provide both of these
attributes, it is not absolutely required for interoperability that
all servers do. The mandate was removed for consistency with
X.500(93). The subschema discovery mechanism was also clarified to
indicate that subschema controlling an entry is obtained by reading
the (sub)entry referred to by that entry's 'subschemaSubentry'
attribute.
A.1.2 Section 3.4 of RFC 2251
Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
This material, with changes, was incorporated in Section 5.1 of this
document.
Changes:
- Clarify that attributes of the root DSE are subject to "other
restrictions" in addition to acccess controls.
- Clarify that only recognized extended requests need to be enumerated
'supportedExtension'.
- Clarify that only recognized request controls need to be enumerated
'supportedControl'.
- Clarify that root DSE attributes are operational and, like other
operational attributes, will not be returned in search requests
unless requested by name.
- Clarify that not all root DSE attributes are user modifiable.
Zeilenga LDAP Models [Page 45]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
- Remove inconsistent text regarding handling of the
'subschemaSubentry' attribute within the root DSE. The previous
specification stated that the 'subschemaSubentry' attribute held in
the root DSE referred to "subschema entries (or subentries) known by
this server." This is inconsistent with the attribute intended use
as well as its formal definition as a single valued attribute
[X.501]. It is also noted that a simple (possibly incomplete) list
of subschema (sub)entries is not terrible useful. This document (in
section 5.1) specifies that the 'subschemaSubentry' attribute of the
root DSE refers to the subschema controlling the root DSE. It is
noted that the general subschema discovery mechanism remains
available (see Section 4.4 of this document).
A.1.2 Section 4 of RFC 2251
Portions of Section 4 of RFC 2251 detailing aspects of the information
model used by LDAP were incorporated in this document, including:
- Restriction of distinguished values to attributes whose descriptions
have no options (from Section 4.1.3).
- Data model aspects of Attribute Types (from Section 4.1.4),
Attribute Descriptions (from 4.1.4), Attribute (from 4.1.8),
Matching Rule Identifier (from 4.1.9).
- User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
A.1.3 Section 6 of RFC 2251
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
where incorporated into this document.
A.2 Changes to RFC 2252
This document incorporates Sections 4, 5 and 7 from RFC 2252.
A.2.1 Section 4 of RFC 2252
The specification was updated to use Augmented BNF [RFC2234]. The
string representation of an OBJECT IDENTIFIER was tighten to
disallow leading zeros as described in RFC 2252 text.
The <descr> syntax was changed to disallow semicolon (U+003B)
characters to appear to be consistent its natural language
Zeilenga LDAP Models [Page 46]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
specification "descr is the syntactic representation of an object
descriptor, which consists of letters and digits, starting with a
letter." In a related change, the statement "an
AttributeDescription can be used as the value in a NAME part of an
AttributeTypeDescription" was deleted. RFC 2252 provided no
specification as to the semantics of attribute options appearing in
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
support for the escaping mechanism described in 4.3 of RFC 2252.
A.2.2 Section 5 of RFC 2252
Definitions of operational attributes provided in Section 5 of RFC
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
only list the OBJECT IDENTIFIERs associated with the extended
requests of the extended operations it recognizes.
The 'supportedControl' description was clarified. A server need
only list the OBJECT IDENTIFIERs associated with the request
controls it recognizes.
A.2.3 Section 7 of RFC 2252
Section 7 of RFC 2252 provides definitions of the 'subschema' and
'extensibleObject' object classes. These definitions where
integrated into Section 4.2 and Section 4.3 of this document,
respectively. Section 7 of RFC 2252 also contained the object class
implementation requirement. This was incorporated into Section 7 of
this document.
The specification of 'extensibleObject' was clarified of how it
Zeilenga LDAP Models [Page 47]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
interacts with precluded attributes.
A.3 Changes to RFC 2256
This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
2256.
Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
attribute type. This was integrated into Section 2.4.1 of this
document. The statement "One of the values is either 'top' or
'alias'" was replaced with statement that one of the values is 'top'
as entries belonging to 'alias' also belong to 'top'.
Section 5.2 of RFC 2256 provided the definition of the
'aliasedObjectName' attribute type. This was integrated into
Section 2.6.2 of this document.
Section 7.1 of RFC 2256 provided the definition of the 'top' object
class. This was integrated into Section 2.4.1 of this document.
Section 7.2 of RFC 2256 provided the definition of the 'alias'
object class. This was integrated into Section 2.6.1 of this
document.
Copyright 2003, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
Zeilenga LDAP Models [Page 48]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga LDAP Models [Page 49]
Reference in New Issue Copy Permalink