draft-ietf-ldapbis-models-03.txt   draft-ietf-ldapbis-models-04.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 4 November 2002 Expires in six months 3 December 2002
Obsoletes: RFC 2251, RFC 2252, RFC 2256 Obsoletes: RFC 2251, RFC 2252, RFC 2256
LDAP: Directory Information Models LDAP: Directory Information Models
<draft-ietf-ldapbis-models-03.txt> <draft-ietf-ldapbis-models-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
This document is intended to be published as a Standard Track RFC. This document is intended to be published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.org>. Please send editorial mailing list <ietf-ldapbis@openldap.org>. Please send editorial
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Status of this Memo 1 Status of this Memo 1
Abstract Abstract
Table of Contents 2 Table of Contents 2
1. Introduction 3 1. Introduction 3
1.1. Relationship to Other LDAP Specifications 1.1. Relationship to Other LDAP Specifications
1.2. Conventions 4 1.2. Conventions 4
1.3. Common ABNF Productions 1.3. Common ABNF Productions
2. Model of Directory User Information 6 2. Model of Directory User Information 6
2.1. The Directory Information Tree 2.1. The Directory Information Tree
2.2. Naming of Entries 7 2.2. Naming of Entries 7
2.3. Structure of an Entry 8 2.3. Structure of an Entry
2.4. Object Classes 2.4. Object Classes 8
2.5. Attribute Descriptions 11 2.5. Attribute Descriptions 10
2.6. Alias Entries 15 2.6. Alias Entries 14
3. Directory Administrative and Operational Information 16 3. Directory Administrative and Operational Information 15
3.1. Subtrees 3.1. Subtrees
3.2. Subentries 3.2. Subentries
3.3. The 'objectClass' attribute 17 3.3. The 'objectClass' attribute
3.4. Operational attributes 18 3.4. Operational attributes 17
4. Directory Schema 19 4. Directory Schema 19
4.1. Schema Definitions 20 4.1. Schema Definitions 20
4.2. Subschema Subentries 28 4.2. Subschema Subentries 28
4.3. 'extensibleObject' 32 4.3. 'extensibleObject' 32
4.4. Subschema Discovery 4.4. Subschema Discovery
5. DSA (Server) Informational Model 35 5. DSA (Server) Informational Model 33
5.1. Server-specific Data Requirements 5.1. Server-specific Data Requirements
6. Other Considerations 36 6. Other Considerations 36
6.1. Preservation of User Information 6.1. Preservation of User Information
6.2. Short Names 37 6.2. Short Names 37
6.3. Cache and Shadowing 6.3. Cache and Shadowing
7. Implementation Guidelines 7. Implementation Guidelines 38
7.1. Server Guidelines 7.1. Server Guidelines
7.2. Client Guidelines 38 7.2. Client Guidelines
8. Security Considerations 8. Security Considerations 39
9. IANA Considerations 9. IANA Considerations
10. Acknowledgments 39 10. Acknowledgments 40
11. Author's Address 40 11. Author's Address
12. References 12. References
12.1. Normative References 12.1. Normative References
12.2. Informative References 41 12.2. Informative References 41
Appendix A. Changes Appendix A. Changes
A.1 Changes to RFC 2251 A.1 Changes to RFC 2251 42
A.2 Changes to RFC 2252 43 A.2 Changes to RFC 2252 44
A.3 Changes to RFC 2256 44 A.3 Changes to RFC 2256 45
Copyright 45 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 6, line 36 skipping to change at page 6, line 35
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 attribute descriptions Section 2.5 discusses attribute descriptions.
Section 2.6 discusses alias entries Section 2.6 discusses alias entries.
2.1. The Directory Information Tree 2.1. The Directory Information Tree
As noted above, the DIB is composed of a set of entries organized As noted above, the DIB is composed of a set of entries organized
hierarchically in a tree structure known as the Directory Information hierarchically in a tree structure known as the Directory Information
Tree (DIT). Specifically, a tree where vertices are the entries. Tree (DIT). Specifically, a tree where vertices are the entries.
The arcs between vertices define relations between entries. If an arc The arcs between vertices define relations between entries. If an arc
exists from X to Y, then the entry at X is the immediate superior of Y exists from X to Y, then the entry at X is the immediate superior of Y
and Y is the immediate subordinate of X. An entry's superiors is the and Y is the immediate subordinate of X. An entry's superiors is the
skipping to change at page 8, line 22 skipping to change at page 8, line 18
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. No two values of an attribute may be equivalent.
Two values are considered equivalent if they would match according to Two values are considered equivalent if they would match according to
the equality matching rule of the associated attribute type. If the the equality matching rule of the associated attribute type. If the
attribute type is defined with no equality matching rule, two values attribute type is defined with no equality matching rule, two values
are equivalent if and only if they are identical. 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'. As described in [Schema]
or more values of this attribute, they must be directory strings, and and [Syntaxes], there can be one or more values of this attribute,
they are case insensitive (e.g. "John" will match "JOHN"). they must be Directory Strings, and 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].
As defined in [X.501]: As defined in [X.501]:
Object classes are used in the Directory for a number of purposes: Object classes are used in the Directory for a number of purposes:
skipping to change at page 9, line 29 skipping to change at page 9, line 27
a member of both sets, it is required to be present. a member of both sets, it is required to be present.
Each object class is defined to be one of three kinds of object Each object class is defined to be one of three kinds of object
classes: Abstract, Structural, and Auxiliary. classes: Abstract, Structural, and Auxiliary.
Each object is identified by an object identifier (OID) and, Each object 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.
2.4.1. Abstract Object Classes 2.4.1. Abstract Object Classes
An Abstract object class, as the name implies, provides a base of An abstract object class, as the name implies, provides a base of
characteristics from which other object classes can be defined to characteristics from which other object classes can be defined to
inherit from. An entry cannot belong to only abstract object classes. inherit from. An entry cannot belong to only abstract object classes.
Abstract object classes can not derive from structural nor auxiliary Abstract object classes can not derive from structural nor auxiliary
object classes. object classes.
All structural object classes derive (directly or indirectly) from the All structural object classes derive (directly or indirectly) from the
'top' abstract object class. Auxiliary object classes do not 'top' abstract object class. Auxiliary object classes do not
necessarily derive from 'top'. necessarily derive from 'top'.
skipping to change at page 11, line 36 skipping to change at page 11, line 33
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 unrecognized. 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
unrecognized. Client MAY treat an unrecognized attribute option as a unrecognized. Clients 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 which mean the attribute type is
may be defined as not modifiable by users. a directory, distributed, or DSA operational, respectively.
A user attribute type cannot be a subtype of an operational attribute An operational attribute type may be defined as not modifiable by
type. An operational attribute type which is a subtype must be users.
subtype of an operational attribute type of the same usage
(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 type cannot be a subtype of an
attribute of different usage.
An attribute description consisting of a subtype and no options is An attribute description consisting of a subtype and no options is
said to the direct description subtype of the attribute description said to the direct description subtype of the attribute description
consisting of the subtype's direct supertype and no options. consisting of the subtype's direct supertype and no options.
Each attribute type is identified by an object identifier (OID) and, Each attribute type is identified by an object identifier (OID) and,
optionally, one or more short names known as descriptors. optionally, one or more short names known as descriptors.
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 options. In particular, these documents must detail whether tagging options. In particular, these documents must detail whether
or not new kinds of options can be associated with attributes held in or not new kinds of options can be associated with attributes held in
the directory, how new kinds of options affect transfer of attribute the directory, how new kinds of options affect transfer of attribute
values, and how new kinds of options are treated in attribute values, and how new kinds of options are treated in attribute
description hierarchies. description hierarchies.
skipping to change at page 14, line 17 skipping to change at page 14, line 11
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 user treated as distinct and unrelated descriptions for user
modification of entry content. modification of entry content.
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.
For the purpose of subschema administration of the entry, a required For the purpose of subschema administration of the entry, a required
attribute requirement is fulfilled if the entry contains a value of an attribute specification is fulfilled if the entry contains a value of
attribute description belonging to an attribute hierarchy if the an attribute description belonging to an attribute hierarchy if the
attribute type of that description is the same as the required attribute type of that description is the same as the required
attribute's type. That is, a "MUST name" requirement is fulfilled by attribute's type. That is, a "MUST name" specification is fulfilled
'name' or 'name;x-tag-option', but is not fulfilled by 'CN' nor by 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 'CN;x-tag-option'. Likewise, an entry may contain a value of an
attribute description belonging to an attribute hierarchy if the attribute description belonging to an attribute hierarchy if the
attribute type of that description is either explicitly included in attribute type of that description is either explicitly included in
the definition of an object class to which the entry belongs or the definition of an object class to which the entry belongs or
allowed by the DIT content rule applicable to that entry. That is, 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' 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" name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
(nor by "MUST name"). (nor by "MUST name").
For the purposes of other policy administration, unless stated For the purposes of other policy administration, unless stated
skipping to change at page 15, line 42 skipping to change at page 15, line 32
An alias entry shall have no subordinates, so that an alias entry An alias entry shall have no subordinates, so that an alias entry
is always a leaf entry. is always a leaf entry.
Every alias entry shall belong to the 'alias' object class. Every alias entry shall belong to the 'alias' object class.
2.6.1. 'alias' object class 2.6.1. 'alias' object class
Alias entries belong to the 'alias' object class. Alias entries belong to the 'alias' object class.
( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName ) ( 2.5.6.1 NAME 'alias'
SUP top STRUCTURAL
MUST aliasedObjectName )
2.6.2. 'aliasedObjectName' attribute type 2.6.2. 'aliasedObjectName' attribute type
The 'aliasedObjectName' attribute holds the name of the entry an alias The 'aliasedObjectName' attribute holds the name of the entry an alias
points to. The 'aliasedObjectName' attribute is known as the points to. The 'aliasedObjectName' attribute is known as the
'aliasedEntryName' attribute in X.500. 'aliasedEntryName' attribute in X.500.
( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch ( 2.5.4.1 NAME 'aliasedObjectName'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
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 is defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.12) syntax is defined in [Syntaxes].
3. Directory Administrative and Operational Information 3. Directory Administrative and Operational Information
This section discusses select aspects of the X.500 Directory This section discusses select aspects of the X.500 Directory
Administrative and Operational Information model [X.501]. LDAP Administrative and Operational Information model [X.501]. LDAP
implementations MAY support other aspects of this model. implementations MAY support other aspects of this model.
skipping to change at page 16, line 45 skipping to change at page 16, line 39
3.2. Subentries 3.2. Subentries
A subentry is a "special sort of entry, known by the Directory, used A subentry is a "special sort of entry, known by the Directory, used
to hold information associated with a subtree or subtree refinement" to hold information associated with a subtree or subtree refinement"
[X.501]. Subentries are used in Directory to hold for administrative [X.501]. Subentries are used in Directory to hold for administrative
and operational purposes as defined in [X.501]. Their use in LDAP is and operational purposes as defined in [X.501]. Their use in LDAP is
not detailed in this technical specification, but may be detailed in not detailed in this technical specification, but may be detailed in
future documents. future documents.
The term "(sub)entry" in this specification indicates that servers The term "(sub)entry" in this specification indicates that servers
implementing X.500(93) models are to use a subentry and other servers implementing X.500(93) models are to use a subentry and that other
use an object entry belonging to the appropriate auxiliary class servers use an object entry belonging to the appropriate auxiliary
normally used with the subentry (e.g., 'subschema' for subschema class normally used with the subentry (e.g., 'subschema' for subschema
subentries) to mimic the subentry. This object entry's RDN SHALL be subentries) to mimic the subentry. This object entry's RDN SHALL be
formed from a value of the 'cn' (commonName) attribute [Schema]. formed from a value of the 'cn' (commonName) attribute [Schema].
3.3. The 'objectClass' attribute 3.3. The 'objectClass' attribute
Each entry in the DIT has an 'objectClass' attribute. Each entry in the DIT has an 'objectClass' attribute.
( 2.5.4.0 NAME 'objectClass' ( 2.5.4.0 NAME 'objectClass'
EQUALITY objectIdentifierMatch EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
skipping to change at page 17, line 24 skipping to change at page 17, line 18
(1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes]. (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
The 'objectClass' attribute specifies the object classes of an entry, The 'objectClass' attribute specifies the object classes of an entry,
which (among other things) is used in conjunction with user and system which (among other things) is used in conjunction with user and system
schema to determine the permitted attributes of an entry. Values of schema to determine the permitted attributes of an entry. Values of
this attribute can be modified by clients, but the 'objectClass' this attribute can be modified by clients, but the 'objectClass'
attribute cannot be removed. attribute cannot be removed.
Servers which follow X.500(93) models SHALL restrict modifications of Servers which follow X.500(93) models SHALL restrict modifications of
this attribute to prevent the basic structural class of the entry from this attribute to prevent the basic structural class of the entry from
being changed (e.g. one cannot change a 'person' into a 'country'). being changed. That is, one cannot change a 'person' into a
'country'.
When creating an entry or adding an 'objectClass' value to an entry, When creating an entry or adding an 'objectClass' value to an entry,
all superclasses of the named classes are implicitly added as well if all superclasses of the named classes SHALL be implicitly added as
not already present, and the client must supply values for any well if not already present, and the client must supply values for any
mandatory attributes of new superclasses. mandatory attributes of new superclasses. That is, if the auxiliary
class 'x-a' is a subclass of the class 'x-b', adding 'x-a' to
'objectClass' causes 'x-b' to added (if is not already present).
Servers SHALL restrict modifications of this attribute to to prevent a
superclasses of remaining 'objectClass' values from being deleted.
That is, if the auxiliary class 'x-a' is a subclass of the class 'x-
b', attempting to deleting 'x-b' to 'objectClass' is an error.
3.4. Operational attributes 3.4. Operational attributes
Some attributes, termed operational attributes (as defined in Section Some attributes, termed operational attributes (as defined in Section
12.4.1 of [X.501]), are used or maintained by servers for 12.4.1 of [X.501]), are used or maintained by servers for
administrative and operational purposes. Not all operational administrative and operational purposes. Not all operational
attributes are user modifiable. attributes are user modifiable.
Operational attributes are not normally visible. They are not Operational attributes are not normally visible. They are not
returned in search results unless explicitly requested by name. returned in search results unless explicitly requested by name.
skipping to change at page 20, line 48 skipping to change at page 20, line 48
4.1. Schema Definitions 4.1. Schema Definitions
Schema definitions in this section are described using ABNF and rely Schema definitions in this section are described using ABNF and rely
on the common productions specified in Section 1.2 as well as these: on the common productions specified in Section 1.2 as well as these:
noidlen = numericoid [ LCURLY len RCURLY ] noidlen = numericoid [ LCURLY len RCURLY ]
len = number len = number
oids = oid / ( LPAREN SP oidlist SP RPAREN ) oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( SP DOLLAR SP oid ) oidlist = oid *( WSP DOLLAR WSP oid )
extensions = *( SP xstring SP qdstrings ) extensions = *( SP xstring SP qdstrings )
xstring = X HYPHEN 1*( ALPHA / HYPHEN / USCORE ) xstring = X HYPHEN 1*( ALPHA / HYPHEN / USCORE )
qdescrs = qdescr / ( LPAREN WHSP qdescrlist WHSP RPAREN ) qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( WHSP qdescr ) ] qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE qdescr = SQUOTE descr SQUOTE
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ]
qdstring = SQUOTE dstring SQUOTE qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF8 string dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF8 string
QQ = ESC %x32 %x37 ; "\27" QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5C" QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
; Any UTF-8 encoded UCS character ; Any UTF-8 encoded UCS character
; except %x27 ("'") and %x5C ("\") ; except %x27 ("'") and %x5C ("\")
QUTF8 = QUTF1 / UTFMB QUTF8 = QUTF1 / UTFMB
; Any ASCII character except %x27 ("'") and %x5C ("\") ; Any ASCII character except %x27 ("'") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F QUTF1 = %x00-26 / %x28-5B / %x5D-7F
Schema definitions in this section also share a number of common Schema definitions in this section also share a number of common
terms. terms.
skipping to change at page 21, line 43 skipping to change at page 21, line 47
be used as aliases for the OID. be used as aliases for the OID.
The DESC field optionally allows a descriptive string to be provided The DESC field optionally allows a descriptive string to be provided
by the directory administrator and/or implementor. While by the directory administrator and/or implementor. While
specifications may suggest a descriptive string, there is no specifications may suggest a descriptive string, there is no
requirement that the suggested (or any) descriptive string be used. requirement that the suggested (or any) descriptive string be used.
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 <space> and <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 = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
[ SP "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"
where: where:
<numericoid> is object identifier assigned to this object class; <numericoid> is object identifier assigned to this object class;
NAME <qdescrs> are short names identifying this object class; NAME <qdescrs> are short names (descriptors) identifying this object
DESC <qdstring> is a store descriptive string; class;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this object class is not active; OBSOLETE indicates this object class is not active;
SUP <oids> specifies the direct superclasses of this object class; SUP <oids> specifies the direct superclasses of this object class;
the kind of object class is indicated by one of ABSTRACT, the kind of object class is indicated by one of ABSTRACT,
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 identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
[ SP "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
skipping to change at page 22, line 46 skipping to change at page 23, line 4
[ 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 (descriptors) identifying this
DESC <qdstring> is a store descriptive string; attribute type;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this attribute type is not active; OBSOLETE indicates this attribute type is not active;
SUP oid specifies the direct subtype of this type; SUP oid specifies the direct 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;
COLLECTIVE indicates this attribute type is collective; COLLECTIVE indicates this attribute type is collective;
NO-USER-MODIFICATION indicates this attribute type is not user NO-USER-MODIFICATION indicates this attribute type is not user
modifiable; modifiable;
USAGE indicates the application of this attribute type; and USAGE indicates the application of this attribute type; and
<extensions> describe extensions. <extensions> describe extensions.
Each attribute type description must contain at least one of the SUP Each attribute type description must contain at least one of the SUP
or SYNTAX fields. or SYNTAX fields.
The default USAGE is userApplications. COLLECTIVE requires USAGE The default USAGE is userApplications. COLLECTIVE requires USAGE
userApplications. NO-USER_MODIFICATION requires usage other than userApplications. NO-USER-MODIFICATION requires usage other than
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
skipping to change at page 24, line 22 skipping to change at page 24, line 24
A matching rule specifies the syntax of the assertion value. A matching rule specifies the syntax of the assertion value.
Each matching rule is identified by an object identifier (OID) and, Each matching rule is identified by an object identifier (OID) and,
optionally, one or more short names known as descriptors. optionally, one or more short names 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 identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "SYNTAX" SP numericoid ; oid corrected to numericoid SP "SYNTAX" SP numericoid ; oid corrected to numericoid
extensions WSP RPAREN ; extensions extensions WSP RPAREN ; extensions
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 (descriptors) identifying this
DESC <qdstring> is a store descriptive string; matching rule;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this matching rule is not active; OBSOLETE indicates this matching rule is not active;
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 identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "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 (descriptors) identifying this
DESC <qdstring> is a store descriptive string; matching rule use;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this matching rule use is not active; OBSOLETE indicates this matching rule use is not active;
APPLIES provides a list of attribute types the matching rule applies APPLIES provides a list of attribute types the matching rule applies
to; and to; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.4. LDAP Syntaxes 4.1.4. LDAP Syntaxes
LDAP Syntaxes of (attribute and assertion) values are described in LDAP Syntaxes of (attribute and assertion) values are described in
terms of ASN.1 [X.680] and, optionally, have an octet string encoding terms of ASN.1 [X.680] and, optionally, have an octet string encoding
known as the LDAP-specific encoding. Commonly, the LDAP-specific known as the LDAP-specific encoding. Commonly, the LDAP-specific
skipping to change at page 25, line 32 skipping to change at page 25, line 37
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 identifier 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 short descriptive string; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.5. DIT Content Rules 4.1.5. DIT Content Rules
A DIT content rule is a "rule governing the content of entries of a A DIT content rule is a "rule governing the content of entries of a
particular structural object class" [X.501]. particular structural object class" [X.501].
A DIT content rule specifies for DIT entries of a particular 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 identifier, 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 (descriptors), 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
object classes the entry belongs to as well as all attributes allowed object classes the entry belongs to as well as all attributes allowed
skipping to change at page 26, line 31 skipping to change at page 26, line 37
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 identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
[ SP "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:
<numericoid> is the object identifier of the structural object class <numericoid> is the object identifier of the structural object class
associated with this DIT content rule; associated with this DIT content rule;
NAME <qdescrs> are short names identifying this DIT content rule; NAME <qdescrs> are short names (descriptors) identifying this DIT
DESC <qdstring> is a store descriptive string; content rule;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this DIT content rule use is not active; OBSOLETE indicates this DIT content rule use is not active;
AUX specifies a list of auxiliary object classes which entries AUX specifies a list of auxiliary object classes which entries
subject to this DIT content rule may belong to; subject to this DIT content rule may belong to;
MUST, MAY, and NOT specify lists of attribute types which are MUST, MAY, and NOT specify lists of attribute types which are
required, allowed, or precluded, respectively, from appearing in required, allowed, or precluded, respectively, from appearing in
entries subject to this DIT content rule; and entries subject to this DIT content rule; and
<extensions> describe extensions. <extensions> describe extensions.
4.1.6. DIT Structural Rules and Name Forms 4.1.6. DIT Structural Rules and Name Forms
skipping to change at page 27, line 40 skipping to change at page 27, line 46
required attribute type and zero or more values from the allowed required attribute type and zero or more values from the allowed
attribute types. attribute types.
Each name form is identified by an object identifier (OID) and, Each name form is identified by an object identifier (OID) and,
optionally, one or more short names known as descriptors. optionally, one or more short names known as descriptors.
DIT structure rule descriptions are written according to the ABNF: DIT structure rule descriptions are written according to the ABNF:
DITStructureRuleDescription = LPAREN WSP DITStructureRuleDescription = LPAREN WSP
ruleid ; rule identifier ruleid ; rule identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "FORM" SP oid ; NameForm SP "FORM" SP oid ; NameForm
[ SP "SUP" ruleids ] ; superior rules [ SP "SUP" ruleids ] ; superior rules
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 (descriptors) identifying this DIT
DESC <qdstring> is a store descriptive string; structure rule;
DESC <qdstring> is a short 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 structure 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 identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "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;
NAME <qdescrs> are short names identifying this name form; NAME <qdescrs> are short names (descriptors) identifying this name
DESC <qdstring> is a store descriptive string; form;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this name form is not active; OBSOLETE indicates this name form is not active;
OC identifies the structural object class this rule applies to, OC identifies the structural object class this rule applies to,
MUST and MAY specify the sets of required and allowed, respectively, MUST and MAY specify the sets of required and allowed, respectively,
naming attributes for this name form; and naming attributes for this name form; and
<extensions> describe extensions. <extensions> describe extensions.
4.2. Subschema Subentries 4.2. Subschema Subentries
Subschema (sub)entries are used for administering information about Subschema (sub)entries are used for administering information about
the directory schema. A single subschema (sub)entry contains all the directory schema. A single subschema (sub)entry contains all
schema definitions (see Section 4.1) used by entries in a particular schema definitions (see Section 4.1) used by entries in a particular
part of the directory tree. part of the directory tree.
Servers which follow X.500(93) models SHOULD implement subschema using Servers which follow X.500(93) models SHOULD implement subschema using
the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]), the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
and so these are not ordinary object entries but subentries (see and so these are not ordinary object entries but subentries (see
Section 3.2). LDAP clients SHOULD NOT assume that servers implement Section 3.2). LDAP clients SHOULD NOT assume that servers implement
any of the other aspects of X.500 subschema. any of the other aspects of X.500 subschema.
Servers MAY allow modification of subschema. Procedures for Subschema Servers MAY allow subschema modification. Procedures for subschema
Modification are discussed in Section 14.5 of [X.501]. modification are discussed in Section 14.5 of [X.501].
A server which masters entries and permits clients to modify these A server which masters entries and permits clients to modify these
entries MUST implement and provide access to these subschema entries MUST implement and provide access to these subschema
(sub)entries including providing a 'subschemaSubentry' attribute in (sub)entries including providing a 'subschemaSubentry' attribute in
each modifiable entry. This so clients may discover the attributes each modifiable entry. This so clients may discover the attributes
and object classes which are permitted to be present. It is strongly and object classes which are permitted to be present. It is strongly
RECOMMENDED that all other servers implement this as well. RECOMMENDED that all other servers implement this as well.
A server SHALL only publish schema definitions for elements it
supports. It is noted that servers do not necessarily have to support
all schema elements referenced by a published definition.
The value of the 'subschemaSubentry' attribute is the name of the The value of the 'subschemaSubentry' attribute is the name of the
subschema (sub)entry holding the subschema controlling the entry. subschema (sub)entry holding the subschema controlling the entry.
( 2.5.18.10 NAME 'subschemaSubentry' ( 2.5.18.10 NAME 'subschemaSubentry'
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
NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE
USAGE directoryOperation ) USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName The 'distinguishedNameMatch' matching rule and the DistinguishedName
skipping to change at page 29, line 39 skipping to change at page 29, line 45
object class. object class.
( 2.5.20.1 NAME 'subschema' AUXILIARY ( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $ MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $ objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) ) matchingRuleUse ) )
The 'ldapSyntaxes' operational attribute may also be present in The 'ldapSyntaxes' operational attribute may also be present in
subschema entries. subschema entries.
Servers MAY provide other attributes in subschema (sub)entries to Servers MAY provide additional attributes (described in other
reflect additional supported capabilities or for other administrative documents) in subschema (sub)entries.
and operational purposes.
Servers SHOULD provide the attributes 'createTimestamp' and Servers SHOULD provide the attributes 'createTimestamp' and
'modifyTimestamp' in subschema (sub)entries, in order to allow clients 'modifyTimestamp' in subschema (sub)entries, in order to allow clients
to maintain their caches of schema information. to maintain their caches of schema information.
The following subsections provide attribute type definitions for each The following subsections provide attribute type definitions for each
of schema definition attribute types. of schema definition attribute types.
4.2.1. 'objectClasses' 4.2.1. 'objectClasses'
skipping to change at page 32, line 43 skipping to change at page 32, line 47
still required to be present and any precluded attributes are still still required to be present and any precluded attributes are still
not allowed to be present. not allowed to be present.
Note that not all servers will implement this object class, and those Note that not all servers will implement this object class, and those
which do not will reject requests to add entries which contain this which do not will reject requests to add entries which contain this
object class, or modify an entry to add this object class. object class, or modify an entry to add this object class.
4.4. Subschema Discovery 4.4. Subschema Discovery
To discover the DN of the subschema (sub)entry holding the subschema To discover the DN of the subschema (sub)entry holding the subschema
controlling a particular entry (or subentry), a client reads that controlling a particular entry, a client reads that entry's
entry's 'subschemaSubentry' operational attribute. To read schema 'subschemaSubentry' operational attribute. To read schema attributes
attributes from the subschema (sub)entry, clients MUST issue a base from the subschema (sub)entry, clients MUST issue a base object search
object search where the filter is "(objectClass=subschema)" and the where the filter is "(objectClass=subschema)" [Filters] and the list
list of attributes includes the names of the desired schema attributes of attributes includes the names of the desired schema attributes (as
(as they are operational). This filter allows LDAP servers which they are operational). This filter allows LDAP servers which gateway
gateway to X.500 to detect that subentry information is being to X.500 to detect that subentry information is being requested.
requested.
Clients SHOULD NOT assume that server supports all referenced elements
of a particular definition. For example, a client is not to assume
the server supports the EQUALITY matching rule of a listed attribute
unless the server publishes a definition for that matching rule.
5. DSA (Server) Informational Model 5. DSA (Server) Informational Model
The LDAP protocol assumes there are one or more servers which jointly The LDAP protocol assumes there are one or more servers which jointly
provide access to a Directory Information Tree (DIT). provide access to a Directory Information Tree (DIT).
As defined in [X.501]: As defined in [X.501]:
context prefix: The sequence of RDNs leading from the Root of the context prefix: The sequence of RDNs leading from the Root of the
DIT to the initial vertex of a naming context; corresponds to DIT to the initial vertex of a naming context; corresponds to
the distinguished name of that vertex. the distinguished name of that vertex.
DIB fragment: The portion of the DIB that is held by one master DIB fragment: The portion of the DIB that is held by one master
DSA, comprising one or more naming contexts. DSA, comprising one or more naming contexts.
naming context: A subtree of entries held in a single master DSA. naming context: A subtree of entries held in a single master DSA.
That is, a naming context is the largest collection of entries, That is, a naming context is the largest collection of entries,
starting at an entry that is mastered by a particular server, and starting at an entry that is mastered by a particular server, and
including all its subordinates and their subordinates, down to the including all its subordinates and their subordinates, down to the
entries which are mastered by different servers. And the context entries which are mastered by different servers. The context prefix
prefix is the name of the initial entry. is the name of the initial entry.
The root of the DIT is a DSA-specific Entry (DSE) and not part of any 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 naming context (or any subtree); each server has different attribute
values in the root DSE. values in the root DSE.
5.1. Server-specific Data Requirements 5.1. Server-specific Data Requirements
An LDAP server MUST provide information about itself and other An LDAP server MUST provide information about itself and other
information that is specific to each server. This is represented as a information that is specific to each server. This is represented as a
group of attributes located in the root DSE (DSA-Specific Entry), group of attributes located in the root DSE (DSA-Specific Entry),
which is named with the zero-length LDAPDN. These attributes are which is named with the zero-length LDAPDN. These attributes are
retrievable, subject to access control and other restrictions, if a retrievable, subject to access control and other restrictions, if a
client performs a base object search of the root with filter client performs a base object search of the root with the filter
"(objectClass=*)" requesting the desired attributes. It is noted that "(objectClass=*)" [Filters] requesting the desired attributes. It is
root DSE attributes are operational, and like other operational noted that root DSE attributes are operational, and like other
attributes, are not returned in search requests unless requested by operational attributes, are not returned in search requests unless
name. requested by name.
The root DSE SHALL NOT be included if the client performs a subtree The root DSE SHALL NOT be included if the client performs a subtree
search starting from the root. search starting from the root.
Servers may allow clients to modify attributes of the root DSE where Servers may allow clients to modify attributes of the root DSE where
appropriate. appropriate.
The following attributes of the root DSE are defined in [Syntaxes]. The following attributes of the root DSE are defined in [Syntaxes].
Additional attributes may be defined in other documents. Additional attributes may be defined in other documents.
skipping to change at page 34, line 26 skipping to change at page 34, line 23
- namingContexts: naming contexts; - namingContexts: naming contexts;
- supportedControl: recognized LDAP controls; - supportedControl: recognized LDAP controls;
- supportedExtension: recognized LDAP extended operations; - supportedExtension: recognized LDAP extended operations;
- supportedLDAPVersion: LDAP versions supported; and - supportedLDAPVersion: LDAP versions supported; and
- supportedSASLMechanisms: recognized SASL mechnanisms. - supportedSASLMechanisms: recognized SASL mechnanisms.
The values of these attributes provided may depend on a session The values of these attributes provided may depend on session specific
specific and other factors. For example, a server supporting the SASL and other factors. For example, a server supporting the SASL EXTERNAL
EXTERNAL mechanism may only list "EXTERNAL" when the client's identity mechanism may only list "EXTERNAL" when the client's identity has been
has been established by a lower level. See [AuthMeth]. established by a lower level. See [AuthMeth].
The root DSE may also include a 'subschemaSubentry' attribute. If so, The root DSE may also include a 'subschemaSubentry' attribute. If so,
it refers to the subschema (sub)entry holding schema controlling it refers to the subschema (sub)entry holding schema controlling
attributes of the root DSE. Client SHOULD NOT assume that the attributes of the root DSE. Client SHOULD NOT assume that the
subschema (sub)entry controlling the root DSE controls any entry held subschema (sub)entry controlling the root DSE controls any entry held
by the server. General subschema discovery procedures are provided in by the server. General subschema discovery procedures are provided in
Section 4.4. Section 4.4.
5.1.1. 'altServer' 5.1.1. 'altServer'
The 'altServer' attribute lists URLs referring to alternative servers The 'altServer' attribute lists URLs referring to alternative servers
which may be contacted when this server becomes unavailable. If the which may be contacted when this server becomes unavailable. If the
server does not know of any other servers which could be used this server does not know of any other servers which could be used this
attribute will be absent. Clients may cache this information in case attribute will be absent. Clients may cache this information in case
their preferred LDAP server later becomes unavailable. their preferred LDAP server later becomes unavailable.
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE dSAOperation )
The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
[Syntaxes]. [Syntaxes].
5.1.2. 'namingContexts' 5.1.2. 'namingContexts'
The 'namingContexts' attribute lists the context prefixes of the The 'namingContexts' attribute lists the context prefixes of the
naming contexts the server masters or shadows (in part or in whole). naming contexts the server masters or shadows (in part or in whole).
If the server does not master or shadow any information (e.g. it is an If the server does not master or shadow any information (e.g. it is an
LDAP gateway to a public X.500 directory) this attribute will be LDAP gateway to a public X.500 directory) this attribute will be
absent. If the server believes it masters or shadows the entire absent. If the server believes it masters or shadows the entire
directory, the attribute will have a single value, and that value will directory, the attribute will have a single value, and that value will
be the empty string (indicating the null DN of the root). This be the empty string (indicating the null DN of the root). This
attribute allows a client to choose suitable base objects for attribute allows a client to choose suitable base objects for
searching when it has contacted a server. searching when it has contacted a server.
skipping to change at page 35, line 18 skipping to change at page 35, line 15
naming contexts the server masters or shadows (in part or in whole). naming contexts the server masters or shadows (in part or in whole).
If the server does not master or shadow any information (e.g. it is an If the server does not master or shadow any information (e.g. it is an
LDAP gateway to a public X.500 directory) this attribute will be LDAP gateway to a public X.500 directory) this attribute will be
absent. If the server believes it masters or shadows the entire absent. If the server believes it masters or shadows the entire
directory, the attribute will have a single value, and that value will directory, the attribute will have a single value, and that value will
be the empty string (indicating the null DN of the root). This be the empty string (indicating the null DN of the root). This
attribute allows a client to choose suitable base objects for attribute allows a client to choose suitable base objects for
searching when it has contacted a server. searching when it has contacted a server.
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE dSAOperation )
The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
defined in [Syntaxes]. defined in [Syntaxes].
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 BCP 64 [RFC3383]. 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
identifying the extended operations which the server supports. If the identifying the extended operations which the server supports. If the
server does not support any extended operations, this attribute will server does not support any extended operations, this attribute will
be absent. be absent.
skipping to change at page 36, line 10 skipping to change at page 36, line 10
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 BCP 64 [RFC3383]. 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
the server supports. the server supports.
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
USAGE dSAOperation )
The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
[Syntaxes]. [Syntaxes].
5.1.6. 'supportedSASLMechanisms' 5.1.6. 'supportedSASLMechanisms'
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
[RFC2222] which the server recognizes. The contents of this attribute [RFC2222] which the server recognizes. The contents of this attribute
may depend on the current session state. If the server does not may depend on the current session state. If the server does not
support any SASL mechanisms this attribute will not be present. support any SASL mechanisms this attribute will not be present.
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE dSAOperation )
The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
in [Syntaxes]. in [Syntaxes].
6. Other Considerations 6. Other Considerations
6.1. Preservation of User Information 6.1. Preservation of User Information
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. And where a server is unable (or unwilling) to
the value of user information, the server SHALL ensure that an preserve the value of user information, the server SHALL ensure that
equivalent value (per Section 2.3) is returned. an equivalent value (per Section 2.3) is returned.
6.2. Short Names 6.2. Short Names
Short names (descriptors) used to identify various schema elements Short names, also known as descriptors, are used as more readable
SHOULD be registered unless in private-use name space (e.g., they aliases for object identifiers and are used to identify various schema
begin with MUST be registered. elements. The same short name might have different meaning in
different subschemas and, within a particular subschema, the same
short name might refer to different object identifiers each
identifying a different kind of schema element.
Procedures for registering short names are detailed in BCP 64 Implementations MUST be prepared that the same short name might be
[RFC3383]. used in a subschema to refer to the different kinds of schema
elements. That is, there might be an object class 'x-fubar' and an
attribute type 'x-fubar' in a subschema.
Implementations MUST be prepared that the same short name might be
used in the different subschemas to refer to the different schema
elements. That is, there might be two matching rules 'x-fubar', each
in different subschemas.
Procedures for registering short names (descriptors) are detailed in
BCP 64 [RFC3383bis].
[[The remainder of this subsection will be included a subsequent
revision of RFC 3383.]]
To avoid interoperability problems, the following additional
considerations are stated:
Descriptors used to identify various schema SHOULD be registered
unless in private-use name space (e.g., they begin with "x-").
Descriptors defined in RFCs MUST be registered.
While the protocol allows the same descriptor to refer to
different object identifiers in certain cases and the registry
supports multiple registrations of the same descriptor (each
indicating a different kind of schema element and different object
identifier), multiple registrations of the same descriptor are to
be avoided. All such registration requests require Expert Review.
6.3. Cache and Shadowing 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.
skipping to change at page 37, line 42 skipping to change at page 38, line 27
Servers MUST recognize all attribute types and object classes defined Servers MUST recognize all attribute types and object classes defined
in this document but, unless stated otherwise, need not support the in this document but, unless stated otherwise, need not support the
associated functionality. Servers SHOULD recognize all the names of associated functionality. Servers SHOULD recognize all the names of
object classes defined in Section 7 of [Schema]. object classes defined in Section 7 of [Schema].
Servers MUST ensure that entries conform to user and system schema Servers MUST ensure that entries conform to user and system schema
rules or other data model constraints. rules or other data model constraints.
Servers MAY support DIT Content Rules, DIT Structural Rules, and/or Servers MAY support DIT Content Rules, DIT Structural Rules, and/or
Name Forms features. To indicate support, servers SHOULD provide in Name Forms features.
the subschema the definitions of attribute types associated with the
features they support.
Servers MAY support alias entries. To indicate support for alias Servers MAY support alias entries.
entries, servers SHOULD provide definitions for 'alias' and
'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 subentries SHOULD use with [X.501]. Servers which do not support subentries SHOULD use
object entries to mimic subentries as detailed in Section 3.2. object entries to mimic subentries as detailed in Section 3.2.
Servers MAY support the 'extensibleObject' object class. To indicate Servers MAY support the 'extensibleObject' object class.
support for 'extensibleObject', servers SHOULD provide the
'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.
7.2 Client Guidelines 7.2 Client Guidelines
Clients MUST NOT display nor attempt to decode as ASN.1, a value if Clients MUST NOT display nor attempt to decode as ASN.1, a value if
its syntax is not known. The implementation may attempt to discover its syntax is not known. The implementation may attempt to discover
the subschema of the source entry, and retrieve the values of the subschema of the source entry, and retrieve the values of
skipping to change at page 40, line 48 skipping to change at page 41, line 27
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
in progress. in progress.
[Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation [Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation
of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a
work in progress. work in progress.
[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] S. Legg (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.
[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,
skipping to change at page 42, line 7 skipping to change at page 42, line 30
Section 3.2 of RFC 2251 provided a brief introduction to the X.500 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 data model, as used by LDAP. The previous specification relied on
[X.501] but lacked clarity in how X.500 models are adapted for use by [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 LDAP. This document describes the X.500 data models, as used by LDAP
in greater detail, especially in areas where the models require in greater detail, especially in areas where the models require
adaptation is needed. adaptation is needed.
Section 3.2.1 of RFC 2251 described an attribute as "a type with one Section 3.2.1 of RFC 2251 described an attribute as "a type with one
or more associated values." In LDAP, an attribute is better described or more associated values." In LDAP, an attribute is better described
as an attribute description, a type with zero or options, and one or as an attribute description, a type with zero or more options, and one
more associated values. or more associated values.
Section 3.2.2 of RFC 2251 mandated that subschema subentries contain Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
objectClasses and attributeTypes attributes, yet X.500(93) treats objectClasses and attributeTypes attributes, yet X.500(93) treats
these attributes as optional. While generally all implementations these attributes as optional. While generally all implementations
support X.500(93) subschema mechanisms will provide both of these that support X.500(93) subschema mechanisms will provide both of these
attributes, it is not absolutely required for interoperability that attributes, it is not absolutely required for interoperability that
all servers do. The mandate was removed for consistency with all servers do. The mandate was removed for consistency with
X.500(93). The subschema discovery mechanism was also clarified to X.500(93). The subschema discovery mechanism was also clarified to
indicate that subschema controlling an entry is obtained by reading indicate that subschema controlling an entry is obtained by reading
the (sub)entry referred to by that entry's 'subschemaSubentry' the (sub)entry referred to by that entry's 'subschemaSubentry'
attribute. attribute.
A.1.2 Section 3.4 of RFC 2251 A.1.2 Section 3.4 of RFC 2251
Section 3.4 of RFC 2251 provided "Server-specific Data Requirements". Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
skipping to change at page 44, line 6 skipping to change at page 44, line 28
characters to appear to be consistent its natural language characters to appear to be consistent its natural language
specification "descr is the syntactic representation of an object specification "descr is the syntactic representation of an object
descriptor, which consists of letters and digits, starting with a descriptor, which consists of letters and digits, starting with a
letter." In a related change, the statement "an letter." In a related change, the statement "an
AttributeDescription can be used as the value in a NAME part of an AttributeDescription can be used as the value in a NAME part of an
AttributeTypeDescription" was deleted. RFC 2252 provided no AttributeTypeDescription" was deleted. RFC 2252 provided no
specification as to the semantics of attribute options appearing in specification as to the semantics of attribute options appearing in
NAME fields. NAME fields.
The ABNF for a quoted string (qdstring) was updated to reflect The ABNF for a quoted string (qdstring) was updated to reflect
support for the eescaping mechanism described in 4.3 of RFC 2252. support for the escaping mechanism described in 4.3 of RFC 2252.
A.2.2 Section 5 of RFC 2252 A.2.2 Section 5 of RFC 2252
Definitions of operational attributes provided in Section 5 of RFC Definitions of operational attributes provided in Section 5 of RFC
2252 where incorporated into this document. 2252 where incorporated into this document.
The 'supportedExtension' description was clarified. A server need The 'supportedExtension' description was clarified. A server need
only list the OBJECT IDENTIFIERs associated with the extended only list the OBJECT IDENTIFIERs associated with the extended
requests of the extended operations it recognizes. requests of the extended operations it recognizes.
 End of changes. 

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