draft-ietf-ldapbis-models-05.txt   draft-ietf-ldapbis-models-06.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 10 December 2002 Expires in six months 16 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-05.txt> <draft-ietf-ldapbis-models-06.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 23 skipping to change at page 2, line 23
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 8
2.4. Object Classes 2.4. Object Classes
2.5. Attribute Descriptions 11 2.5. Attribute Descriptions 11
2.6. Alias Entries 15 2.6. Alias Entries 15
3. Directory Administrative and Operational Information 16 3. Directory Administrative and Operational Information 16
3.1. Subtrees 3.1. Subtrees
3.2. Subentries 3.2. Subentries 17
3.3. The 'objectClass' attribute 17 3.3. The 'objectClass' attribute
3.4. Operational attributes 18 3.4. Operational attributes 18
4. Directory Schema 20 4. Directory Schema 20
4.1. Schema Definitions 21 4.1. Schema Definitions 21
4.2. Subschema Subentries 30 4.2. Subschema Subentries 30
4.3. 'extensibleObject' 33 4.3. 'extensibleObject' 34
4.4. Subschema Discovery 34 4.4. Subschema Discovery
5. DSA (Server) Informational Model 5. DSA (Server) Informational Model
5.1. Server-specific Data Requirements 5.1. Server-specific Data Requirements 35
6. Other Considerations 38 6. Other Considerations 38
6.1. Preservation of User Information 6.1. Preservation of User Information
6.2. Short Names 6.2. Short Names
6.3. Cache and Shadowing 39 6.3. Cache and Shadowing 39
7. Implementation Guidelines 7. Implementation Guidelines 40
7.1. Server Guidelines 7.1. Server Guidelines
7.2. Client Guidelines 40 7.2. Client Guidelines
8. Security Considerations 8. Security Considerations 41
9. IANA Considerations 9. IANA Considerations
10. Acknowledgments 41 10. Acknowledgments 42
11. Author's Address 11. Author's Address
12. References 12. References
12.1. Normative References 12.1. Normative References
12.2. Informative References 43 12.2. Informative References 43
Appendix A. Changes Appendix A. Changes
A.1 Changes to RFC 2251 A.1 Changes to RFC 2251 44
A.2 Changes to RFC 2252 45 A.2 Changes to RFC 2252 46
A.3 Changes to RFC 2256 46 A.3 Changes to RFC 2256 47
Copyright Copyright
1. Introduction 1. Introduction
This document discusses the X.500 Directory Information Models This document discusses the X.500 Directory Information Models
[X.501], as used by the Lightweight Directory Access Protocol (LDAP) [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
[Roadmap]. [Roadmap].
The Directory is "a collection of open systems cooperating to provide The Directory is "a collection of open systems cooperating to provide
directory services" [X.500]. The information held in the Directory is directory services" [X.500]. The information held in the Directory is
skipping to change at page 7, line 38 skipping to change at page 7, line 38
An entry's relative distinguished name must be unique among all An entry's relative distinguished name must be unique among all
immediate subordinates of the entry's immediate superior (i.e., all immediate subordinates of the entry's immediate superior (i.e., all
siblings). siblings).
The following are example string representations of RDNs [LDAPDN]: The following are example string representations of RDNs [LDAPDN]:
UID=12345 UID=12345
OU=Engineering OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores CN=Kurt Zeilenga+L=Redwood Shores
The last is an example of a multi-valued RDN. The last is an example of a multi-valued RDN. That is, an RDN
composed of multiple AVAs.
2.2.2. Distinguished Names 2.2.2. Distinguished Names
An entry's fully qualified name, known as its Distinguished Name (DN) An entry's fully qualified name, known as its Distinguished Name (DN)
[X.501], is the concatenation of its RDN and its immediate superior's [X.501], is the concatenation of its RDN and its immediate superior's
DN. A Distinguished Name unambiguously refers to an entry in the DN. A Distinguished Name unambiguously refers to an entry in the
tree. The following are example string representations of DNs tree. The following are example string representations of DNs
[LDAPDN]: [LDAPDN]:
UID=nobody@example.com,DC=example,DC=com UID=nobody@example.com,DC=example,DC=com
skipping to change at page 13, line 23 skipping to change at page 13, line 28
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 BCP 64 [RFC3383]. 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 any number of tagging options. Tagging options are never mutually
exclusive. exclusive.
An attribute description with N tagging options is considered a direct An attribute description with N tagging options is considered 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
type has a supertype, then the attribute description is also type has a supertype, then the attribute description is also
considered a direct (description) subtype of the attribute description considered a direct (description) subtype of the attribute description
of the supertype and the N tagging options. That is, of the supertype and the N tagging options. That is,
'cn;lang-de;lang-en' is considered a direct subtype of 'cn;lang-de', 'cn;lang-de;lang-en' is considered a direct subtype of 'cn;lang-de',
'cn;lang-en', and 'name;lang-de;lang-en' ('cn' is a subtype of 'name', 'cn;lang-en', and 'name;lang-de;lang-en' ('cn' is a subtype of 'name',
skipping to change at page 22, line 38 skipping to change at page 22, line 44
terms. terms.
The NAME field provides a set of short names (descriptors) which are The NAME field provides a set of short names (descriptors) which are
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.
The OBSOLETE field, if present, indicates the element is not active.
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 <space> and <qdstrings> tokens. MUST be followed by <SP> 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 = LPAREN WSP ObjectClassDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
skipping to change at page 23, line 46 skipping to change at page 24, line 7
[ 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" / ; user
"directoryOperation" / ; directory operational "directoryOperation" / ; directory operational
"distributedOperation" / ; DSA-shared operational "distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operational "dSAOperation" ; DSA-specific operational
where: where:
<numericoid> is object identifier assigned to this attribute type; <numericoid> is object identifier assigned to this attribute type;
NAME <qdescrs> are short names (descriptors) identifying this NAME <qdescrs> are short names (descriptors) identifying this
attribute type; attribute type;
DESC <qdstring> is a short descriptive string; DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this attribute type is not active; OBSOLETE indicates this attribute type is not active;
SUP oid specifies the direct supertype of this type; SUP oid specifies the direct supertype of this type;
EQUALITY, ORDERING, SUBSTRING provide the oid of the equality, EQUALITY, ORDERING, 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 may suggest SYNTAX identifies value syntax by object identifier and may suggest
skipping to change at page 24, line 47 skipping to change at page 25, line 8
a directory operational attribute. distributedOperation usage a directory operational attribute. distributedOperation usage
indicates that the attribute of this DSA-shared usage operational indicates that the attribute of this DSA-shared usage operational
attribute. dSAOperation usage indicates that the attribute of this attribute. dSAOperation usage indicates that the attribute of this
type is a DSA-specific operational attribute. type is a DSA-specific operational attribute.
NO-USER-MODIFICATION requires an operational usage. NO-USER-MODIFICATION requires an operational usage.
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.4.
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 minimum 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
skipping to change at page 25, line 38 skipping to change at page 25, line 47
Each matching rule is identified by an object identifier (OID) and, Each matching rule is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors). optionally, one or more short names (descriptors).
Matching rule definitions are written according to the ABNF: Matching rule definitions are written according to the ABNF:
MatchingRuleDescription = LPAREN WSP MatchingRuleDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active [ SP "OBSOLETE" ] ; not active
SP "SYNTAX" SP numericoid ; oid corrected to numericoid SP "SYNTAX" SP numericoid ; assertion syntax
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 (descriptors) identifying this NAME <qdescrs> are short names (descriptors) identifying this
matching rule; matching rule;
DESC <qdstring> is a short descriptive string; 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.
4.1.4. Matching Rule Uses
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 are written according to the following
according to the following ABNF: ABNF:
MatchingRuleUseDescription = LPAREN WSP MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifier numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description [ SP "DESC" SP qdstring ] ; description
[ 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 (descriptors) identifying this NAME <qdescrs> are short names (descriptors) identifying this
matching rule use; matching rule use;
DESC <qdstring> is a short descriptive string; 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.5. 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
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).
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 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 short 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.6. 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].
For DIT entries of a particular structural object class, a DIT content For DIT entries of a particular structural object class, a DIT content
rule specifies which auxiliary object classes the entries are allowed rule specifies which auxiliary object classes the entries are allowed
to belong to and which additional attributes (by type) are required, to belong to and which additional attributes (by type) are required,
allowed or not allowed to appear in the entries. 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
skipping to change at page 28, line 22 skipping to change at page 28, line 33
content rule; content rule;
DESC <qdstring> is a short descriptive string; 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 Structure Rules and Name Forms 4.1.7. DIT Structure Rules and Name Forms
It is sometimes desirable to regulate where object entries can be It is sometimes desirable to regulate where object entries can be
placed in the DIT and how they can be named based upon their placed in the DIT and how they can be named based upon their
structural object class. structural object class.
4.1.7.1. DIT Structure Rules
A DIT structure rule is a "rule governing the structure of the DIT by A DIT structure rule is a "rule governing the structure of the DIT by
specifying a permitted superior to subordinate entry relationship. A specifying a permitted superior to subordinate entry relationship. A
structure rule relates a name form, and therefore a structural object structure rule relates a name form, and therefore a structural object
class, to superior structure rules. This permits entries of the class, to superior structure rules. This permits entries of the
structural object class identified by the name form to exist in the structural object class identified by the name form to exist in the
DIT as subordinates to entries governed by the indicated superior DIT as subordinates to entries governed by the indicated superior
structure rules" [X.501]. structure rules" [X.501].
A name form "specifies a permissible RDN for entries of a particular
structural object class. A name form identifies a named object class
and one or more attribute types to be used for naming (i.e. for the
RDN). Name forms are primitive pieces of specification used in the
definition of DIT structure rules" [X.501].
Each name form indicates the structural object class to be named, a
set of required attribute types, and a set of allowed attributes
types. A particular attribute type cannot be listed in both sets.
Entries governed by the form must be named using a value from each
required attribute type and zero or more values from the allowed
attribute types.
Each name form is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
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 (descriptors) [ 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
skipping to change at page 29, line 34 skipping to change at page 29, line 31
<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 (descriptors) identifying this DIT NAME <qdescrs> are short names (descriptors) identifying this DIT
structure rule; structure rule;
DESC <qdstring> is a short descriptive string; 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.
If no superior rules are identified, the DIT structure rule applies
to an autonomous administrative point (e.g. the root vertex of the
subtree controlled by the subschema) [X.501].
4.1.7.2. Name Forms
A name form "specifies a permissible RDN for entries of a particular
structural object class. A name form identifies a named object
class and one or more attribute types to be used for naming (i.e.
for the RDN). Name forms are primitive pieces of specification
used in the definition of DIT structure rules" [X.501].
Each name form indicates the structural object class to be named,
a set of required attribute types, and a set of allowed attributes
types. A particular attribute type cannot be listed in both sets.
Entries governed by the form must be named using a value from each
required attribute type and zero or more values from the allowed
attribute types.
Each name form is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
Name form descriptions are written according to the ABNF: 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 (descriptors) [ 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 which identifies this name form;
NAME <qdescrs> are short names (descriptors) identifying this name NAME <qdescrs> are short names (descriptors) identifying this name
form; form;
DESC <qdstring> is a short descriptive string; 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.
All attribute types in the required ("MUST") and allowed ("MAY") lists
shall be different.
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
skipping to change at page 38, line 25 skipping to change at page 38, line 48
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. And where a server is unable (or unwilling) to different form. And where a server is unable (or unwilling) to
preserve the value of user information, the server SHALL ensure that preserve the value of user information, the server SHALL ensure that
an 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, also known as descriptors, are used as more readable Short names, also known as descriptors, are used as more readable
aliases for object identifiers and are used to identify various schema aliases for object identifiers and are used to identify various schema
elements. elements. However, it is not expected that LDAP implementations with
human user interface would display these short names (nor the object
identifiers they refer to) to the user, but would most likely be
performing translations (such as expressing the short name in one of
the local national languages). For example, the short name "st"
(stateOrProvinceName) might be displayed to a German-speaking user as
"Land".
The same short name might have different meaning in different The same short name might have different meaning in different
subschemas and, within a particular subschema, the same short name subschemas and, within a particular subschema, the same short name
might refer to different object identifiers each identifying a might refer to different object identifiers each identifying a
different kind of schema element. different kind of schema element.
Implementations MUST be prepared that the same short name might be Implementations MUST be prepared that the same short name might be
used in a subschema to refer to the different kinds of schema 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 elements. That is, there might be an object class 'x-fubar' and an
attribute type 'x-fubar' in a subschema. attribute type 'x-fubar' in a subschema.
skipping to change at page 39, line 27 skipping to change at page 40, line 12
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
Servers MUST recognize all attribute types and object classes defined Servers MUST recognize all attribute types and object classes names
in this document but, unless stated otherwise, need not support the defined in this document but, unless stated otherwise, need not
associated functionality. Servers SHOULD recognize all the names of support the associated functionality. Servers SHOULD recognize all
attribute types and object classes defined in Section 3 and 4, the names of attribute types and object classes defined in Section 3
respectively, of [Schema]. and 4, respectively, 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 Structure Rules, and/or Servers MAY support the 'extensibleObject' object class.
Name Forms features.
Servers MAY support DIT Content Rules. Servers MAY support DIT
Structure Rules, and Name Forms.
Servers MAY support alias entries. Servers MAY support alias 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.
Servers MAY implement additional schema elements. Servers SHOULD Servers MAY implement additional schema elements. Servers SHOULD
provide the definitions of all schema elements they support in provide definitions of all schema elements they support in subschema
subschema (sub)entries. (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
'attributeTypes' from the subschema (sub)entry. 'attributeTypes' from the subschema (sub)entry.
Clients MUST NOT assume the LDAP-specific string encoding is Clients MUST NOT assume the LDAP-specific string encoding is
restricted to a UTF-8 encoded string of UCS characters or any restricted to a UTF-8 encoded string of UCS characters or any
skipping to change at page 41, line 38 skipping to change at page 42, line 22
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 RFC 2251 by M. Wahl, T. Howes, and This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
RFC 2556 by M. Wahl, all products of the IETF Access, Searching and RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
Indexing of Directories (ASID) Working Group. This document is also Indexing of Directories (ASID) Working Group. This document is also
based in part on "The Directory: Models" [X.501], a product of the based in part on "The Directory: Models" [X.501], a product of the
International Telephone Union (ITU). International Telephone Union (ITU). Additional text was borrowed
from RFC 2253 by Mark Wahl, Tim Howes, and Steve Kille.
This document is a product of the IETF LDAPBIS Working Group.
11. Author's Address 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 [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
 End of changes. 

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