draft-ietf-ldapbis-models-10.txt   draft-ietf-ldapbis-models-11.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 15 February 2004 Expires in six months 4 June 2004
Obsoletes: RFC 2251, RFC 2252, RFC 2256 Obsoletes: RFC 2251, RFC 2252, RFC 2256
LDAP: Directory Information Models LDAP: Directory Information Models
<draft-ietf-ldapbis-models-10.txt> <draft-ietf-ldapbis-models-11.txt>
Status of this Memo 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. This document is intended to be published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.org>. Please send editorial mailing list <ietf-ldapbis@openldap.org>. Please send editorial
comments directly to the editor <Kurt@OpenLDAP.org>. comments directly to the editor <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference material
material or to cite them other than as ``work in progress.'' or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of http://www.ietf.org/ietf/1id-abstracts.txt. The list of
Internet-Draft Shadow Directories can be accessed at Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>. http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Please see the Full Copyright section near the end of this document Please see the Full Copyright section near the end of this document
for more information. for more information.
Abstract Abstract
The Lightweight Directory Access Protocol (LDAP) is an Internet The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in protocol for accessing distributed directory services which act in
accordance with X.500 data and service models. This document accordance with X.500 data and service models. This document
describes the X.500 Directory Information Models, as used in LDAP. describes the X.500 Directory Information Models, as used in LDAP.
Table of Contents Table of Contents
Status of this Memo 1 Status of this Memo 1
Abstract Abstract 2
Table of Contents 2 Table of Contents
1. Introduction 3 1. Introduction 3
1.1. Relationship to Other LDAP Specifications 1.1. Relationship to Other LDAP Specifications
1.2. Relationship to X.501 4 1.2. Relationship to X.501 4
1.3. Conventions 1.3. Conventions
1.4. Common ABNF Productions 1.4. Common ABNF Productions
2. Model of Directory User Information 6 2. Model of Directory User Information 6
2.1. The Directory Information Tree 7 2.1. The Directory Information Tree 7
2.2. Naming of Entries 2.2. Structure of an Entry
2.3. Structure of an Entry 8 2.3. Naming of Entries 8
2.4. Object Classes 9 2.4. Object Classes 9
2.5. Attribute Descriptions 11 2.5. Attribute Descriptions 12
2.6. Alias Entries 15 2.6. Alias Entries 15
3. Directory Administrative and Operational Information 17 3. Directory Administrative and Operational Information 17
3.1. Subtrees 3.1. Subtrees
3.2. Subentries 3.2. Subentries
3.3. The 'objectClass' attribute 3.3. The 'objectClass' attribute 18
3.4. Operational attributes 18 3.4. Operational attributes 19
4. Directory Schema 21 4. Directory Schema 20
4.1. Schema Definitions 22 4.1. Schema Definitions 23
4.2. Subschema Subentries 31 4.2. Subschema Subentries 30
4.3. 'extensibleObject' 35 4.3. 'extensibleObject' 35
4.4. Subschema Discovery 4.4. Subschema Discovery
5. DSA (Server) Informational Model 5. DSA (Server) Informational Model 36
5.1. Server-specific Data Requirements 36 5.1. Server-specific Data Requirements
6. Other Considerations 39 6. Other Considerations 39
6.1. Preservation of User Information 6.1. Preservation of User Information 40
6.2. Short Names 40 6.2. Short Names
6.3. Cache and Shadowing 6.3. Cache and Shadowing 41
7. Implementation Guidelines 7. Implementation Guidelines
7.1. Server Guidelines 7.1. Server Guidelines
7.2. Client Guidelines 41 7.2. Client Guidelines
8. Security Considerations 8. Security Considerations 42
9. IANA Considerations 42 9. IANA Considerations
10. Acknowledgments 43 10. Acknowledgments 43
11. Editor's Address 11. Editor's Address
12. References 12. References 44
12.1. Normative References 12.1. Normative References
12.2. Informative References 45 12.2. Informative References 45
Appendix A. Changes Appendix A. Changes
Intellectual Property Rights 49 Intellectual Property Rights 50
Full Copyright Full 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 4, line 42 skipping to change at page 4, line 48
A number of syntaxes in this document are described using Augmented A number of syntaxes in this document are described using Augmented
Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
number of syntaxes defined in other documents) rely on the following number of syntaxes defined in other documents) rely on the following
common productions: common productions:
keystring = leadkeychar *keychar keystring = leadkeychar *keychar
leadkeychar = ALPHA leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT ) number = DIGIT / ( LDIGIT 1*DIGIT )
ALPHA = UALPHA / %x61-7A ; "A"-"Z" / "a"-"z" ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
UALPHA = %x41-5A ; "A"-"Z"
DIGIT = %x30 / LDIGIT ; "0"-"9" DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9" LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f" HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
SP = 1*SPACE ; one or more " " SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " " WSP = 0*SPACE ; zero or more " "
NULL = %x00 ; null (0) NULL = %x00 ; null (0)
SPACE = %x20 ; space (" ") SPACE = %x20 ; space (" ")
DQUOTE = %x22 ; quote (""") DQUOTE = %x22 ; quote (""")
SHARP = %x23 ; octothorpe (or sharp sign) ("#") SHARP = %x23 ; octothorpe (or sharp sign) ("#")
DOLLAR = %x24 ; dollar sign ("$") DOLLAR = %x24 ; dollar sign ("$")
SQUOTE = %x27 ; single quote ("'") SQUOTE = %x27 ; single quote ("'")
LPAREN = %x28 ; left paren ("(") LPAREN = %x28 ; left paren ("(")
RPAREN = %x29 ; right paren (")") RPAREN = %x29 ; right paren (")")
PLUS = %x2B ; plus sign ("+") PLUS = %x2B ; plus sign ("+")
COMMA = %x2C ; comma (",") COMMA = %x2C ; comma (",")
skipping to change at page 5, line 25 skipping to change at page 5, line 32
DOT = %x2E ; period (".") DOT = %x2E ; period (".")
SEMI = %x3B ; semicolon (";") SEMI = %x3B ; semicolon (";")
LANGLE = %x3C ; left angle bracket ("<") LANGLE = %x3C ; left angle bracket ("<")
EQUALS = %x3D ; equals sign ("=") EQUALS = %x3D ; equals sign ("=")
RANGLE = %x3E ; right angle bracket (">") RANGLE = %x3E ; right angle bracket (">")
ESC = %x5C ; backslash ("\") ESC = %x5C ; backslash ("\")
USCORE = %x5F ; underscore ("_") USCORE = %x5F ; underscore ("_")
LCURLY = %x7B ; left curly brace "{" LCURLY = %x7B ; left curly brace "{"
RCURLY = %x7D ; right curly brace "}" RCURLY = %x7D ; right curly brace "}"
; Any UTF-8 [UTF-8] encoded UCS [ISO10646] character ; Any UTF-8 [UTF-8] encoded Unicode [Unicode] character
UTF8 = UTF1 / UTFMB UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4 UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF UTF0 = %x80-BF
UTF1 = %x00-7F UTF1 = %x00-7F
UTF2 = %xC2-DF UTF0 UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0) %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0) %xF4 %x80-8F 2(UTF0)
OCTET = %x00-FF ; Any octet OCTET = %x00-FF ; Any octet (8-bit data unit)
Object identifiers (OIDs) [X.680] are represented in LDAP using a dot- Object identifiers (OIDs) [X.680] are represented in LDAP using a
decimal format conforming to the ABNF: dot-decimal format conforming to the ABNF:
numericoid = number 1*( DOT number ) numericoid = number 1*( DOT number )
Short names, also known as descriptors, are used as more readable Short names, also known as descriptors, are used as more readable
aliases for object identifiers. Short names are case insensitive and aliases for object identifiers. Short names are case insensitive and
conform to the ABNF: conform to the ABNF:
descr = keystring descr = keystring
Where either an object identifier or a short name may be specified, Where either an object identifier or a short name may be specified,
skipping to change at page 6, line 16 skipping to change at page 6, line 22
While the <descr> form is generally preferred when the usage is While the <descr> form is generally preferred when the usage is
restricted to short names referring to object identifiers which restricted to short names referring to object identifiers which
identify like kinds of objects (e.g., attribute type descriptions, identify like kinds of objects (e.g., attribute type descriptions,
matching rule descriptions, object class descriptions), the matching rule descriptions, object class descriptions), the
<numericoid> form should be used when the object identifiers may <numericoid> form should be used when the object identifiers may
identify multiple kinds of objects or when an unambiguous short name identify multiple kinds of objects or when an unambiguous short name
(descriptor) is not available. (descriptor) is not available.
Implementations SHOULD treat short names (descriptors) used in an Implementations SHOULD treat short names (descriptors) used in an
unambiguous manner (as discussed above) as unrecognized. ambiguous manner (as discussed above) as unrecognized.
Short Names (descriptors) are discussed further in Section 6.2. Short Names (descriptors) are discussed further in Section 6.2.
2. Model of Directory User Information 2. Model of Directory User Information
As [X.501] states: As [X.501] states:
The purpose of the Directory is to hold, and provide access to, The purpose of the Directory is to hold, and provide access to,
information about objects of interest (objects) in some 'world'. information about objects of interest (objects) in some 'world'.
An object can be anything which is identifiable (can be named). An object can be anything which is identifiable (can be named).
skipping to change at page 6, line 48 skipping to change at page 7, line 7
of directory entries. of directory entries.
An object entry represents a particular object. An alias entry An object entry represents a particular object. An alias entry
provides alternative naming. A subentry holds administrative and/or provides alternative naming. A subentry holds administrative and/or
operational information. 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 the structure of entries.
Section 2.3 discusses the structure of entries. Section 2.3 discusses naming 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
skipping to change at page 7, line 29 skipping to change at page 7, line 35
Similarly, the superior/subordinate relationship between object Similarly, the superior/subordinate relationship between object
entries can be used to derive a relation between the objects they entries can be used to derive a relation between the objects they
represent. DIT structure rules can be used to govern relationships represent. DIT structure rules can be used to govern relationships
between objects. between objects.
Note: An entry's immediate superior is also known as the entry's Note: An entry's immediate superior is also known as the entry's
parent and an entry's immediate subordinate is also known as the parent and an entry's immediate subordinate is also known as the
entry's child. Entries which have the same parent are known as entry's child. Entries which have the same parent are known as
siblings. siblings.
2.2. Naming of Entries 2.2. Structure of an Entry
2.2.1. Relative Distinguished Names An entry consists of a set of attributes which hold information about
the object which the 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.
Attribute values conform to the defined syntax of the attribute type.
No two values of an attribute may be equivalent. Two values are
considered equivalent only 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, a 'givenName' attribute can have more than one value,
they must be Directory Strings, and they are case insensitive. A
'givenName' attribute cannot hold both "John" and "JOHN" as these are
equivalent values per the equality matching rule of the attribute
type.
When an attribute is used for naming of the entry, one and only one
value of the attribute is used in forming the Relative Distinguished
Name. This value is known as a distinguished value.
2.3. Naming of Entries
2.3.1. Relative Distinguished Names
Each entry is named relative to its immediate superior. This relative Each entry is named relative to its immediate superior. This relative
name, known as its Relative Distinguished Name (RDN) [X.501], is name, known as its Relative Distinguished Name (RDN) [X.501], is
composed of an unordered set of one or more attribute value assertions composed of an unordered set of one or more attribute value assertions
(AVA) consisting of an attribute description with zero options and an (AVA) consisting of an attribute description with zero options and an
attribute value. These AVAs are chosen from the attributes of the attribute value. These AVAs are chosen to match attribute values
entry. (each a distinguished value) of the entry.
An entry's relative distinguished name must be unique among all An entry's relative distinguished name must be unique among all
immediate subordinates of the entry's immediate superior (i.e., all immediate subordinates of the entry's immediate superior (i.e., all
siblings). siblings).
The following are examples of string representations of RDNs [LDAPDN]: The following are examples of string representations of RDNs [LDAPDN]:
UID=12345 UID=12345
OU=Engineering OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores CN=Kurt Zeilenga+L=Redwood Shores
The last is an example of a multi-valued RDN. That is, an RDN The last is an example of a multi-valued RDN. That is, an RDN
composed of multiple AVAs. composed of multiple AVAs.
2.2.2. Distinguished Names 2.3.2. Distinguished Names
An entry's fully qualified name, known as its Distinguished Name (DN) An entry's fully qualified name, known as its Distinguished Name (DN)
[X.501], is the concatenation of its RDN and its immediate superior's [X.501], is the concatenation of its RDN and its immediate superior's
DN. A Distinguished Name unambiguously refers to an entry in the DN. A Distinguished Name unambiguously refers to an entry in the
tree. The following are examples of string representations of DNs tree. The following are examples of string representations of DNs
[LDAPDN]: [LDAPDN]:
UID=nobody@example.com,DC=example,DC=com UID=nobody@example.com,DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
2.2.3. Alias Names 2.3.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
An entry consists of a set of attributes which hold information about
the object which the 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.
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, a 'givenName' attribute can have can have more than one
value, they must be Directory Strings, and they are case insensitive.
A '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 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:
- describing and categorising objects and the entries that - describing and categorising objects and the entries that
skipping to change at page 12, line 38 skipping to change at page 12, line 48
Section 2.5.2.1). Section 2.5.2.1).
All attributes of an entry must have distinct attribute descriptions. All attributes of an entry must have distinct attribute descriptions.
2.5.1. Attribute Types 2.5.1. Attribute Types
An attribute type governs whether the attribute can have multiple An attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used to construct and compare values, the syntax and matching rules used to construct and compare
values of that attribute, and other functions. values of that attribute, and other functions.
If no equality matching is specified for the attribute type:
- the attribute (of the type) cannot be used for naming;
- individual values of a multi-valued attribute attribute to be
added or deleted;
- attribute value assertions (such as matching in search filters and
comparisons) using values of such a type cannot be performed.
Otherwise, the equality matching rule is to be used for the purposes
of evaluating attribute value assertions concerning the attribute
type.
The attribute type indicates whether the attribute is a user attribute The attribute type indicates whether the attribute is a user attribute
or an operational attribute. If operational, the attribute type or an operational attribute. If operational, the attribute type
indicates the operational usage and whether the attribute is indicates the operational usage and whether the attribute is
modifiable by users or not. Operational attributes are discussed in modifiable by users or not. Operational attributes are discussed in
Section 3.4. Section 3.4.
An attribute type (a subtype) may derive from a more generic attribute An attribute type (a subtype) may derive from a more generic attribute
type (a direct supertype). The following restrictions apply to type (a direct supertype). The following restrictions apply to
subtyping: subtyping:
- a subtype must have the same usage as its direct supertype, - a subtype must have the same usage as its direct supertype,
- a subtype's syntax must be the same, or a refine of, its - a subtype's syntax must be the same, or a refinement of, its
supertype's syntax, and supertype's syntax, and
- a subtype must be collective [RFC3671] if its supertype is - a subtype must be collective [RFC3671] if its supertype is
collective. collective.
An attribute description consisting of a subtype and no options is An attribute description consisting of a subtype and no options is
said to be the direct description subtype of the attribute description said to be the direct description subtype of the attribute description
consisting of the subtype's direct supertype and no options. consisting of the subtype's direct supertype and no options.
Each attribute type is identified by an object identifier (OID) and, Each attribute type is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors). optionally, one or more short names (descriptors).
skipping to change at page 15, line 26 skipping to change at page 15, line 50
the DIT content rule applicable to that entry. That is, 'name' and 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 '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 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (nor by "MUST
name"). name").
For the purposes of other policy administration, unless stated For the purposes of other policy administration, unless stated
otherwise in the specification of the particular administrative model, otherwise in the specification of the particular administrative model,
all of the attribute descriptions in an attribute hierarchy are all of the attribute descriptions in an attribute hierarchy are
treated as distinct and unrelated descriptions. treated as distinct and unrelated descriptions.
2.5.4. Attribute Values
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 2.6. Alias Entries
As adapted from [X.501]: As adapted from [X.501]:
An alias, or an alias name, for an object is a an alternative name 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 for an object or object entry which is provided by the use of
alias entries. alias entries.
Each alias entry contains, within the 'aliasedObjectName' Each alias entry contains, within the 'aliasedObjectName'
attribute (known as the 'aliasedEntryName' attribute in X.500]), a attribute (known as the 'aliasedEntryName' attribute in X.500]), a
name of some object. The distinguished name of the alias entry is name of some object. The distinguished name of the alias entry is
thus also a name for this object. thus also a name for this object.
skipping to change at page 23, line 13 skipping to change at page 23, line 22
Schema definitions in this section are described using ABNF and rely Schema definitions in this section are described using ABNF and rely
on the common productions specified in Section 1.2 as well as these: on the common productions specified in Section 1.2 as well as these:
noidlen = numericoid [ LCURLY len RCURLY ] noidlen = numericoid [ LCURLY len RCURLY ]
len = number len = number
oids = oid / ( LPAREN WSP oidlist WSP RPAREN ) oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid ) oidlist = oid *( WSP DOLLAR WSP oid )
extensions = *( SP xstring SP qdstrings ) extensions = *( SP xstring SP qdstrings )
xstring = "X" HYPHEN 1*( UALPHA / HYPHEN / USCORE ) xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN ) qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( SP qdescr ) ] qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE qdescr = SQUOTE descr SQUOTE
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN ) qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ] qdstringlist = [ qdstring *( SP qdstring ) ]
qdstring = SQUOTE dstring SQUOTE qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
skipping to change at page 25, line 19 skipping to change at page 25, line 30
"distributedOperation" / ; DSA-shared operational "distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific 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 supertype of this type; SUP oid specifies the direct supertype of this type;
EQUALITY, ORDERING, SUBSTRING provide the oid of the equality, EQUALITY, ORDERING, SUBSTR provide the oid of the equality,
ordering, and substrings matching rules, respectively; ordering, and substrings matching rules, respectively;
SYNTAX identifies value syntax by object identifier and may suggest SYNTAX identifies value syntax by object identifier and may suggest
a minimum upper bound; a minimum upper bound;
SINGLE-VALUE indicates attributes of this type are restricted to a
single value;
COLLECTIVE indicates this attribute type is collective COLLECTIVE indicates this attribute type is collective
[X.501][RFC3671]; [X.501][RFC3671];
NO-USER-MODIFICATION indicates this attribute type is not user NO-USER-MODIFICATION indicates this attribute type is not user
modifiable; modifiable;
USAGE indicates the application of this attribute type; and USAGE indicates the application of this attribute type; and
<extensions> describe extensions. <extensions> describe extensions.
Each attribute type description must contain at least one of the SUP Each attribute type description must contain at least one of the SUP
or SYNTAX fields. If no SYNTAX field is provided, the attribute type or SYNTAX fields. If no SYNTAX field is provided, the attribute type
description takes its value from the supertype. description takes its value from the supertype.
skipping to change at page 26, line 36 skipping to change at page 26, line 49
although they may allow longer strings. Note that a single character although they may allow longer strings. Note that a single character
of the Directory String syntax may be encoded in more than one octet of the Directory String syntax may be encoded in more than one octet
since UTF-8 [RFC3629] is a variable-length encoding. since UTF-8 [RFC3629] is a variable-length encoding.
4.1.3. Matching Rules 4.1.3. Matching Rules
Matching rules are used in performance of attribute value assertions, Matching rules are used in performance of attribute value assertions,
such as in performance of a Compare operation. They are also used in such as in performance of a Compare operation. They are also used in
evaluation of a Search filters, in determining which individual values evaluation of a Search filters, in determining which individual values
are be added or deleted during performance of a Modify operation, and are be added or deleted during performance of a Modify operation, and
used in comparison of distinguished names used in comparison of distinguished names.
Each matching rule is identified by an object identifier (OID) and, Each matching rule is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors). optionally, one or more short names (descriptors).
Matching rule definitions are written according to the ABNF: Matching rule definitions are written according to the ABNF:
MatchingRuleDescription = LPAREN WSP MatchingRuleDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
skipping to change at page 42, line 37 skipping to change at page 42, line 49
Specification: RFC XXXX Specification: RFC XXXX
Author/Change Controller: IESG Author/Change Controller: IESG
Comments: Comments:
The following descriptors (short names) should be added to The following descriptors (short names) should be added to
the registry. the registry.
NAME Type OID NAME Type OID
------------------------ ---- ----------------- ------------------------ ---- -----------------
governingStructureRule A 2.5.21.10 governingStructureRule A 2.5.21.10
structuralObjectClass A 2.5.21.5 structuralObjectClass A 2.5.21.9
The following descriptors (short names) should be updated to The following descriptors (short names) should be updated to
refer to this RFC. refer to this RFC.
NAME Type OID NAME Type OID
------------------------ ---- ----------------- ------------------------ ---- -----------------
alias O 2.5.6.1 alias O 2.5.6.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
skipping to change at page 43, line 36 skipping to change at page 44, line 4
RFC 2556 by M. Wahl, all products of the IETF Access, Searching and RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
Indexing of Directories (ASID) Working Group. This document is also Indexing of Directories (ASID) Working Group. This document is also
based in part on "The Directory: Models" [X.501], a product of the based in part on "The Directory: Models" [X.501], a product of the
International Telephone Union (ITU). Additional text was borrowed International Telephone Union (ITU). Additional text was borrowed
from RFC 2253 by M. Wahl, T. Howes, and S. Kille. from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
This document is a product of the IETF LDAP Revision (LDAPBIS) Working This document is a product of the IETF LDAP Revision (LDAPBIS) Working
Group. Group.
11. Editor's Address 11. Editor's Address
Kurt Zeilenga Kurt Zeilenga
E-mail: <kurt@openldap.org> E-mail: <kurt@openldap.org>
12. References 12. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn.]]
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997. Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC3639] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3639 (also STD 63), November 2003. 10646", RFC 3629 (also STD 63), November 2003.
[RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671, [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
December 2003. December 2003.
[RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC [RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
3672, December 2003. 3672, December 2003.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
ietf-ldapbis-bcp64-xx.txt, a work in progress. draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress. progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress. draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms", Connection Level Security Mechanisms",
skipping to change at page 47, line 19 skipping to change at page 47, line 36
root DSE refers to the subschema controlling the root DSE. It is root DSE refers to the subschema controlling the root DSE. It is
noted that the general subschema discovery mechanism remains noted that the general subschema discovery mechanism remains
available (see Section 4.4 of this document). available (see Section 4.4 of this document).
A.1.2 Section 4 of RFC 2251 A.1.2 Section 4 of RFC 2251
Portions of Section 4 of RFC 2251 detailing aspects of the information Portions of Section 4 of RFC 2251 detailing aspects of the information
model used by LDAP were incorporated in this document, including: model used by LDAP were incorporated in this document, including:
- Restriction of distinguished values to attributes whose descriptions - Restriction of distinguished values to attributes whose descriptions
have no options (from Section 4.1.3). have no options (from Section 4.1.3);
- Data model aspects of Attribute Types (from Section 4.1.4), - Data model aspects of Attribute Types (from Section 4.1.4),
Attribute Descriptions (from 4.1.4), Attribute (from 4.1.8), Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
Matching Rule Identifier (from 4.1.9). Matching Rule Identifier (from 4.1.9); and
- User schema requirements (from Section 4.1.6, 4.5.1, and 4.7). - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
Clarifications to these portions include:
- Subtyping and AttributeDescriptions with options.
A.1.3 Section 6 of RFC 2251 A.1.3 Section 6 of RFC 2251
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
where incorporated into this document. where incorporated into this document.
A.2 Changes to RFC 2252 A.2 Changes to RFC 2252
This document incorporates Sections 4, 5 and 7 from RFC 2252. This document incorporates Sections 4, 5 and 7 from RFC 2252.
A.2.1 Section 4 of RFC 2252 A.2.1 Section 4 of RFC 2252
skipping to change at page 49, line 33 skipping to change at page 50, line 8
Section 7.1 of RFC 2256 provided the definition of the 'top' object Section 7.1 of RFC 2256 provided the definition of the 'top' object
class. This was integrated into Section 2.4.1 of this document. class. This was integrated into Section 2.4.1 of this document.
Section 7.2 of RFC 2256 provided the definition of the 'alias' Section 7.2 of RFC 2256 provided the definition of the 'alias'
object class. This was integrated into Section 2.6.1 of this object class. This was integrated into Section 2.6.1 of this
document. document.
Intellectual Property Rights Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain Intellectual Property Rights or other rights that might be claimed to
to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in
document or the extent to which any license under such rights might or this document or the extent to which any license under such rights
might not be available; neither does it represent that it has made any might or might not be available; nor does it represent that it has
effort to identify any such rights. Information on the IETF's made any independent effort to identify any such rights. Information
procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be found
standards-related documentation can be found in BCP-11. Copies of in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such proprietary assurances of licenses to be made available, or the result of an
rights by implementors or users of this specification can be obtained attempt made to obtain a general license or permission for the use of
from the IETF Secretariat. such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Full Copyright
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published and OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
distributed, in whole or in part, without restriction of any kind, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
 End of changes. 

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