-
-
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 15 February 2004
-Obsoletes: RFC 2251, RFC 2252, RFC 2256
+Expires in six months 21 February 2005
+Obsoletes: RFC 2251, RFC 2252, RFC 2256, RFC 3674
LDAP: Directory Information Models
- <draft-ietf-ldapbis-models-10.txt>
+ <draft-ietf-ldapbis-models-14.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 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, or will be 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
- 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.
+
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.''
+ 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>.
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
- Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full 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]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+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.
Table of Contents
Status of this Memo 1
- Abstract
- Table of Contents 2
+ Abstract 2
+ Table of Contents
1. Introduction 3
1.1. Relationship to Other LDAP Specifications
1.2. Relationship to X.501 4
1.4. Common ABNF Productions
2. Model of Directory User Information 6
2.1. The Directory Information Tree 7
- 2.2. Naming of Entries
- 2.3. Structure of an Entry 8
+ 2.2. Structure of an Entry
+ 2.3. Naming of Entries 8
2.4. Object Classes 9
- 2.5. Attribute Descriptions 11
- 2.6. Alias Entries 15
+ 2.5. Attribute Descriptions 12
+ 2.6. Alias Entries 16
3. Directory Administrative and Operational Information 17
3.1. Subtrees
- 3.2. Subentries
+ 3.2. Subentries 18
3.3. The 'objectClass' attribute
- 3.4. Operational attributes 18
- 4. Directory Schema 21
- 4.1. Schema Definitions 22
- 4.2. Subschema Subentries 31
+ 3.4. Operational attributes 19
+ 4. Directory Schema 22
+ 4.1. Schema Definitions 23
+ 4.2. Subschema Subentries 32
4.3. 'extensibleObject' 35
- 4.4. Subschema Discovery
+ 4.4. Subschema Discovery 36
5. DSA (Server) Informational Model
- 5.1. Server-specific Data Requirements 36
- 6. Other Considerations 39
- 6.1. Preservation of User Information
- 6.2. Short Names 40
+ 5.1. Server-specific Data Requirements 37
+ 6. Other Considerations 40
+ 6.1. Preservation of User Information 41
+ 6.2. Short Names
6.3. Cache and Shadowing
- 7. Implementation Guidelines
+ 7. Implementation Guidelines 42
7.1. Server Guidelines
- 7.2. Client Guidelines 41
- 8. Security Considerations
- 9. IANA Considerations 42
- 10. Acknowledgments 43
+ 7.2. Client Guidelines
+ 8. Security Considerations 43
+ 9. IANA Considerations
+ 10. Acknowledgments 44
11. Editor's Address
12. References
- 12.1. Normative References
- 12.2. Informative References 45
- Appendix A. Changes
- Intellectual Property Rights 49
- Full Copyright
-
-
Zeilenga LDAP Models [Page 2]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ 12.1. Normative References 45
+ 12.2. Informative References
+ Appendix A. Changes
+ Intellectual Property Rights 51
+ Full Copyright
1. Introduction
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]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+ 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 summarizes changes to
+ these sections. The remainder of RFC 2251 is obsoleted by the
+ [Protocol], [AuthMeth], and [Roadmap] documents.
+
This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
- summaries changes to these sections. The remainder of RFC 2252 is
+ summarizes changes to these sections. The remainder of RFC 2252 is
obsoleted by [Syntaxes].
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].
+ This document obsoletes RFC 3674 in its entirety. Appendix A.4
+ summarizes changes since RFC 3674.
+
1.2. Relationship to X.501
This document includes material, with and without adaptation, from
- [X.501]. The material in this document takes precedence over that in
- [X.501].
+ [X.501] as necessary to describe this protocol. These adaptations
+ (and any other differences herein) apply to this protocol, and only
+ this protocol.
1.3. Conventions
keystring = leadkeychar *keychar
leadkeychar = ALPHA
+
+
+
+Zeilenga LDAP Models [Page 4]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT )
- ALPHA = UALPHA / %x61-7A ; "A"-"Z" / "a"-"z"
- UALPHA = %x41-5A ; "A"-"Z"
+ 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 " "
WSP = 0*SPACE ; zero or more " "
-
-
-Zeilenga LDAP Models [Page 4]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
NULL = %x00 ; null (0)
SPACE = %x20 ; space (" ")
DQUOTE = %x22 ; quote (""")
LCURLY = %x7B ; left 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
UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(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-decimal format conforming to the ABNF:
+
+
+
+
+Zeilenga LDAP Models [Page 5]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
- Object identifiers (OIDs) [X.680] are represented in LDAP using a dot-
- decimal format conforming to the ABNF:
numericoid = number 1*( DOT number )
Where either an object identifier or a short name may be specified,
the following production is used:
-
-
-
-Zeilenga LDAP Models [Page 5]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
oid = descr / numericoid
While the <descr> form is generally preferred when the usage is
(descriptor) is not available.
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.
of directory entries.
An object entry represents a particular object. An alias entry
+
+
+
+Zeilenga LDAP Models [Page 6]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
provides alternative naming. A subentry holds administrative and/or
operational information.
in a tree structure known as the Directory Information Tree (DIT).
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.2 discusses the structure of entries.
+ Section 2.3 discusses naming of entries.
Section 2.4 discusses object classes.
Section 2.5 discusses attribute descriptions.
-
-
-
-Zeilenga LDAP Models [Page 6]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
Section 2.6 discusses alias entries.
siblings.
-2.2. Naming of Entries
+2.2. 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
+
+
+
+Zeilenga LDAP Models [Page 7]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ '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 if and only if they would match according to the
+ equality matching rule of the attribute type or, if the attribute type
+ is defined with no equality matching rule, two values are equivalent
+ if and only if they are identical. (See 2.5.1 for other
+ restrictions.)
+
+ 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.
+
+ Additionally, no attribute is to have a value which is not equivalent
+ to itself. For example, the 'givenName' attribute cannot have as a
+ value a directory string which includes the REPLACEMENT CHARACTER
+ (U+FFFD) code point as matching involving that directory string is
+ Undefined per this attribute's equality matching rule.
+
+ 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.2.1. Relative Distinguished Names
+
+2.3. Naming of Entries
+
+2.3.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.
+ attribute value. These AVAs are chosen to match attribute values
+ (each a distinguished value) 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
+
+
+
+Zeilenga LDAP Models [Page 8]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
siblings).
The following are examples of string representations of RDNs [LDAPDN]:
CN=Kurt Zeilenga+L=Redwood Shores
The last is an example of a multi-valued RDN. That is, an RDN
-
-
-
-Zeilenga LDAP Models [Page 7]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
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)
[X.501], is the concatenation of its RDN and its immediate superior's
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
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 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.
-
-
-
-
-Zeilenga LDAP Models [Page 8]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
- 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
An object class is "an identified family of objects (or conceivable
- regulating, in conjunction with DIT structure rule
specifications, the position of entries in the DIT;
+
+
+
+Zeilenga LDAP Models [Page 9]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
- regulating, in conjunction with DIT content rule
specifications, the attributes that are contained in entries;
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
-
-
-
-Zeilenga LDAP Models [Page 9]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
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
'top' abstract object class. Auxiliary object classes do not
necessarily derive from 'top'.
+
+
+
+Zeilenga LDAP Models [Page 10]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
The following is the object class definition (see Section 4.1.1) for
the 'top' object class:
Structural object classes are related to associated entries:
-
-
-Zeilenga LDAP Models [Page 10]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
- an entry conforming to a structural object class shall
represent the real-world object constrained by the object
class;
all classes in its structural object class's superclass chain.
+
+
+
+Zeilenga LDAP Models [Page 11]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
2.4.3. Auxiliary Object Classes
- Auxiliary object classes are used augment the characteristics of
+ Auxiliary object classes are used to augment the characteristics of
entries. They are commonly used to augment the sets of attributes
required and allowed to be present in an entry. They can be used to
describe entries or classes of entries.
2.5.1) and a set of zero or more attribute options (see Section
2.5.2).
-
-
-
-Zeilenga LDAP Models [Page 11]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
An attribute description is represented by the ABNF:
attributedescription = attributetype options
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
+
+
+
+Zeilenga LDAP Models [Page 12]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
Section 2.5.2.1).
All attributes of an entry must have distinct attribute descriptions.
values, the syntax and matching rules used to construct and compare
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;
+ - when adding the attribute (or replacing all values), no two values
+ may be equivalent (see 2.2);
+ - individual values of a multi-valued attribute are not to be
+ independently 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 specified equality matching rule is to be used for the
+ purposes of evaluating attribute value assertions concerning the
+ attribute type. The specified equality rule is to be transitive and
+ commutative.
+
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 is
type (a direct supertype). The following restrictions apply to
subtyping:
- 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
- a subtype must be collective [RFC3671] if its supertype is
collective.
-
-
-Zeilenga LDAP Models [Page 12]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
An attribute description consisting of a subtype and no options is
said to be the direct description subtype of the attribute description
consisting of the subtype's direct supertype and no options.
optionally, one or more short names (descriptors).
+
+
+
+Zeilenga LDAP Models [Page 13]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
2.5.2. Attribute Options
There are multiple kinds of attribute description options. The LDAP
An attribute description with N tagging options is a direct
(description) subtype of all attribute descriptions of the same
-
-
-
-Zeilenga LDAP Models [Page 13]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
attribute type and all but one of the N options. If the attribute
type has a supertype, then the attribute description is also a direct
(description) subtype of the attribute description of the supertype
in [Schema]).
+
+
+Zeilenga LDAP Models [Page 14]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
2.5.3. Attribute Description Hierarchies
An attribute description can be the direct subtype of zero or more
treated as distinct and unrelated descriptions for user
modification of entry content.
- An attribute value stored in a object or alias entry is of
+ An attribute value stored in an object or alias entry is of
precisely one attribute description. The description is indicated
when the value is originally added to the entry.
-
-
-Zeilenga LDAP Models [Page 14]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
For the purpose of subschema administration of the entry, a
specification that an attribute is required is fulfilled if the entry
contains a value of an attribute description belonging to an attribute
is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by
'CN' nor by 'CN;x-tag-option' (even though 'CN' is a subtype of
'name'). Likewise, an entry may contain a value of an attribute
+
+
+
+Zeilenga LDAP Models [Page 15]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
description belonging to an attribute hierarchy where 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
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
+ An alias, or an alias name, for an object is an alternative name
for an object or object entry which is provided by the use of
alias entries.
thus also a name for this object.
NOTE - The name within the 'aliasedObjectName' is said to be
-
-
-
-Zeilenga LDAP Models [Page 15]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
pointed to by the alias. It does not have to be the
distinguished name of any entry.
Every alias entry shall belong to the 'alias' object class.
An entry with the 'alias' object class must also belong to an object
+
+
+
+Zeilenga LDAP Models [Page 16]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
class (or classes), or be governed by a DIT content rule, which allows
suitable naming attributes to be present.
'aliasedEntryName' attribute in X.500.
( 2.5.4.1 NAME 'aliasedObjectName'
-
-
-
-Zeilenga LDAP Models [Page 16]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
As defined in [X.501]:
A subtree is a collection of object and alias entries situated at
+
+
+
+Zeilenga LDAP Models [Page 17]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
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.
all subentries are named with 'cn').
-
-
-Zeilenga LDAP Models [Page 17]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
3.3. The 'objectClass' attribute
Each entry in the DIT has an 'objectClass' attribute.
Servers which follow X.500(93) models SHALL restrict modifications of
this attribute to prevent the basic structural class of the entry from
+
+
+
+Zeilenga LDAP Models [Page 18]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
being changed. That is, one cannot change a 'person' into a
'country'.
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
-
-
-
-Zeilenga LDAP Models [Page 18]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
administrated by the user (e.g. 'ditContentRules').
A DSA-shared operational attribute is used to represent information of
Not all operational attributes are user modifiable.
Entries may contain, among others, the following operational
+
+
+
+Zeilenga LDAP Models [Page 19]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
attributes:
- creatorsName: the Distinguished Name of the user who added this
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
-
-
-
-Zeilenga LDAP Models [Page 19]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
+
+
+
+Zeilenga LDAP Models [Page 20]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
are defined in [Syntaxes].
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
-
-
-
-Zeilenga LDAP Models [Page 20]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
USAGE directoryOperation )
The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
+
+
+
+Zeilenga LDAP Models [Page 21]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
(1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
of the information and the ways in which values of attributes may
be matched in attribute value and matching rule assertions.
-
-
-
-Zeilenga LDAP Models [Page 21]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
NOTE 1 - The schema enables the Directory system to, for example:
- prevent the creation of subordinate entries of the wrong
for structural object classes;
b) DIT Structure Rule definitions that define the names that
+
+
+
+Zeilenga LDAP Models [Page 22]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
entries may have and the ways in which the entries may be
related to one another in the DIT;
4.1. Schema Definitions
Schema definitions in this section are described using ABNF and rely
-
-
-
-Zeilenga LDAP Models [Page 22]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
on the common productions specified in Section 1.2 as well as these:
noidlen = numericoid [ LCURLY len RCURLY ]
oidlist = oid *( WSP DOLLAR WSP oid )
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 )
qdescrlist = [ qdescr *( SP qdescr ) ]
qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
+
+
+Zeilenga LDAP Models [Page 23]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
terms.
The NAME field provides a set of short names (descriptors) which are
- be used as aliases for the OID.
+ to 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
are followed by <SP> and <qdstrings> tokens.
-
-
-Zeilenga LDAP Models [Page 23]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
4.1.1. Object Class Definitions
Object Class definitions are written according to the ABNF:
where:
<numericoid> is object identifier assigned to this object class;
+
+
+
+Zeilenga LDAP Models [Page 24]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
NAME <qdescrs> are short names (descriptors) identifying this object
class;
DESC <qdstring> is a short descriptive string;
[ SP "SINGLE-VALUE" ] ; single-value
[ SP "COLLECTIVE" ] ; collective
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable
-
-
-
-Zeilenga LDAP Models [Page 24]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
[ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this attribute type is not active;
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;
SYNTAX identifies value syntax by object identifier and may suggest
a minimum upper bound;
+
+
+
+Zeilenga LDAP Models [Page 25]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ SINGLE-VALUE indicates attributes of this type are restricted to a
+ single value;
COLLECTIVE indicates this attribute type is collective
[X.501][RFC3671];
NO-USER-MODIFICATION indicates this attribute type is not user
type is a DSA-specific operational attribute.
COLLECTIVE requires usage userApplications. Use of collective
-
-
-
-Zeilenga LDAP Models [Page 25]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
attribute types in LDAP is discussed in [RFC3671].
NO-USER-MODIFICATION requires an operational usage.
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
+
+
+
+Zeilenga LDAP Models [Page 26]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
other syntaxes, may be indicated by appending this bound count inside
of curly braces following the syntax's OBJECT IDENTIFIER in an
Attribute Type Description. This bound is not part of the syntax name
such as in performance of a Compare operation. They are also used in
evaluation of a Search filters, in determining which individual values
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,
optionally, one or more short names (descriptors).
SP "SYNTAX" SP numericoid ; assertion syntax
extensions WSP RPAREN ; extensions
-
-
-
-Zeilenga LDAP Models [Page 26]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
where:
<numericoid> is object identifier assigned to this matching rule;
NAME <qdescrs> are short names (descriptors) identifying this
4.1.4. Matching Rule Uses
- A matching rule use lists the attributes which are suitable for use
- with an extensibleMatch search filter.
+ A matching rule use lists the attribute types which are suitable for
+ use with an extensibleMatch search filter.
Matching rule use descriptions are written according to the following
+
+
+
+Zeilenga LDAP Models [Page 27]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
ABNF:
MatchingRuleUseDescription = LPAREN WSP
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 Unicode [Unicode] characters in
+ encoding is constrained to a string of Unicode [Unicode] characters in
UTF-8 [RFC3629] form.
Each LDAP syntax is identified by an object identifier (OID).
-
-
-Zeilenga LDAP Models [Page 27]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
LDAP syntax definitions are written according to the ABNF:
SyntaxDescription = LPAREN WSP
extensions WSP RPAREN ; extensions
where:
- <numericoid> is object identifier assigned to this LDAP syntax;
+ <numericoid> is the 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
+
+
+
+Zeilenga LDAP Models [Page 28]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
particular structural object class" [X.501].
For DIT entries of a particular structural object class, a DIT content
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
+ as mandatory in the 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
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
+ the entry belongs to as well as all attributes required by the
governing content rule.
An entry may contain any non-precluded attributes allowed by the
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
-
-
-
-Zeilenga LDAP Models [Page 28]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
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 rules for superclasses of the structural
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
[ SP "NOT" SP oids ] ; attribute types
+
+
+
+Zeilenga LDAP Models [Page 29]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
extensions WSP RPAREN ; extensions
where:
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
-
-
-
-Zeilenga LDAP Models [Page 29]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
structure rules" [X.501].
DIT structure rule descriptions are written according to the ABNF:
ruleidlist = ruleid *( SP ruleid )
ruleid = number
+
+
+Zeilenga LDAP Models [Page 30]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
where:
<ruleid> is the rule identifier of this DIT structure rule;
NAME <qdescrs> are short names (descriptors) identifying this DIT
required attribute type and zero or more values from the allowed
attribute types.
-
-
-Zeilenga LDAP Models [Page 30]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
Each name form is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
extensions WSP RPAREN ; extensions
where:
+
+
+
+Zeilenga LDAP Models [Page 31]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
<numericoid> is object identifier which identifies this name form;
NAME <qdescrs> are short names (descriptors) identifying this name
form;
A server which masters entries and permits clients to modify these
entries SHALL implement and provide access to these subschema
-
-
-
-Zeilenga LDAP Models [Page 31]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
(sub)entries including providing a 'subschemaSubentry' attribute in
- each modifiable entry. This so clients may discover the attributes
+ each modifiable entry. This is 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 '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 32]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
Subschema is held in (sub)entries belonging to the subschema auxiliary
object class.
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation )
-
-
-
-Zeilenga LDAP Models [Page 32]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
The 'objectIdentifierFirstComponentMatch' matching rule and the
ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
defined in [Syntaxes].
defined in [Syntaxes].
+
+Zeilenga LDAP Models [Page 33]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
4.2.3. 'matchingRules'
This attribute holds definitions of matching rules.
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'
-
-
+ MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
+ defined in [Syntaxes].
-Zeilenga LDAP Models [Page 33]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
+4.2.5. 'ldapSyntaxes'
This attribute holds definitions of LDAP syntaxes.
subschema.
( 2.5.21.2 NAME 'dITContentRules'
+
+
+
+Zeilenga LDAP Models [Page 34]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation )
4.2.7. 'dITStructureRules'
- This attribute lists DIT Structure Rules which present in the
+ This attribute lists DIT Structure Rules which are present in the
subschema.
( 2.5.21.1 NAME 'dITStructureRules'
( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch
-
-
-
-Zeilenga LDAP Models [Page 34]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation )
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )
+
+
+
+Zeilenga LDAP Models [Page 35]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
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.
provide access to a Directory Information Tree (DIT). The server
holding the original information is called the "master" (for that
information). Servers which hold copies of the original information
-
-
-
-Zeilenga LDAP Models [Page 35]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
are referred to as "shadowing" or "caching" servers.
As defined in [X.501]:
entries which are mastered by different servers. The context prefix
is the name of the initial entry.
+
+
+
+Zeilenga LDAP Models [Page 36]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
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.
The following attributes of the root DSE are defined in [Syntaxes].
Additional attributes may be defined in other documents.
-
-
-
-Zeilenga LDAP Models [Page 36]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
- altServer: alternative servers;
- namingContexts: naming contexts;
- supportedExtension: recognized LDAP extended operations;
+ - supportedFeatures: recognized LDAP features;
+
- supportedLDAPVersion: LDAP versions supported; and
- supportedSASLMechanisms: recognized Simple Authentication and
The values provided for these attributes may depend on
session-specific and other factors. For example, a server supporting
the SASL EXTERNAL mechanism might only list "EXTERNAL" when the
+
+
+
+Zeilenga LDAP Models [Page 37]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
client's identity has been established by a lower level. See
[AuthMeth].
The 'namingContexts' attribute lists the context prefixes of the
naming contexts the server masters or shadows (in part or in whole).
-
-
-
-Zeilenga LDAP Models [Page 37]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
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
USAGE dSAOperation )
The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
+
+
+
+Zeilenga LDAP Models [Page 38]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
defined in [Syntaxes].
extended response but may also include other protocol data units (such
as intermediate responses). The object identifier assigned to the
extended request is used to identify the extended operation. Other
-
-
-
-Zeilenga LDAP Models [Page 38]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
object identifiers used in the extended operation need not be listed
as values of this attribute.
defined in [Syntaxes].
-5.1.5. 'supportedLDAPVersion'
+5.1.5. 'supportedFeatures'
+
+
+
+
+Zeilenga LDAP Models [Page 39]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The 'supportedFeatures' attribute lists object identifiers identifying
+ elective features which the server supports. If the server does not
+ support any discoverable elective features, this attribute will be
+ absent.
+
+ ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64 [BCP64bis].
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
+ objectIdentifierMatch matching rule are defined in [Syntaxes].
+
+
+5.1.6. 'supportedLDAPVersion'
The 'supportedLDAPVersion' attribute lists the versions of LDAP which
the server supports.
[Syntaxes].
-5.1.6. 'supportedSASLMechanisms'
+5.1.7. 'supportedSASLMechanisms'
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
[SASL] which the server recognizes and/or supports [AuthMeth]. The
6. Other Considerations
-6.1. Preservation of User Information
-
- Syntaxes may be defined which have specific value and/or value form
-Zeilenga LDAP Models [Page 39]
+Zeilenga LDAP Models [Page 40]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+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
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
-Zeilenga LDAP Models [Page 40]
+Zeilenga LDAP Models [Page 41]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+ 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.
its syntax is not known. Clients MUST NOT assume the LDAP-specific
string encoding is restricted to a UTF-8 encoded string of Unicode
characters or any particular subset of Unicode (such as a printable
- subset) unless such restriction is explicitly stated. Clients SHOULD
- NOT send attribute values in a request that are not valid according to
- the syntax defined for the attributes.
-Zeilenga LDAP Models [Page 41]
+Zeilenga LDAP Models [Page 42]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ subset) unless such restriction is explicitly stated. Clients SHOULD
+ NOT send attribute values in a request that are not valid according to
+ the syntax defined for the attributes.
8. Security Considerations
9. IANA Considerations
It is requested that the Internet Assigned Numbers Authority (IANA)
- update the LDAP descriptors registry as indicated the following
+ update the LDAP descriptors registry as indicated in the following
template:
Subject: Request for LDAP Descriptor Registration Update
NAME Type OID
------------------------ ---- -----------------
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
refer to this RFC.
alias O 2.5.6.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
-Zeilenga LDAP Models [Page 42]
+Zeilenga LDAP Models [Page 43]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+ 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
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
+ supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
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
11. Editor's Address
- Kurt Zeilenga
- E-mail: <kurt@openldap.org>
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt@OpenLDAP.org
12. References
+
+
+Zeilenga LDAP Models [Page 44]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
-
-
-Zeilenga LDAP Models [Page 43]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
- [RFC3639] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3639 (also STD 63), November 2003.
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629 (also STD 63), November 2003.
[RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
December 2003.
[RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
3672, December 2003.
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
- ietf-ldapbis-bcp64-xx.txt, a work in progress.
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[SASL] Melnikov, A. (Editor), "Simple Authentication and
+
+
+
+Zeilenga LDAP Models [Page 45]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
Security Layer (SASL)",
draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
-
-
-
-Zeilenga LDAP Models [Page 44]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
as amended by the "Unicode Standard Annex #27: Unicode
3.1" (http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2"
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
12.2. Informative References
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
+
+
+
+Zeilenga LDAP Models [Page 46]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
portions of these documents.
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
-
-
-
-Zeilenga LDAP Models [Page 45]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
[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 adaptation is needed.
- Clarify that only recognized extended requests need to be enumerated
'supportedExtension'.
+
+
+
+Zeilenga LDAP Models [Page 47]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
- Clarify that only recognized request controls need to be enumerated
'supportedControl'.
'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
-
-
-
-Zeilenga LDAP Models [Page 46]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
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
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).
+ 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).
+ Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
+ Matching Rule Identifier (from 4.1.9); and
- 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
+
+
+
+Zeilenga LDAP Models [Page 48]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
where incorporated into this document.
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
-
-
-
-Zeilenga LDAP Models [Page 47]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
AttributeTypeDescription" was deleted. RFC 2252 provided no
specification of the semantics of attribute options appearing in
NAME fields.
The 'altServer' description was clarified. It may hold any URI.
+
+
+
+Zeilenga LDAP Models [Page 49]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
The 'supportedExtension' description was clarified. A server need
only list the OBJECT IDENTIFIERs associated with the extended
requests of the extended operations it recognizes.
implementation requirement. This was incorporated into Section 7 of
this document.
-
-
-
-Zeilenga LDAP Models [Page 48]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
The specification of 'extensibleObject' was clarified of how it
interacts with precluded attributes.
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to pertain
- to the implementation or use of the technology described in this
- document or the extent to which any license under such rights might or
- might not be available; neither does it represent that it has made any
- effort to identify any such rights. Information on the IETF's
- procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such proprietary
- rights by implementors or users of this specification can be obtained
- from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
-
-Zeilenga LDAP Models [Page 49]
+Zeilenga LDAP Models [Page 50]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
-
-
- Director.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2004). 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+A.4 Changes to RFC 3674
+ This document made no substantive change to the 'supportedFeatures'
+ technical specification provided in RFC 3674.
+Intellectual Property Rights
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ 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
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+Full Copyright
+ Copyright (C) The Internet Society (2005). 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 the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-Zeilenga LDAP Models [Page 50]
+Zeilenga LDAP Models [Page 51]
\f
projects / openldap / blobdiff