draft-ietf-ldapbis-models-07.txt   draft-ietf-ldapbis-models-08.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 1 March 2003 Expires in six months 30 June 2003
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-07.txt> <draft-ietf-ldapbis-models-08.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 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>. <http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved. Please Copyright (C) The Internet Society (2003). All Rights Reserved.
see the Copyright section near the end of this document for more
information. Please see the Full Copyright section near the end of this document
for more information.
Abstract Abstract
The Lightweight Directory Access Protocol (LDAP) is an Internet The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in protocol for accessing distributed directory services which act in
accordance with X.500 data and service models. This document accordance with X.500 data and service models. This document
describes the X.500 Directory Information Models, as used in LDAP. describes the X.500 Directory Information Models, as used in LDAP.
Table of Contents Table of Contents
skipping to change at page 4, line 7 skipping to change at page 4, line 7
[Roadmap] which obsoletes the previously defined LDAP technical [Roadmap] which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety. specification, RFC 3377, in its entirety.
This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
portions of sections 4 and 6. Appendix A.1 summaries changes to these portions of sections 4 and 6. Appendix A.1 summaries changes to these
sections. The remainder of RFC 2251 is obsoleted by the [Protocol], sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
[AuthMeth], and [Roadmap] documents. [AuthMeth], and [Roadmap] documents.
This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
summaries changes to these sections. The remainder of RFC 2252 is summaries changes to these sections. The remainder of RFC 2252 is
obsoleted by [Syntaxes] and [Schema]. obsoleted by [Syntaxes].
This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2. This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
Appendix A.3 summarizes changes to these sections. The remainder of Appendix A.3 summarizes changes to these sections. The remainder of
RFC 2256 is obsoleted by [Schema] and [Syntaxes]. RFC 2256 is obsoleted by [Schema] and [Syntaxes].
1.2. Relationship to X.501 1.2. Relationship to X.501
This document includes material, with and without adaptation, from the This document includes material, with and without adaptation, from the
[X.501]. Due to the adaptation, the material included in this [X.501]. Due to the adaptation, the material included in this
document takes precedence. document takes precedence.
skipping to change at page 5, line 30 skipping to change at page 5, line 30
EQUALS = %x3D ; equals sign ("=") EQUALS = %x3D ; equals sign ("=")
RANGLE = %x3E ; right angle bracket (">") RANGLE = %x3E ; right angle bracket (">")
X = %x58 ; uppercase x ("X") X = %x58 ; uppercase x ("X")
ESC = %x5C ; backslash ("\") ESC = %x5C ; backslash ("\")
USCORE = %x5F ; underscore ("_") USCORE = %x5F ; underscore ("_")
LCURLY = %x7B ; left curly brace "{" LCURLY = %x7B ; left curly brace "{"
RCURLY = %x7D ; right curly brace "}" RCURLY = %x7D ; right curly brace "}"
; Any UTF-8 character ; Any UTF-8 character
UTF8 = UTF1 / UTFMB UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6 UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF UTF0 = %x80-BF
UTF1 = %x00-7F UTF1 = %x00-7F
UTF2 = %xC0-DF 1(UTF0) UTF2 = %xC2-DF UTF0
UTF3 = %xE0-EF 2(UTF0) UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
UTF4 = %xF0-F7 3(UTF0) %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF5 = %xF8-FB 4(UTF0) UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
UTF6 = %xFC-FD 5(UTF0) %xF4 %x80-8F 2(UTF0)
; Any octet ; Any octet
OCTET = %x00-FF OCTET = %x00-FF
Object identifiers are represented in LDAP using a dot-decimal format Object identifiers are represented in LDAP using a dot-decimal format
conforming to the ABNF: conforming to the ABNF:
numericoid = number *( DOT number ) numericoid = number *( DOT number )
Short names, also known as descriptors, are used as more readable Short names, also known as descriptors, are used as more readable
skipping to change at page 13, line 22 skipping to change at page 13, line 22
optionally, one or more short names (descriptors). optionally, one or more short names (descriptors).
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 used 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.
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 [BCP64bis].
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
any number of 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
skipping to change at page 18, line 34 skipping to change at page 18, line 34
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. That is, one cannot change a 'person' into a being changed. That is, one cannot change a 'person' into a
'country'. '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 SHALL be implicitly added as all superclasses of the named classes SHALL be implicitly added as
well if not already present. That is, if the auxiliary class 'x-a' is well if not already present. That is, if the auxiliary class 'x-a' is
a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
'x-b' to added (if is not already present). 'x-b' to be implicitly added (if is not already present).
Servers SHALL restrict modifications of this attribute to prevent a Servers SHALL restrict modifications of this attribute to prevent a
superclasses of remaining 'objectClass' values from being deleted. superclasses of remaining 'objectClass' values from being deleted.
That is, if the auxiliary class 'x-a' is a subclass of the auxiliary That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b', class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
an attempt to delete only 'x-b' from the 'objectClass' attribute is an an attempt to delete only 'x-b' from the 'objectClass' attribute is an
error. error.
3.4. Operational attributes 3.4. Operational attributes
Some attributes, termed operational attributes, are used or maintained Some attributes, termed operational attributes, are used or maintained
by servers for administrative and operational purposes. As stated in by servers for administrative and operational purposes. As stated in
[X.501]: "There are three varieties of operational attributes: [X.501]: "There are three varieties of operational attributes:
Directory operational attributes, DSA-shared operational attributes, Directory operational attributes, DSA-shared operational attributes,
and DSA-specific operational attributes." and DSA-specific operational attributes."
A directory operational attribute is used to represent operational A directory operational attribute is used to represent operational
and/or administrative information in the Directory Information Model. and/or administrative information in the Directory Information Model.
This includes operational attributes maintained by the server (e.g. This includes operational attributes maintained by the server (e.g.
'createTimeStamp') as well as operational attributes which hold values 'createTimestamp') as well as operational attributes which hold values
administrated by the user (e.g. 'ditContentRules'). administrated by the user (e.g. 'ditContentRules').
A DSA-shared operational attribute is used to represent information of A DSA-shared operational attribute is used to represent information of
the DSA Information Model. Its values, if shared between DSAs the DSA Information Model. Its values, if shared between DSAs
(servers) are identical (except during periods of transient (servers) are identical (except during periods of transient
inconsistency). inconsistency).
A DSA-specific operational attribute is used to represent information A DSA-specific operational attribute is used to represent information
of the DSA Information Model. Its values, if shared between DSAs of the DSA Information Model. Its values, if shared between DSAs
(servers), need not be identical. (servers), need not be identical.
skipping to change at page 27, line 30 skipping to change at page 27, line 30
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.5. 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 [UTF-8] form.
Each LDAP syntax is identified by an object identifier (OID). Each LDAP syntax is identified by an object identifier (OID).
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
skipping to change at page 36, line 37 skipping to change at page 36, line 37
- altServer: alternative servers; - altServer: alternative servers;
- 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 mechanisms.
The values of these attributes provided may depend on session specific The values of these attributes provided may depend on session specific
and other factors. For example, a server supporting the SASL EXTERNAL and other factors. For example, a server supporting the SASL EXTERNAL
mechanism might only list "EXTERNAL" when the client's identity has mechanism might only list "EXTERNAL" when the client's identity has
been established by a lower level. See [AuthMeth]. been 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
skipping to change at page 37, line 47 skipping to change at page 37, line 47
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 [BCP64bis].
( 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 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation ) 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'
skipping to change at page 38, line 24 skipping to change at page 38, line 24
server does not support any extended operations, this attribute will server does not support any extended operations, this attribute will
be absent. be absent.
An extended operation comprises a ExtendedRequest, possibly other PDUs An extended operation comprises a ExtendedRequest, possibly other PDUs
defined by extension, and an ExtendedResponse [Protocol]. The object defined by extension, and an ExtendedResponse [Protocol]. The object
identifier assigned to the ExtendedRequest is used to identify the identifier assigned to the ExtendedRequest is used to identify the
extended operation. Other object identifiers associated with the extended operation. Other object identifiers associated with the
extended operation need not be listed. extended operation need not be listed.
Procedures for registering object identifiers used to discovery of Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in BCP 64 [RFC3383]. protocol mechanisms are detailed in BCP 64 [BCP64bis].
( 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 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation ) 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'
skipping to change at page 40, line 12 skipping to change at page 40, line 12
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.
Implementations MUST be prepared that the same short name might be Implementations MUST be prepared that the same short name might be
used in the different subschemas to refer to the different schema used in the different subschemas to refer to the different schema
elements. That is, there might be two matching rules 'x-fubar', each elements. That is, there might be two matching rules 'x-fubar', each
in different subschemas. in different subschemas.
Procedures for registering short names (descriptors) are detailed in Procedures for registering short names (descriptors) are detailed in
BCP 64 [RFC3383bis]. BCP 64 [BCP64bis].
[[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 elements 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 43, line 4 skipping to change at page 42, line 32
objectClasses A 2.5.21.6 objectClasses A 2.5.21.6
subschema O 2.5.20.1 subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10 subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13 supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7 supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15 supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14 supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0 top O 2.5.6.0
10. Acknowledgments 10. Acknowledgments
This document is based in part on 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). Additional text was borrowed International Telephone Union (ITU). Additional text was borrowed
from RFC 2253 by Mark Wahl, Tim Howes, and Steve Kille. from RFC 2253 by Mark Wahl, Tim Howes, and Steve Kille.
This document is a product of the IETF LDAPBIS Working Group. This document is a product of the IETF LDAP Revison (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", [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
RFC 2279, January 1998.
[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 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
RFC 3383), September 2002. ietf-ldapbis-bcp64-xx.txt, a work in progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress. progress.
[Protocol] J. Sermersheim (editor), "LDAP: The Protocol", [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress. draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms", Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
in progress.
[Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation
of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a
work in progress. work in progress.
[LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator", [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
Representation of Search Filters",
draft-ietf-ldapbis-filter-xx.txt, a work in progress.
[LDAPURL] Smith, M. (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] S. Legg (editor), "LDAP: Syntaxes", [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
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] Dally, K. (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) - [UTF-8] Yergeau, F., "UTF-8, a transformation
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 format of ISO 10646", draft-yergeau-rfc2279bis, a work
: 1993. in progress.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, [ISO10646] International Organization for Standardization,
Models and Service", 1993. "Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane", ISO/IEC
10646-1 : 1993.
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. [X.500] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Overview of concepts, models and services,"
X.500(1993) (also ISO/IEC 9594-1:1994).
[X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - [X.501] International Telecommunication Union -
Specification of Basic Notation", 1994. Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
12.2. Informative References 12.2. Informative References
None. None.
Appendix A. Changes Appendix A. Changes
This appendix is non-normative. This appendix is non-normative.
This document amounts to nearly a complete rewrite of portions of RFC This document amounts to nearly a complete rewrite of portions of RFC
skipping to change at page 45, line 39 skipping to change at page 45, line 32
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".
This material, with changes, was incorporated in Section 5.1 of this This material, with changes, was incorporated in Section 5.1 of this
document. document.
Changes: Changes:
- Clarify that attributes of the root DSE are subject to "other - Clarify that attributes of the root DSE are subject to "other
restrictions" in addition to acccess controls. restrictions" in addition to access controls.
- Clarify that only recognized extended requests need to be enumerated - Clarify that only recognized extended requests need to be enumerated
'supportedExtension'. 'supportedExtension'.
- Clarify that only recognized request controls need to be enumerated - Clarify that only recognized request controls need to be enumerated
'supportedControl'. 'supportedControl'.
- Clarify that root DSE attributes are operational and, like other - Clarify that root DSE attributes are operational and, like other
operational attributes, will not be returned in search requests operational attributes, will not be returned in search requests
unless requested by name. unless requested by name.
skipping to change at page 48, line 28 skipping to change at page 48, line 24
'aliasedObjectName' attribute type. This was integrated into 'aliasedObjectName' attribute type. This was integrated into
Section 2.6.2 of this document. Section 2.6.2 of this document.
Section 7.1 of RFC 2256 provided the definition of the 'top' object Section 7.1 of RFC 2256 provided the definition of the 'top' object
class. This was integrated into Section 2.4.1 of this document. class. This was integrated into Section 2.4.1 of this document.
Section 7.2 of RFC 2256 provided the definition of the 'alias' Section 7.2 of RFC 2256 provided the definition of the 'alias'
object class. This was integrated into Section 2.6.1 of this object class. This was integrated into Section 2.6.1 of this
document. document.
Copyright 2003, The Internet Society. All Rights Reserved. Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such proprietary
rights by implementors or users of this specification can be obtained
from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed, copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English. or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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