draft-ietf-ldapbis-models-02.txt   draft-ietf-ldapbis-models-03.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 12 August 2002 Expires in six months 4 November 2002
Obsoletes: RFC 2251, RFC 2252, RFC 2256 Obsoletes: RFC 2251, RFC 2252, RFC 2256
LDAP: Directory Information Models LDAP: Directory Information Models
<draft-ietf-ldapbis-models-02.txt> <draft-ietf-ldapbis-models-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
This document is intended to be published as a Standard Track RFC. This document is intended to be published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.org>. Please send editorial mailing list <ietf-ldapbis@openldap.org>. Please send editorial
skipping to change at page 2, line 10 skipping to change at page 2, line 10
The Lightweight Directory Access Protocol (LDAP) is an Internet The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in protocol for accessing distributed directory services which act in
accordance with X.500 data and service models. This document accordance with X.500 data and service models. This document
describes the X.500 Directory Information Models, as used in LDAP. describes the X.500 Directory Information Models, as used in LDAP.
Table of Contents Table of Contents
Status of this Memo 1 Status of this Memo 1
Abstract Abstract
Table of Contents 2 Table of Contents 2
1. Introduction 4 1. Introduction 3
1.1. Relationship to Other LDAP Specifications 1.1. Relationship to Other LDAP Specifications
1.2. Conventions 5 1.2. Conventions 4
1.3. Common ABNF Productions 1.3. Common ABNF Productions
2. Model of Directory User Information 7 2. Model of Directory User Information 6
2.1. The Directory Information Tree 2.1. The Directory Information Tree
2.2. Naming of Entries 8 2.2. Naming of Entries 7
2.2.1. Relative Distinguished Names 2.3. Structure of an Entry 8
2.2.2. Distinguished Names 2.4. Object Classes
2.2.3. Alias Names 2.5. Attribute Descriptions 11
2.3. Structure of an Entry 2.6. Alias Entries 15
2.4. Object Classes 9 3. Directory Administrative and Operational Information 16
2.4.1. Abstract Object Classes 10
2.4.2. Structural Object Classes
2.4.3. Auxiliary Object Classes 11
2.5. Attribute Descriptions
2.5.1. Attribute Types 12
2.5.2. Attribute Options 13
2.5.2.1. Tagging Options
2.5.3. Attribute Description Hierarchies 14
2.5.4. Attribute Values 15
2.6. Alias Entries
2.6.1. 'alias' 16
2.6.2. 'aliasObjectName'
3. Directory Administrative and Operational Information
3.1. Subtrees 3.1. Subtrees
3.2. Subentries 17 3.2. Subentries
3.3. The 'objectClass' attribute 3.3. The 'objectClass' attribute 17
3.4. Operational attributes 18 3.4. Operational attributes 18
3.4.1. 'creatorsName' 4. Directory Schema 19
3.4.2. 'createTimestamp' 19 4.1. Schema Definitions 20
3.4.3. 'modifiersName' 4.2. Subschema Subentries 28
3.4.4. 'modifyTimestamp' 4.3. 'extensibleObject' 32
4. Directory Schema 20 4.4. Subschema Discovery
4.1. Schema Definitions 21 5. DSA (Server) Informational Model 35
4.1.1. Object Class Definitions 22 5.1. Server-specific Data Requirements
4.1.2. Attribute Types 23 6. Other Considerations 36
4.1.3. Matching Rules 24
4.1.4. LDAP Syntaxes 25
4.1.5. DIT Content Rules 26
4.1.6. DIT Structural Rules and Name Forms 27
4.2. Subschema Subentries 29
4.2.1. 'objectClasses' 30
4.2.2. 'attributeTypes'
4.2.3. 'matchingRules' 31
4.2.4. 'matchingRuleUse'
4.2.5. 'ldapSyntaxes'
4.2.6. 'dITContentRules' 32
4.2.7. 'dITStructureRules'
4.2.8. 'nameForms'
4.3. 'extensibleObject'
4.4. Subschema Discovery 33
5. DSA (Server) Informational Model
5.1. Server-specific Data Requirements 34
5.1.1. 'altServer' 35
5.1.2. 'namingContexts'
5.1.3. 'supportedControl'
5.1.4. 'supportedExtension' 36
5.1.5. 'supportedLDAPVersion'
5.1.6. 'supportedSASLMechanisms'
6. Other Considerations 37
6.1. Preservation of User Information 6.1. Preservation of User Information
6.2. Short Names 6.2. Short Names 37
6.3. Cache and Shadowing 6.3. Cache and Shadowing
7. Implementation Guidelines 38 7. Implementation Guidelines
7.1. Server Guidelines 7.1. Server Guidelines
7.2. Client Guidelines 7.2. Client Guidelines 38
8. Security Considerations 39 8. Security Considerations
9. IANA Considerations 9. IANA Considerations
10. Acknowledgments 40 10. Acknowledgments 39
11. Author's Address 11. Author's Address 40
12. References 12. References
12.1. Normative References 12.1. Normative References
12.2. Informative References 41 12.2. Informative References 41
Appendix A. Changes 42 Appendix A. Changes
A.1 Changes to RFC 2251 A.1 Changes to RFC 2251
A.1.1 Section 3.2 of RFC 2251 A.2 Changes to RFC 2252 43
A.1.2 Section 3.4 of RFC 2251 43 A.3 Changes to RFC 2256 44
A.1.2 Section 4 of RFC 2251 Copyright 45
A.1.3 Section 6 of RFC 2251 44
A.2 Changes to RFC 2252
A.2.1 Section 4 of RFC 2252
A.2.2 Section 5 of RFC 2252
A.2.3 Section 7 of RFC 2252 45
A.3 Changes to RFC 2256
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
collectively known as the Directory Information Base (DIB). A collectively known as the Directory Information Base (DIB). A
skipping to change at page 4, line 44 skipping to change at page 3, line 44
discovery. Section 5 discusses the DSA (Server) Informational Model. discovery. Section 5 discusses the DSA (Server) Informational Model.
Other X.500 information models, such as access control, collective Other X.500 information models, such as access control, collective
attribute, distribution knowledge, and replication knowledge attribute, distribution knowledge, and replication knowledge
information models, may be adapted for use in LDAP. Specification of information models, may be adapted for use in LDAP. Specification of
how these models are to be used in LDAP is left to future documents. how these models are to be used in LDAP is left to future documents.
1.1. Relationship to Other LDAP Specifications 1.1. Relationship to Other LDAP Specifications
This document is a integral part of the LDAP technical specification This document is a integral part of the LDAP technical specification
[Roadmap] which obsoletes entirely the previously defined LDAP [Roadmap] which obsoletes the previously defined LDAP technical
technical specification [LDAPTS]. specification, RFC 3377, in its entirety.
This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
portions of sections 4 and 6. Appendix A.1 summaries changes to these portions of sections 4 and 6. Appendix A.1 summaries changes to these
sections. The remainder of RFC 2251 is obsoleted by the [Protocol], sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
[AuthMeth], and [Roadmap] documents. [AuthMeth], and [Roadmap] documents.
This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
summaries changes to these sections. The remainder of RFC 2252 is summaries changes to these sections. The remainder of RFC 2252 is
obsoleted by [Syntaxes] and [Schema]. obsoleted by [Syntaxes] and [Schema].
skipping to change at page 5, line 22 skipping to change at page 4, line 22
1.2. Conventions 1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119].
Schema definitions are provided using LDAP description formats (as Schema definitions are provided using LDAP description formats (as
defined in Section 4.1). Definitions provided here are formatted defined in Section 4.1). Definitions provided here are formatted
(line wrapped) for readability. Matching rules and LDAP syntaxes (line wrapped) for readability. Matching rules and LDAP syntaxes
referenced in these defintions are defined in [Syntaxes]. referenced in these definitions are specified in [Syntaxes].
1.3. Common ABNF Productions 1.3. Common ABNF Productions
A number of syntaxes in this document are described using ABNF A number of syntaxes in this document are described using Augmented
[RFC2234]. These syntaxes (as well as a number of syntaxes defined in Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
other documents) rely on the following common productions: number of syntaxes defined in other documents) rely on the following
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 = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9" DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9" LDIGIT = %x31-39 ; "1"-"9"
skipping to change at page 6, line 8 skipping to change at page 5, line 9
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 (",")
HYPHEN = %x2D ; hypen ("-") HYPHEN = %x2D ; hyphen ("-")
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 (">")
X = %x58 ; uppercase x ("X") X = %x58 ; uppercase x ("X")
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 "}"
skipping to change at page 6, line 39 skipping to change at page 5, line 40
UTF6 = %xFC-FD 5(UTF0) UTF6 = %xFC-FD 5(UTF0)
; Any octet ; Any octet
OCTET = %x00-FF OCTET = %x00-FF
Object identifiers are represented in LDAP using a dot-decimal format Object identifiers are represented in LDAP using a dot-decimal format
conforming to the ABNF: conforming to the ABNF:
numericoid = number *( DOT number ) numericoid = number *( DOT number )
Short names, known as descriptors, are used as a more readable aliases Short names, known as descriptors, are used as more readable aliases
for object identifiers. Descriptors are case insensitive and conform for object identifiers. Descriptors are case insensitive and conform
to the the ABNF: to the ABNF:
descr = keystring descr = keystring
Where either an object identifier or a short name may be specified, Where either an object identifier or a short name may be specified,
the following production is used: the following production is used:
oid = descr / numericoid oid = descr / numericoid
The <descr> form is preferred. When a production <oid> is encoded in The <descr> form is preferred. When a production <oid> is encoded in
a value, the <descr> encoding option SHOULD be used instead of the a value, the <descr> encoding option SHOULD be used instead of the
<numericoid> encoding option. <numericoid> encoding option.
2. Model of Directory User Information 2. Model of Directory User Information
As [X.501] states: As [X.501] states:
The purpose of the Directory is to hold, and provide access to, The purpose of the Directory is to hold, and provide access to,
information about objects of interest (objects) in some 'world'. information about objects of interest (objects) in some 'world'.
skipping to change at page 7, line 34 skipping to change at page 6, line 36
a particular object. An alias entry provides alternative naming. A a particular object. An alias entry provides alternative naming. A
subentry holds administrative and/or operational information. subentry holds administrative and/or operational information.
The set of entries representing the DIB are organized hierarchically The set of entries representing the DIB are organized hierarchically
in a tree structure known as the Directory Information Tree (DIT). in a tree structure known as the Directory Information Tree (DIT).
Section 2.1 describes the Directory Information Tree Section 2.1 describes the Directory Information Tree
Section 2.2 discusses naming of entries. Section 2.2 discusses naming of entries.
Section 2.3 discusses the structure of entries. Section 2.3 discusses the structure of entries.
Section 2.4 discusses object classes. Section 2.4 discusses object classes.
Section 2.5 discusses attributes 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 9, line 10 skipping to change at page 8, line 15
2.3. Structure of an Entry 2.3. Structure of an Entry
An entry consist of a set of attributes which hold information about An entry consist of a set of attributes which hold information about
the object which entry represents. the object which entry represents.
An attribute is an attribute description, a type and one or more An attribute is an attribute description, a type and one or more
options, with one or more associated values. The attribute type options, with one or more associated values. The attribute type
governs whether the attribute can have multiple values, the syntax and governs whether the attribute can have multiple values, the syntax and
matching rules used to construct and compare values of that attribute, matching rules used to construct and compare values of that attribute,
and other functions. Options indicate subtypes and other functions. 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 associated attribute type. If the
attribute type is defined with no equality matching rule, two values
are equivalent if and only if they are identical.
An example of an attribute is 'givenName' [Schema]. There can be one An example of an attribute is 'givenName' [Schema]. There can be one
or more values of this attribute, they must be directory strings, and or more values of this attribute, they must be directory strings, and
they are case insensitive (e.g. "John" will match "JOHN"). they are case insensitive (e.g. "John" will match "JOHN").
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].
skipping to change at page 12, line 26 skipping to change at page 11, line 34
is irrelevant. That is, any two <attributedescription>s which consist is irrelevant. That is, any two <attributedescription>s which consist
of the same <attributetype> and same set of <option>s are equivalent. of the same <attributetype> and same set of <option>s are equivalent.
Examples of valid attribute descriptions: Examples of valid attribute descriptions:
2.5.4.0 2.5.4.0
cn;lang-de;lang-en cn;lang-de;lang-en
owner owner
An attribute description which consisting of an unrecognized attribute An attribute description which consisting of an unrecognized attribute
type is to be treated as unrecongized. Servers SHALL treat an type is to be treated as unrecognized. Servers SHALL treat an
attribute description with an unrecognized attribute option as attribute description with an unrecognized attribute option as
unrecongized. Client MAY treat an unrecongized attribute option as a unrecognized. Client MAY treat an unrecognized attribute option as a
tagging option (see Section 2.5.2.1). tagging option (see Section 2.5.2.1).
All attributes of an entry must have distinct attribute descriptions. All attributes of an entry must have distinct attribute descriptions.
2.5.1. Attribute Types 2.5.1. Attribute Types
An attribute type governs whether the attribute can have multiple An attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used to construct and compare values, the syntax and matching rules used to construct and compare
values of that attribute, and other functions. values of that attribute, and other functions.
A user attribute type has userApplications usage. An operational A user attribute type has userApplications usage. An operational
attribute type has one of three usages: directoryOperation, attribute type has one of three usages: directoryOperation,
distributedOperation, or dsaOperation. An operational attribute type distributedOperation, or dSAOperation. An operational attribute type
may be defined as not modifiable by users. may be defined as not modifiable by users.
A user attribute type cannot be a subtype of an operational attribute A user attribute type cannot be a subtype of an operational attribute
type. An operational attribute type which is a subtype must be type. An operational attribute type which is a subtype must be
subtype of an operational attribute type of the same usage subtype of an operational attribute type of the same usage
(application). (application).
An attribute type (a subtype) may derive from another attribute type An attribute type (a subtype) may derive from another attribute type
(a direct supertype). The subtype inherits the matching rules and (a direct supertype). The subtype inherits the matching rules and
syntax of its supertype. syntax of its supertype.
An attribute description consisting of a subtype and no options is An attribute description consisting of a subtype and no options is
said to the direct description subtype of the attribute description said to the direct description subtype of the attribute description
consisting of the subtype's direct supertype and no options. consisting of the subtype's direct supertype and no options.
Each attribute type is identified by an object identifier (OID) and, Each attribute type is identified by an object identifier (OID) and,
optionally, one or more short names known as descriptors. optionally, one or more short names known as descriptors.
Procedures for registering descriptors are detailed in [LDAPIANA]. Procedures for registering descriptors are detailed in BCP 64
[RFC3383].
2.5.2. Attribute Options 2.5.2. Attribute Options
There are multiple kinds of attribute description options. The LDAP There are multiple kinds of attribute description options. The LDAP
technical specification details one kind: tagging options. technical specification details one kind: tagging options.
Not all options can be associated with attributes held in the Not all options can be associated with attributes held in the
directory. Tagging options can be. directory. Tagging options can be.
Not all options can be use in conjunction with all attribute types. Not all options can be use in conjunction with all attribute types.
In such cases, the attribute description is to be treated as In such cases, the attribute description is to be treated as
unrecognized. unrecognized.
An attribute description that contains mutually exclusive options An attribute description that contains mutually exclusive options
shall be treated as unrecognized. That is, "cn;x-bar;x-foo" (where shall be treated as unrecognized. That is, "cn;x-bar;x-foo" (where
"x-foo" and "x-bar" are mutually exclusive) is to be treated as "x-foo" and "x-bar" are mutually exclusive) is to be treated as
unrecognized. unrecognized.
Other kinds of options may be specified in future documents. These Other kinds of options may be specified in future documents. These
documents must detail how new kinds of options they define relate to documents must detail how new kinds of options they define relate to
tagging and transfer options. In particular, these documents must tagging options. In particular, these documents must detail whether
detail whether or not new kinds of options can be associated with or not new kinds of options can be associated with attributes held in
attributes held in the directory, how new kinds of options affect the directory, how new kinds of options affect transfer of attribute
transfer of attribute values, and how new kinds of options are treated values, and how new kinds of options are treated in attribute
in attribute description hierarchies. description hierarchies.
Options are represented as short case insensitive textual strings Options are represented as short case insensitive textual strings
conforming to the <option> production defined in Section 2.5 of this conforming to the <option> production defined in Section 2.5 of this
document. document.
Procedures for registering options are detailed in [LDAPIANA]. Procedures for registering options are detailed in BCP 64 [RFC3383].
2.5.2.1. Tagging Options 2.5.2.1. Tagging Options
Attributes held in the directory can have attribute descriptions with Attributes held in the directory can have attribute descriptions with
one or more tagging options. Tagging options are never mutually one or more tagging options. Tagging options are never mutually
exclusive. exclusive.
An attribute description with N tagging options is consider a direct An attribute description with N tagging options is consider a direct
(description) subtype of all attribute descriptions of the same (description) subtype of all attribute descriptions of the same
attribute type and all but one of the N options. If the attribute attribute type and all but one of the N options. If the attribute
skipping to change at page 14, line 48 skipping to change at page 14, line 9
Where subordinate specialized descriptions are selected to be Where subordinate specialized descriptions are selected to be
returned as part of a search result these descriptions shall be returned as part of a search result these descriptions shall be
returned if available. Where the more general descriptions are returned if available. Where the more general descriptions are
selected to be returned as part of a search result both the selected to be returned as part of a search result both the
general and the specialized descriptions shall be returned, if general and the specialized descriptions shall be returned, if
available. An attribute value shall always be returned as a value available. An attribute value shall always be returned as a value
of its own attribute description. of its own attribute description.
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 for the purpose of treated as distinct and unrelated descriptions for user
administration of the entry and for user modification of entry modification of entry content.
content.
For an entry to contain a value of an attribute description
belonging to an attribute hierarchy, the attribute type of that
description must be explicitly included either in the definition
of an object class to which the entry belongs, or because the DIT
content rule applicable to that entry permits it.
An attribute value stored in a object or alias entry is of An attribute value stored in a object or alias entry is of
precisely one attribute description. The description is indicated precisely one attribute description. The description is indicated
when the value is originally added to the entry. when the value is originally added to the entry.
The indicated description may include options not stored with as part For the purpose of subschema administration of the entry, a required
of the attribute. attribute requirement is fulfilled if the entry contains a value of an
attribute description belonging to an attribute hierarchy if the
attribute type of that description is the same as the required
attribute's type. That is, a "MUST name" requirement is fulfilled by
'name' or 'name;x-tag-option', but is not fulfilled by 'CN' nor by
'CN;x-tag-option'. Likewise, an entry may contain a value of an
attribute description belonging to an attribute hierarchy if the
attribute type of that description is either explicitly included in
the definition of an object class to which the entry belongs or
allowed by the DIT content rule applicable to that entry. That is,
'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
(nor by "MUST name").
For the purposes of other policy administration, unless stated
otherwise in the specification of the particular administrative model,
all of the attribute descriptions in an attribute hierarchy are
treated as distinct and unrelated descriptions.
2.5.4. Attribute Values 2.5.4. Attribute Values
Attribute values conform to the defined syntax of the attribute. Attribute values conform to the defined syntax of the attribute.
When an attribute is used for naming of the entry, one and only one 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 value of the attribute is selected to appear in the Relative
Distinguished Name. This value is known as a distinguished value. Distinguished Name. This value is known as a distinguished value.
Only attributes whose descriptions have no options can be used for Only attributes whose descriptions have no options can be used for
skipping to change at page 18, line 39 skipping to change at page 18, line 13
modified this entry. modified this entry.
- modifyTimestamp: the time this entry was last modified. - modifyTimestamp: the time this entry was last modified.
Servers SHOULD maintain the 'creatorsName', 'createTimestamp', Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
'modifiersName', and 'modifyTimestamp' for all entries of the DIT. 'modifiersName', and 'modifyTimestamp' for all entries of the DIT.
3.4.1. 'creatorsName' 3.4.1. 'creatorsName'
This attribute appears in entries which were added using the protocol This attribute appears in entries which were added using the protocol
(e.g., using the Add operation). The value is the distinguised name (e.g., using the Add operation). The value is the distinguished name
of the creator. of the creator.
( 2.5.18.3 NAME 'creatorsName' ( 2.5.18.3 NAME 'creatorsName'
EQUALITY distinguishedNameMatch EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
skipping to change at page 19, line 26 skipping to change at page 18, line 46
USAGE directoryOperation ) USAGE directoryOperation )
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
are defined in [Syntaxes]. are defined in [Syntaxes].
3.4.3. 'modifiersName' 3.4.3. 'modifiersName'
This attribute appears in entries which have been modified using the This attribute appears in entries which have been modified using the
protocol (e.g., using Modify operation). The value is the protocol (e.g., using Modify operation). The value is the
distinguised name of the last modifier. distinguished name of the last modifier.
( 2.5.18.4 NAME 'modifiersName' ( 2.5.18.4 NAME 'modifiersName'
EQUALITY distinguishedNameMatch EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
skipping to change at page 20, line 38 skipping to change at page 20, line 14
- prevent the addition of an attribute value of a syntax not - prevent the addition of an attribute value of a syntax not
matching that defined for the attribute-type (e.g. a printable matching that defined for the attribute-type (e.g. a printable
string to a bit string). string to a bit string).
Formally, the Directory Schema comprises a set of: Formally, the Directory Schema comprises a set of:
a) Name Form definitions that define primitive naming relations a) Name Form definitions that define primitive naming relations
for structural object classes; for structural object classes;
b) DIT Structure Rule definitions that define the names that b) DIT Structure Rule definitions that define the names that
entries may have and the ways in which the the entries may be entries may have and the ways in which the entries may be
related to one another in the DIT; related to one another in the DIT;
c) DIT Content Rule definitions that extend the specification of c) DIT Content Rule definitions that extend the specification of
allowable attributes for entries beyond those indicated by the allowable attributes for entries beyond those indicated by the
structural object classes of the entries; structural object classes of the entries;
d) Object Class definitions that define the basic set of mandatory d) Object Class definitions that define the basic set of mandatory
and optional attributes that shall be present, and may be and optional attributes that shall be present, and may be
present, respectively, in an entry of a given class, and which present, respectively, in an entry of a given class, and which
indicate the kind of object class that is being defined; indicate the kind of object class that is being defined;
skipping to change at page 22, line 28 skipping to change at page 21, line 50
Implementors should note that future versions of this document may Implementors should note that future versions of this document may
expand these definitions to include additional terms. Terms whose expand these definitions to include additional terms. Terms whose
identifier begins with "X-" are reserved for private experiments, and identifier begins with "X-" are reserved for private experiments, and
MUST be followed by a <space> and a <qdstrings> tokens. MUST be followed by a <space> and a <qdstrings> tokens.
4.1.1. Object Class Definitions 4.1.1. Object Class Definitions
Object Class definitions are written according to the ABNF: Object Class definitions are written according to the ABNF:
ObjectClassDescription = RPAREN WSP ObjectClassDescription = RPAREN WSP
numericoid ; object identifer numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oids ] ; superior object classes [ SP "SUP" SP oids ] ; superior object classes
[ SP kind ] ; kind of class [ SP kind ] ; kind of class
[ SP "MUST" SP oids ] ; attribute types [ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN extensions WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
skipping to change at page 23, line 10 skipping to change at page 22, line 32
STRUCTURAL, or AUXILIARY, default is STRUCTURAL; STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
MUST and MAY specify the sets of required and allowed attribute MUST and MAY specify the sets of required and allowed attribute
types, respectively; and types, respectively; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.2. Attribute Types 4.1.2. Attribute Types
Attribute Type definitions are written according to the ABNF: Attribute Type definitions are written according to the ABNF:
AttributeTypeDescription = LPAREN WSP AttributeTypeDescription = LPAREN WSP
numericoid ; object identifer numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oid ] ; subtype [ SP "SUP" SP oid ] ; subtype
[ SP "EQUALITY" SP oid ] ; equality matching rule [ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule [ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule [ SP "SUBSTR" SP oid ] ; substrings matching rule
[ SP "SYNTAX" SP noidlen ] ; value syntax [ SP "SYNTAX" SP noidlen ] ; value syntax
[ SP "SINGLE-VALUE" ] ; single-value [ SP "SINGLE-VALUE" ] ; single-value
[ SP "COLLECTIVE" ] ; collective [ SP "COLLECTIVE" ] ; collective
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
[ SP "USAGE" SP usage ] ; usage [ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
usage = "userApplications" / usage = "userApplications" /
"directoryOperation" / "directoryOperation" /
"distributedOperation" / ; DSA-shared "distributedOperation" / ; DSA-shared
"dsaOperation" ; DSA-specific "dSAOperation" ; DSA-specific
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 identifying this attribute type; NAME <qdescrs> are short names identifying this attribute type;
DESC <qdstring> is a store descriptive string; DESC <qdstring> is a store descriptive string;
OBSOLETE indicates this attribute type is not active; OBSOLETE indicates this attribute type is not active;
SUP oid specifies the direct subtype of this type; SUP oid specifies the direct subtype of this type;
EQUALITY, ORDERING, SUBSTRING provide the oid of the equality, EQUALITY, ORDERING, SUBSTRING provide the oid of the equality,
ordering, and substrings matching rules, respectively; ordering, and substrings matching rules, respectively;
SYNTAX identifies value syntax by object identifier and suggests a SYNTAX identifies value syntax by object identifier and suggests a
minimum upper bound; minimum upper bound;
skipping to change at page 24, line 13 skipping to change at page 23, line 35
userApplications. userApplications.
Note that the <AttributeTypeDescription> does not list the matching Note that the <AttributeTypeDescription> does not list the matching
rules which can can be used with that attribute type in an rules which can can be used with that attribute type in an
extensibleMatch search filter. This is done using the extensibleMatch search filter. This is done using the
'matchingRuleUse' attribute described in Section 4.1.3. 'matchingRuleUse' attribute described in Section 4.1.3.
This document refines the schema description of X.501 by requiring This document refines the schema description of X.501 by requiring
that the SYNTAX field in an <AttributeTypeDescription> be a string that the SYNTAX field in an <AttributeTypeDescription> be a string
representation of an object identifier for the LDAP string syntax representation of an object identifier for the LDAP string syntax
definition with an optional indication of the suggested minimun bound definition with an optional indication of the suggested minimum bound
of a value of this attribute. of a value of this attribute.
A suggested minimum upper bound on the number of characters in a value A suggested minimum upper bound on the number of characters in a value
with a string-based syntax, or the number of bytes in a value for all with a string-based syntax, or the number of bytes in a value for all
other syntaxes, may be indicated by appending this bound count inside other syntaxes, may be indicated by appending this bound count inside
of curly braces following the syntax's OBJECT IDENTIFIER in an of curly braces following the syntax's OBJECT IDENTIFIER in an
Attribute Type Description. This bound is not part of the syntax name Attribute Type Description. This bound is not part of the syntax name
itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
implementations should allow a string to be 64 characters long, implementations should allow a string to be 64 characters long,
although they may allow longer strings. Note that a single character although they may allow longer strings. Note that a single character
skipping to change at page 24, line 35 skipping to change at page 24, line 13
since UTF-8 is a variable-length encoding. since UTF-8 is a variable-length encoding.
4.1.3. Matching Rules 4.1.3. Matching Rules
Matching rules are used by servers to compare attribute values against Matching rules are used by servers to compare attribute values against
assertion values when performing Search and Compare operations. They assertion values when performing Search and Compare operations. They
are also used to identify the value to be added or deleted when are also used to identify the value to be added or deleted when
modifying entries, and are used when comparing a purported modifying entries, and are used when comparing a purported
distinguished name with the name of an entry. distinguished name with the name of an entry.
A matching rule specifes the syntax of the assertion value. A matching rule specifies the syntax of the assertion value.
Each matching rule is identified by an object identifier (OID) and, Each matching rule is identified by an object identifier (OID) and,
optionally, one or more short names known as descriptors. optionally, one or more short names known as 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 identifer numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "SYNTAX" SP numericoid ; oid corrected to numericoid SP "SYNTAX" SP numericoid ; oid corrected to numericoid
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
<numericoid> is object identifier assigned to this matching rule; <numericoid> is object identifier assigned to this matching rule;
NAME <qdescrs> are short names identifying this matching rule; NAME <qdescrs> are short names identifying this matching rule;
DESC <qdstring> is a store descriptive string; DESC <qdstring> is a store descriptive string;
skipping to change at page 25, line 17 skipping to change at page 24, line 43
SYNTAX identifies the assertion syntax by object identifier; and SYNTAX identifies the assertion syntax by object identifier; and
<extensions> describe extensions. <extensions> describe extensions.
A matching rule use lists the attributes which are suitable for use A matching rule use lists the attributes which are suitable for use
with an extensible matching rule. with an extensible matching rule.
Matching rule use descriptions (see Section 4.1.3) are written Matching rule use descriptions (see Section 4.1.3) are written
according to the following ABNF: according to the following ABNF:
MatchingRuleUseDescription = LPAREN WSP MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifer numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "APPLIES" SP oids ; attribute types SP "APPLIES" SP oids ; attribute types
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
<numericoid> is the object identifier of the matching rule <numericoid> is the object identifier of the matching rule
associated with this matching rule use description; associated with this matching rule use description;
NAME <qdescrs> are short names identifying this matching rule use; NAME <qdescrs> are short names identifying this matching rule use;
skipping to change at page 25, line 48 skipping to change at page 25, line 26
known as the LDAP-specific encoding. Commonly, the LDAP-specific known as the LDAP-specific encoding. Commonly, the LDAP-specific
encoding is constrained to string of Universal Character Set (UCS) encoding is constrained to string of Universal Character Set (UCS)
[ISO10646] characters in UTF-8 [RFC2279] form. [ISO10646] characters in UTF-8 [RFC2279] form.
Each LDAP syntax is identified by an object identifier (OID). These Each LDAP syntax is identified by an object identifier (OID). These
are not intended to be displayed to users. are not intended to be displayed to users.
LDAP syntax definitions are written according to the ABNF: LDAP syntax definitions are written according to the ABNF:
SyntaxDescription = LPAREN WSP SyntaxDescription = LPAREN WSP
numericoid ; object identifer numericoid ; object identifier
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
<numericoid> is object identifier assigned to this LDAP syntax; <numericoid> is object identifier assigned to this LDAP syntax;
DESC <qdstring> is a store descriptive string; and DESC <qdstring> is a store descriptive string; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.5. DIT Content Rules 4.1.5. DIT Content Rules
skipping to change at page 26, line 25 skipping to change at page 25, line 49
A DIT content rule specifies for DIT entries of a particular A DIT content rule specifies for DIT entries of a particular
structural object class, which auxiliary object classes the entries structural object class, which auxiliary object classes the entries
are allowed to belong to and which additional attributes (by type) are are allowed to belong to and which additional attributes (by type) are
required, allowed or not allowed to appear in the entries. required, allowed or not allowed to appear in the entries.
The list of precluded attributes cannot include any attribute listed The list of precluded attributes cannot include any attribute listed
as mandatory in rule, the structural object class, or any of the as mandatory in rule, the structural object class, or any of the
allowed auxiliary object classes. allowed auxiliary object classes.
Each content rule is identified by the object identifer, as well as Each content rule is identified by the object identifier, as well as
any short names, of the structural rule it applies to. any short names, of the structural rule it applies to.
An entry may only belong to auxiliary object classes listed in the An entry may only belong to auxiliary object classes listed in the
governing content rule. governing content rule.
An entry must contain all attributes required by the object classes An entry must contain all attributes required by the object classes
the entry belongs to as well as all attributed required by the the entry belongs to as well as all attributed required by the
governing content rule. governing content rule.
An entry may contain any non-precluded attributes allowed by the An entry may contain any non-precluded attributes allowed by the
skipping to change at page 27, line 6 skipping to change at page 26, line 30
An entry is governed by (if present and active in the subschema) 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 DIT content rule which applies to the structural object class of the
entry (see Section 2.4.2). If no active rule is present for the entry (see Section 2.4.2). If no active rule is present for the
entry's structural object class, the entry's content is governed by entry's structural object class, the entry's content is governed by
the structural object class (and possibly other aspects of user and the structural object class (and possibly other aspects of user and
system schema). system schema).
DIT content rule descriptions are written according to the ABNF: DIT content rule descriptions are written according to the ABNF:
DITContentRuleDescription = LPAREN WSP DITContentRuleDescription = LPAREN WSP
numericoid ; object identifer numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
[ SP "AUX" SP oids ] ; auxiliary object classes [ SP "AUX" SP oids ] ; auxiliary object classes
[ SP "MUST" SP oids ] ; attribute types [ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types
[ SP "NOT" SP oids ] ; attribute types [ SP "NOT" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
skipping to change at page 28, line 28 skipping to change at page 28, line 4
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "FORM" SP oid ; NameForm SP "FORM" SP oid ; NameForm
[ SP "SUP" ruleids ] ; superior rules [ SP "SUP" ruleids ] ; superior rules
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
ruleids = ruleid / LPAREN WSP ruleidlist WSP RPAREN ruleids = ruleid / LPAREN WSP ruleidlist WSP RPAREN
ruleidlist = [ ruleid *( SP ruleid ) ] ruleidlist = [ ruleid *( SP ruleid ) ]
ruleid = number ruleid = number
where: where:
<ruleid> is the rule identifier of this DIT structure rule; <ruleid> is the rule identifier of this DIT structure rule;
NAME <qdescrs> are short names identifying this DIT structure rule; NAME <qdescrs> are short names identifying this DIT structure rule;
DESC <qdstring> is a store descriptive string; DESC <qdstring> is a store descriptive string;
OBSOLETE indicates this DIT structure rule use is not active; OBSOLETE indicates this DIT structure rule use is not active;
FORM is specifies the name form associated with this DIT strucure FORM is specifies the name form associated with this DIT structure
rule; rule;
SUP identifies superior rules (by rule id); and SUP identifies superior rules (by rule id); and
<extensions> describe extensions. <extensions> describe extensions.
Name form descriptions are written according to the ABNF: Name form descriptions are written according to the ABNF:
NameFormDescription = LPAREN WSP NameFormDescription = LPAREN WSP
numericoid ; object identifer numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "OC" SP oid ; structural object class SP "OC" SP oid ; structural object class
SP "MUST" SP oids ; attribute types SP "MUST" SP oids ; attribute types
[ SP "MAY" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
where: where:
<numericoid> is object identifier assigned to this name form; <numericoid> is object identifier assigned to this name form;
skipping to change at page 36, line 8 skipping to change at page 35, line 32
5.1.3. 'supportedControl' 5.1.3. 'supportedControl'
The 'supportedControl' attribute lists object identifiers identifying The 'supportedControl' attribute lists object identifiers identifying
the request controls the server supports. If the server does not the request controls the server supports. If the server does not
support any request controls, this attribute will be absent. support any request controls, this attribute will be absent.
Object identifiers identifying response controls need not be listed. Object identifiers identifying response controls need not be listed.
Procedures for registering object identifiers used to discovery of Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in [LDAPIANA]. protocol mechanisms are detailed in BCP 64 [RFC3383].
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
defined in [Syntaxes]. defined in [Syntaxes].
5.1.4. 'supportedExtension' 5.1.4. 'supportedExtension'
The 'supportedExtension' attribute lists object identifiers The 'supportedExtension' attribute lists object identifiers
skipping to change at page 36, line 30 skipping to change at page 36, line 7
server does not support any extended operations, this attribute will server does not support any extended operations, this attribute will
be absent. be absent.
An extended operation comprises a ExtendedRequest, possibly other PDUs An extended operation comprises a ExtendedRequest, possibly other PDUs
defined by extension, and an ExtendedResponse [Protocol]. The object defined by extension, and an ExtendedResponse [Protocol]. The object
identifier assigned to the ExtendedRequest is used to identify the identifier assigned to the ExtendedRequest is used to identify the
extended operation. Other object identifiers associated with the extended operation. Other object identifiers associated with the
extended operation need not be listed. extended operation need not be listed.
Procedures for registering object identifiers used to discovery of Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in [LDAPIANA]. protocol mechanisms are detailed in BCP 64 [RFC3383].
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
defined in [Syntaxes]. defined in [Syntaxes].
5.1.5. 'supportedLDAPVersion' 5.1.5. 'supportedLDAPVersion'
The 'supportedLDAPVersion' attribute lists the versions of LDAP which The 'supportedLDAPVersion' attribute lists the versions of LDAP which
skipping to change at page 37, line 29 skipping to change at page 37, line 9
Syntaxes may be defined which have specific value and/or value form Syntaxes may be defined which have specific value and/or value form
(representation) preservation requirements. For example, a syntax (representation) preservation requirements. For example, a syntax
containing digitally signed data can mandate the server preserve both containing digitally signed data can mandate the server preserve both
the value and form of value presented to ensure signature is not the value and form of value presented to ensure signature is not
invalidated. invalidated.
Where such requirements have not be explicitly stated, servers SHOULD Where such requirements have not be explicitly stated, servers SHOULD
preserve the value of user information but MAY return the value in a preserve the value of user information but MAY return the value in a
different form. Where a server is unable (or unwilling) to preserve different form. Where a server is unable (or unwilling) to preserve
the value of user information, the server SHALL ensure that an the value of user information, the server SHALL ensure that an
equivalent value is returned. Two values are considered equivalent if equivalent value (per Section 2.3) is returned.
they would match according to the equality matching rule of the
associated attribute as evaluated (within variances allowed by the
rule's specification) on that server. If the attribute is defined
with no equality matching rule, two values are equivalent only if and
only if they are identical.
6.2. Short Names 6.2. Short Names
Short names (descriptors) used to identify various schema elements are Short names (descriptors) used to identify various schema elements
non-unique, as two different specifications (neither in Standards SHOULD be registered unless in private-use name space (e.g., they
Track RFCs) may choose the same name. The client can retrieve the begin with MUST be registered.
subschema (as described above) to determine the element identified (in
that subschema) by a particular short name.
Procedures for registering short names are detailed in [LDAPIANA]. Procedures for registering short names are detailed in BCP 64
Specifications of schema elements should use registered short names to [RFC3383].
avoid conflicts.
6.3. Cache and Shadowing 6.3. Cache and Shadowing
Some servers may hold cache or shadow copies of entries, which can be Some servers may hold cache or shadow copies of entries, which can be
used to answer search and comparison queries, but will return used to answer search and comparison queries, but will return
referrals or contact other servers if modification operations are referrals or contact other servers if modification operations are
requested. Servers that perform shadowing or caching MUST ensure that requested. Servers that perform shadowing or caching MUST ensure that
they do not violate any access control constraints placed on the data they do not violate any access control constraints placed on the data
by the originating server. by the originating server.
7. Implementation Guidelines 7. Implementation Guidelines
7.1 Server Guidelines 7.1 Server Guidelines
skipping to change at page 38, line 33 skipping to change at page 38, line 6
Servers MAY support DIT Content Rules, DIT Structural Rules, and/or Servers MAY support DIT Content Rules, DIT Structural Rules, and/or
Name Forms features. To indicate support, servers SHOULD provide in Name Forms features. To indicate support, servers SHOULD provide in
the subschema the definitions of attribute types associated with the the subschema the definitions of attribute types associated with the
features they support. features they support.
Servers MAY support alias entries. To indicate support for alias Servers MAY support alias entries. To indicate support for alias
entries, servers SHOULD provide definitions for 'alias' and entries, servers SHOULD provide definitions for 'alias' and
'aliasedObjectName' in subschema (sub)entries. 'aliasedObjectName' in subschema (sub)entries.
Servers MAY support subentries. If so, they MUST do so in accordance Servers MAY support subentries. If so, they MUST do so in accordance
with [X.501]. Servers which do not support subenties SHOULD use with [X.501]. Servers which do not support subentries SHOULD use
object entries to mimic subentries as detailed in Section 3.2. object entries to mimic subentries as detailed in Section 3.2.
Servers MAY support the 'extensibleObject' object class. To indicate Servers MAY support the 'extensibleObject' object class. To indicate
support for 'extensibleObject', servers SHOULD provide the support for 'extensibleObject', servers SHOULD provide the
'extensibleObject' definition in subschema (sub)entries. 'extensibleObject' definition in subschema (sub)entries.
Servers MAY implement additional object classes. Servers SHOULD Servers MAY implement additional object classes. Servers SHOULD
provide the definitions of all object classes they support in provide the definitions of all object classes they support in
subschema (sub)entries. subschema (sub)entries.
skipping to change at page 39, line 25 skipping to change at page 38, line 44
Attributes of directory entries are used to provide descriptive Attributes of directory entries are used to provide descriptive
information about the real-world objects they represent, which can be information about the real-world objects they represent, which can be
people, organizations or devices. Most countries have privacy laws people, organizations or devices. Most countries have privacy laws
regarding the publication of information about people. regarding the publication of information about people.
General security considerations for accessing directory information General security considerations for accessing directory information
with LDAP are discussed in [Protocol] and [AuthMeth]. with LDAP are discussed in [Protocol] and [AuthMeth].
9. IANA Considerations 9. IANA Considerations
It is requested that IANA update the LDAP descriptors registry as It is requested that the Internet Assigned Numbers Authority (IANA)
indicated the following template: update the LDAP descriptors registry as indicated the following
template:
Subject: Request for LDAP Descriptor Registration Update Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment Descriptor (short name): see comment
Object Identifier: see comment Object Identifier: see comment
Person & email address to contact for further information: Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org> Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see comment Usage: see comment
Specification: RFC XXXX Specification: RFC XXXX
Author/Change Controller: IESG Author/Change Controller: IESG
Comments: Comments:
skipping to change at page 40, line 24 skipping to change at page 39, line 45
subschema O 2.5.20.1 subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10 subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13 supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7 supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15 supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14 supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0 top O 2.5.6.0
10. Acknowledgments 10. Acknowledgments
This document is based, in part, on [RFC2251] by M. Wahl, T. Howes, This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
and S. Kille and [RFC2252] by M. Wahl, A. Coulbeck, T. Howes, S. S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
Kille, both products of the IETF Access, Searching and Indexing of RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
Directories (ASID) Working Group. This document is also based, in Indexing of Directories (ASID) Working Group. This document is also
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). International Telephone Union (ITU).
11. Author's Address 11. Author's Address
Kurt Zeilenga Kurt Zeilenga
E-mail: <kurt@openldap.org> E-mail: <kurt@openldap.org>
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998. RFC 2279, January 1998.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "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.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress. progress.
[Protocol] J. Sermersheim (editor), "LDAP: The Protocol", [Protocol] J. Sermersheim (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] R. Harrison (editor), "LDAP: Authentication Methods and [AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms", Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
skipping to change at page 41, line 33 skipping to change at page 41, line 6
[LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator", [LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress. draft-ietf-ldapbis-url-xx.txt, a work in progress.
[Syntaxes] K. Dally (editor), "LDAP: Syntaxes", [Syntaxes] K. Dally (editor), "LDAP: Syntaxes",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Schema] K. Dally (editor), "LDAP: User Schema", [Schema] K. Dally (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in progress. draft-ietf-ldapbis-user-schema-xx.txt, a work in progress.
[LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP",
draft-ietf-ldapbis-xx.txt (a work in progress).
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
: 1993. : 1993.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993. Models and Service", 1993.
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.
[X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - [X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", 1994. Specification of Basic Notation", 1994.
12.2. Informative References 12.2. Informative References
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
[LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access None.
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-xx.txt.
Appendix A. Changes Appendix A. Changes
This appendix is non-normative. This appendix is non-normative.
This document amounts to nearly a complete rewrite of portions of RFC This document amounts to nearly a complete rewrite of portions of RFC
2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
overall clarity of technical specification. This appendix provides a overall clarity of technical specification. This appendix provides a
summary of substantive changes made to the portions of these documents summary of substantive changes made to the portions of these documents
incorporated into this document. Readers should consult [Roadmap], incorporated into this document. Readers should consult [Roadmap],
skipping to change at page 44, line 4 skipping to change at page 43, line 10
this server." This is inconsistent with the attribute intended use this server." This is inconsistent with the attribute intended use
as well as its formal definition as a single valued attribute as well as its formal definition as a single valued attribute
[X.501]. It is also noted that a simple (possibly incomplete) list [X.501]. It is also noted that a simple (possibly incomplete) list
of subschema (sub)entries is not terrible useful. This document (in of subschema (sub)entries is not terrible useful. This document (in
section 5.1) specifies that the 'subschemaSubentry' attribute of the section 5.1) specifies that the 'subschemaSubentry' attribute of the
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.4), Attribute (from 4.1.8),
Matching Rule Identifer (from 4.1.9). Matching Rule Identifier (from 4.1.9).
- 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).
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
 End of changes. 

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