upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-12-24 16:49:39 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Suck in latest I-D revisions

Browse source
This commit is contained in:
Kurt Zeilenga 2003-12-07 07:50:23 +00:00
parent e96063d9e8
commit 43ffeda85d
20 changed files with 6775 additions and 9196 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2058
doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt
View file

File diff suppressed because it is too large Load diff

362
doc/drafts/draft-ietf-ldapbis-dn-xx.txt
View file

@ -6,12 +6,14 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 4 May 2003
Expires in six months 27 October 2003
Obsoletes: 2253
LDAP: String Representation of Distinguished Names
<draft-ietf-ldapbis-dn-10.txt>
<draft-ietf-ldapbis-dn-12.txt>
Status of Memo
@ -23,7 +25,7 @@ Status of Memo
revision, submitted to the RFC Editor as a Standard Track document
replacing RFC 2253. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF LDAP
Revision (LDAPbis) Working Group mailing list
Revision (LDAPBIS) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the document editor <Kurt@OpenLDAP.org>.
@ -40,10 +42,22 @@ Status of Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please 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.
Zeilenga LDAP: Distinguished Names [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
Abstract
@ -52,14 +66,6 @@ Abstract
entries in the directory. This document defines the string
representation used in the Lightweight Directory Access Protocol
(LDAP) to transfer distinguished names. The string representation is
Zeilenga LDAP: Distinguished Names [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
designed to give a clean representation of commonly used distinguished
names, while being able to represent any distinguished name.
@ -75,13 +81,14 @@ Conventions
In X.500-based directory systems [X.500], including those accessed
using the Lightweight Directory Access Protocol (LDAP) [Roadmap],
distinguished names (DNs) are used to unambiguously refer to a
directory entry [X.501][Models].
distinguished names (DNs) are used to unambiguously refer to directory
entries [X.501][Models].
The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
directory protocols), DNs are encoded using the Basic Encoding Rules
(BER) [X.690]. In LDAP, DNs are represented in string form.
(BER) [X.690]. In LDAP, DNs are represented in the string form
described in this document.
It is important to have a common format to be able to unambiguously
represent a distinguished name. The primary goal of this
@ -89,8 +96,8 @@ Conventions
to have names that are human readable. It is not expected that LDAP
implementations with a human user interface would display these
strings directly to the user, but would most likely be performing
translations (such as expressing attribute type names in one of the
local national languages).
translations (such as expressing attribute type names in the local
national language).
This document defines the string representation of Distinguished Names
used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
@ -102,6 +109,13 @@ Conventions
from its ASN.1 structured representation to a string, all algorithms
MUST produce strings which adhere to the requirements of Section 3.
Zeilenga LDAP: Distinguished Names [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
This document does not define a canonical string representation for
DNs. Comparison of DNs for equality is to be performed in accordance
with the distinguishedNameMatch matching rule [Syntaxes].
@ -109,13 +123,6 @@ Conventions
This document is an integral part of the LDAP Technical Specification
[Roadmap].
Zeilenga LDAP: Distinguished Names [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
This document obsoletes RFC 2253. Changes since RFC 2253 are
summarized in Appendix B.
@ -141,7 +148,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
This section defines the RECOMMENDED algorithm for converting a
distinguished name from an ASN.1 structured representation to an UTF-8
[RFC2279] encoded Universal Character Set (UCS) [ISO10646] character
[UTF-8] encoded Universal Character Set (UCS) [ISO10646] character
string representation. Other documents may describe other algorithms
for converting a distinguished name to a string, but only strings
which conform to the grammar defined in Section 3 MUST be produced by
@ -158,20 +165,19 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
2.2), starting with the last element of the sequence and moving
backwards toward the first.
Zeilenga LDAP: Distinguished Names [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
The encodings of adjoining RelativeDistinguishedNames are separated by
a comma ("," U+002C) character.
2.2. Converting RelativeDistinguishedName
Zeilenga LDAP: Distinguished Names [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
When converting from an ASN.1 RelativeDistinguishedName to a string,
the output consists of the string encodings of each
AttributeTypeAndValue (according to Section 2.3), in any order.
@ -189,14 +195,14 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
encoding of the AttributeValue is given in Section 2.4.
If the AttributeType is defined to have a short name and that short
name is known to be registered [REGISTRY] as identifying the
name is known to be registered [REGISTRY][BCP64bis] as identifying the
AttributeType, that short name, a <descr>, is used. Otherwise the
AttributeType is encoded as the dotted-decimal encoding, a
<numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid>
is defined in [Models].
Implementations are not expected dynamically update their knowledge of
registered short names. However, implementations SHOULD provide a
Implementations are not expected to dynamically update their knowledge
of registered short names. However, implementations SHOULD provide a
mechanism to allow its knowledge of registered short names to be
updated.
@ -214,20 +220,20 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
desired (see Section 5.2).
Otherwise, if the AttributeValue is of a syntax which has a native
string encoding, the value is converted first to a UTF-8 encoded UCS
string according to its syntax specification (see for example Section
6 of [Syntaxes]). If that UTF-8 encoded UCS string does not have any
of the following characters which need escaping, then that string can
be used as the string representation of the value.
Zeilenga LDAP: Distinguished Names [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
string encoding, the value is converted first to a UTF-8 encoded UCS
string according to its syntax specification (see for example Section
6 of [Syntaxes]). If that UTF-8 encoded UCS string does not have any
of the following characters which need escaping, then that string can
be used as the string representation of the value.
- a space (" " U+0020) or number sign ("#" U+0023) occurring at
the beginning of the string;
@ -259,7 +265,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
3. Parsing a String back to a Distinguished Name
The string representation of Distinguished Names is restricted to
UTF-8 [RFC2279] encoded characters from the Universal Character Set
UTF-8 [UTF-8] encoded characters from the Universal Character Set
(UCS) [ISO10646]. The structure of this string representation is
specified using the following Augmented BNF [RFC2234] grammar:
@ -271,19 +277,18 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
attributeTypeAndValue = attributeType EQUALS attributeValue
Zeilenga LDAP: Distinguished Names [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
attributeType = descr / numericoid
attributeValue = string / hexstring
; The UTF-8 string shall not contain NULL, ESC, or
Zeilenga LDAP: Distinguished Names [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
; one of escaped, shall not start with SHARP or SPACE,
; and shall must not end with SPACE.
string = [ (leadchar / pair)
@ -327,19 +332,19 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
replace <ESC><special> with <special>;
replace <ESC><hexpair> with the octet indicated by the <hexpair>.
If in <hexstring> form, a BER representation can be obtained from
converting each <hexpair> of the <hexstring> to the octet indicated by
the <hexpair>.
One or more attribute values assertions, separated by <PLUS>, for a
Zeilenga LDAP: Distinguished Names [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
If in <hexstring> form, a BER representation can be obtained from
converting each <hexpair> of the <hexstring> to the octet indicated by
the <hexpair>.
One or more attribute values assertions, separated by <PLUS>, for a
relative distinguished name.
Zero or more relative distinguished names, separated by <COMMA>, for a
@ -383,19 +388,19 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
OU=Sales+CN=J. Smith,DC=example,DC=net
This example shows the method of escaping of a comma in a common
name:
CN=John Smith\, III,DC=example,DC=net
An example name in which a value contains a carriage return
Zeilenga LDAP: Distinguished Names [Page 7]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
name:
CN=John Smith\, III,DC=example,DC=net
An example name in which a value contains a carriage return
character:
CN=Before\0dAfter,DC=example,DC=net
@ -439,17 +444,19 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
- the common name of the object (i.e. a person's full name)
- an email or TCP/IP address
- its physical location (country, locality, city, street address)
- organizational attributes (such as department name or affiliation)
Most countries have privacy laws regarding the publication of
information about people.
Zeilenga LDAP: Distinguished Names [Page 8]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
- its physical location (country, locality, city, street address)
- organizational attributes (such as department name or affiliation)
Most countries have privacy laws regarding the publication of
information about people.
5.2. Use of Distinguished Names in Security Applications
@ -491,79 +498,97 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
8. Normative References
[X.501] "The Directory -- Models," ITU-T Rec. X.501(1993).
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119).
[RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
Zeilenga LDAP: Distinguished Names [Page 9]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
Specifications: ABNF", RFC 2234, November 1997.
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[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).
[Models] K. Zeilenga (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", draft-yergeau-rfc2279bis-xx.txt, a work in
progress.
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[Schema] K. Dally (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC
10646-1 : 1993.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[ISO10646] International Organization for Standardization,
"Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane", ISO/IEC
10646-1 : 1993.
[REGISTRY] IANA, Object Identifier Descriptors Registry,
<http://www.iana.org/...>.
9. Informative References
[X.500] "The Directory -- overview of concepts, models and
services," ITU-T Rec. X.500(1993).
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", X.690,
1994.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[RFC2849] G. Good, "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000.
Appendix A. Presentation Issues
This appendix is provided for informational purposes only, it is not a
normative part of this specification.
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
Zeilenga LDAP: Distinguished Names [Page 10]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
[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.690] International Telecommunication Union -
Telecommunication Standardization Sector, "Specification
of ASN.1 encoding rules: Basic Encoding Rules (BER),
Canonical Encoding Rules (CER), and Distinguished
Encoding Rules (DER)", X.690(1997) (also ISO/IEC
8825-1:1998).
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
ietf-ldapbis-bcp64-xx.txt, a work in progress.
Appendix A. Presentation Issues
This appendix is provided for informational purposes only, it is not a
normative part of this specification.
The string representation described in this document is not intended
to be presented to humans without translation. However, at times it
may be desirable to present non-translated DN strings to users. This
@ -587,6 +612,14 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
demonstrated in the final example of Section 4).
When a DN string is displayed in free form text, it is often necessary
Zeilenga LDAP: Distinguished Names [Page 11]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
to distinguish the DN string from surrounding text. While this is
often done with white space (as demonstrated in Section 4), it is
noted that DN strings may end with white space. Careful readers of
@ -612,14 +645,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
so it has been line-wrapped for readability. The extra white
space is to be removed before the DN string is used in LDAP.
Zeilenga LDAP: Distinguished Names [Page 11]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
It is not advised to insert white space otherwise as it may not be
obvious to the user which white space is part of the DN string and
which white space was added for readability.
@ -642,18 +667,27 @@ Appendix B. Changes made since RFC 2253
The following substantive changes were made to RFC 2253:
- Removed IESG Note. The IESG Note has been addressed.
- Clarified (in Section 1), that this document does not define a
- Clarified (in Section 1) that this document does not define a
Zeilenga LDAP: Distinguished Names [Page 12]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
canonical string representation.
- Revised specification (in Section 2) to allow short names of any
registered attribute type to appear in string representations of
DNs instead of being restricted to a "published table". Remove
"as an example" language. Added statement (in Section 3) allowing
recognition of additional names but require recognization of those
names in the published table. The table is now published in
Section 3.
- Replaced specification of additional requirements for LDAPv2
implementations which also support LDAPv3 (RFC 2253, Section 4)
with a statement (in Section 3) allowing recognition of
alternative string representations.
- Clarified (in Section 2.3) that the "published" table of names
which may be appear in DNs is the table which Section 2.3
provides. Remove "as an example" language. Noted this table is
not extensible. Added statement (in Section 3) allowing
recognition of additional names. Added security considerations
(Section 5.3) regarding the use of other names.
- Updated Section 2.3 to indicate attribute type name strings are
case insensitive.
- Updated Section 2.4 to allow hex pair escaping of all characters
@ -669,21 +703,48 @@ Appendix B. Changes made since RFC 2253
- Added discussion of presentation issues (Appendix A).
- Added this appendix.
Zeilenga LDAP: Distinguished Names [Page 12]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
In addition, numerous editorial changes were made.
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
Zeilenga LDAP: Distinguished Names [Page 13]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
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
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,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
@ -694,15 +755,6 @@ Copyright 2003, The Internet Society. All Rights Reserved.
copyrights defined in the Internet Standards process must be followed,
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.
@ -727,5 +779,9 @@ Copyright 2003, The Internet Society. All Rights Reserved.
Zeilenga LDAP: Distinguished Names [Page 13]
Zeilenga LDAP: Distinguished Names [Page 14]

268
doc/drafts/draft-ietf-ldapbis-filter-xx.txt
View file

@ -7,12 +7,12 @@
Network Working Group M. Smith, Editor
Request for Comments: DRAFT Netscape Communications Corp.
Obsoletes: RFC 2254 T. Howes
Expires: 28 August 2003 Opsware, Inc.
28 February 2003
Expires: 25 April 2004 Opsware, Inc.
25 October 2003
LDAP: String Representation of Search Filters
<draft-ietf-ldapbis-filter-04.txt>
<draft-ietf-ldapbis-filter-05.txt>
@ -57,7 +57,7 @@ Expires: 28 August 2003 Opsware, Inc.
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
3. Table of Contents
@ -72,15 +72,16 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
8. Security Considerations........................................7
9. Normative References...........................................7
10. Informative References.........................................8
11. Acknowledgments................................................8
12. Authors' Address...............................................8
13. Full Copyright Statement.......................................9
14. Appendix A: Changes Since RFC 2254.............................9
14.1. Technical Changes...........................................9
14.2. Editorial Changes...........................................10
15. Appendix B: Changes Since Previous Document Revision...........11
15.1. Technical Changes...........................................11
15.2. Editorial Changes...........................................11
11. Intellectual Property Rights...................................8
12. Acknowledgments................................................8
13. Authors' Address...............................................8
14. Full Copyright Statement.......................................9
15. Appendix A: Changes Since RFC 2254.............................9
15.1. Technical Changes...........................................10
15.2. Editorial Changes...........................................10
16. Appendix B: Changes Since Previous Document Revision...........11
16.1. Technical Changes...........................................12
16.2. Editorial Changes...........................................12
4. Introduction
@ -110,10 +111,9 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
Smith & Howes Intended Category: Standards Track [Page 2]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
Filter ::= CHOICE {
@ -160,7 +160,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- ISO 10646 characters
where the LDAPString above is limited to the UTF-8 encoding [RFC2279]
where the LDAPString above is limited to the UTF-8 encoding [UTF-8]
of the ISO 10646 character set [ISO10646]. The AttributeDescription
is a string representation of the attribute description and is
defined in [Protocol]. The AttributeValue and AssertionValue OCTET
@ -169,7 +169,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
STRING have the form defined in [Syntaxes]. The Filter is encoded
@ -201,10 +201,10 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
extensible = attr [dnattrs] [matchingrule] COLON EQUALS assertionvalue
/ [dnattrs] matchingrule COLON EQUALS assertionvalue
/ COLON EQUALS assertionvalue
present = attr EQUALS ASTERIX
present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
any = ASTERIX *(assertionvalue ASTERIX)
any = ASTERISK *(assertionvalue ASTERISK)
final = assertionvalue
attr = attributedescription
; The attributedescription rule is defined in
@ -219,18 +219,18 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
; RPAREN, ASTERIX, and ESC.
; RPAREN, ASTERISK, and ESC.
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
EXCLAMATION = %x21 ; exclamation mark ("!")
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
ASTERIX = %x2A ; asterix ("*")
ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
TILDE = %x7E ; tilde ("~")
@ -264,11 +264,11 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
As indicated by the valueencoding rule, implementations MUST escape
all octets greater than 0x7F that are not part of a valid UTF-8
encoding sequence when they generate a string representation of a
search filter. Since RFC 2254 does not clearly define the term
"string representation" (and in particular does mention that the
string representation of an LDAP search filter is a string of UTF-8
encoded ISO 10646-1 characters) implementations SHOULD accept as
input strings that include invalid UTF-8 octet sequences.
search filter. Implementations SHOULD accept as input a string that
includes invalid UTF-8 octet sequences. This is necessary because RFC
2254 did not clearly define the term "string representation" (and in
particular did not mention that the string representation of an LDAP
search filter is a string of UTF-8 encoded ISO 10646-1 characters).
7. Examples
@ -281,7 +281,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
(!(cn=Tim Howes))
@ -297,7 +297,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
(o:dn:=Ace Industry)
(:1.2.3:=Wilma Flintstone)
(:dn:2.4.6.8.10:=Dino)
(:=Fred Flintstone)
The first example shows use of the matching rule "1.2.3.4.5".
@ -316,13 +315,10 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
The fifth example is a filter that should be applied to any attribute
supporting the matching rule given (since the attr has been omitted).
The sixth example is also a filter that should be applied to any
attribute supporting the matching rule given. Attributes supporting
the matching rule contained in the DN should also be considered.
The seventh and final example is a filter that should be applied to
any attribute (since both the attr and matching rule have been
omitted).
The sixth and final example is also a filter that should be applied
to any attribute supporting the matching rule given. Attributes
supporting the matching rule contained in the DN should also be
considered.
The following examples illustrate the use of the escaping mechanism.
@ -333,16 +329,17 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
(sn=Lu\c4\8di\c4\87)
(1.3.6.1.4.1.1466.0=\04\02\48\69)
The first example shows the use of the escaping mechanism to
represent parenthesis characters. The second shows how to represent a
"*" in an assertion value, preventing it from being interpreted as a
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
The first example shows the use of the escaping mechanism to
represent parenthesis characters. The second shows how to represent a
"*" in an assertion value, preventing it from being interpreted as a
substring indicator. The third illustrates the escaping of the
backslash character.
@ -388,33 +385,53 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[Syntaxes] Dally, K. (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
syntaxes-xx.txt, a work in progress.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
draft-yergeau-rfc2279bis-xx.txt, a work in progress.
10. Informative References
None.
11. Intellectual Property Rights
11. Acknowledgments
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.
12. Acknowledgments
This document replaces RFC 2254 by Tim Howes. Changes included in
this revised specification are based upon discussions among the
@ -424,15 +441,23 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
acknowledged.
12. Authors' Address
13. Authors' Address
Mark Smith, Editor
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
Netscape Communications Corp.
360 W. Caribbean Drive
Sunnyvale, CA 94089
USA
+1 650 937-3477
mcs@netscape.com
MarkCSmithWork@aol.com
Tim Howes
Opsware, Inc.
@ -442,19 +467,9 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+1 408 744-7509
howes@opsware.com
14. Full Copyright Statement
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
13. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
@ -481,9 +496,19 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Appendix A: Changes Since RFC 2254
15. Appendix A: Changes Since RFC 2254
14.1. Technical Changes
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
15.1. Technical Changes
The following technical changes were made to the contents of the
"String Search Filter Definition" section:
@ -501,13 +526,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
precisely reference productions from the [Models] and [Protocol]
documents.
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
Introduced the "valueencoding" and associated "normal" and "escaped"
rules to reduce the dependence on descriptive text. The "normal"
production restricts filter strings to valid UTF-8 sequences.
@ -519,7 +537,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
of a clear definition of "string representation."
14.2. Editorial Changes
15.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
@ -529,14 +547,23 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
Header and "Authors' Addresses" sections: added Mark Smith as the
document editor and updated affiliation and contact information.
"Table of Contents" section: added.
"Table of Contents" and "Intellectual Property Rights" sections:
added.
Copyright: updated the year.
Copyright: updated per latest IETF guidelines.
"Abstract" section: separated from introductory material.
"Introduction" section: new section; separated from the Abstract.
Updated second paragraph to indicate that RFC 2254 is replaced by
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
this document (instead of RFC 1960). Added reference to the [Roadmap]
document.
@ -550,27 +577,19 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
escaped is replaced by a backslash and two hex digits, which
represent a single octet.
"Examples" section: added five additional examples: (seeAlso=),
(cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), (:=Fred Flintstone),
and (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
"Examples" section: added four additional examples: (seeAlso=),
(cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
(1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
value" with "an assertion value".
"Security Considerations" section: added references to [Protocol] and
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
[AuthMeth].
"Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the
document. Added entries for [ISO10646], [RFC2119], [AuthMeth],
[Models], and [Roadmap] and updated UTF-8 reference to RFC 2279.
Replaced RFC 822 reference with a reference to RFC 2234.
[Models], and [Roadmap] and updated the UTF-8 reference. Replaced
RFC 822 reference with a reference to RFC 2234.
"Informative References" section: added for clarity.
@ -582,72 +601,53 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
added.
15. Appendix B: Changes Since Previous Document Revision
16. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the last published
revision, draft-ietf-ldapbis-filter-03.txt. Note that when
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-filter-04.txt. Note that when
appropriate these changes are also included in Appendix A, but are
also included here for the benefit of the people who have already
reviewed draft-ietf-ldapbis-filter-03.txt. This section will be
reviewed draft-ietf-ldapbis-filter-04.txt. This section will be
removed before this document is published as an RFC.
15.1. Technical Changes
"String Search Filter Definition" section: Added statement that the
string representation is a string of UTF-8 encoded ISO 10646-1
characters and statement about expected behavior in light of RFC
2254's lack of a clear definition of "string representation."
"String Search Filter Definition" section: Revised all of the ABNF to
use common productions from [Models]. Revised the "normal"
production to restrict filter strings to valid UTF-8 sequences.
15.2. Editorial Changes
"Status of this Memo" section: updated boilerplate to match current
I-D guidelines.
"Examples" section: removed ;binary from an example.
"LDAP Search Filter Definition " section: updated section references
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
to match current LDAPBis drafts. Made minor changes to the ASN.1 so
it exactly matches that used in the Protocol document (added
comments).
"Normative References" section: added references to [ISO10646],
[RFC2119] and [Models].
"Informative References" section: added for clarity.
Updated copyright year to 2003.
This Internet Draft expires on 28 August 2003.
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
16.1. Technical Changes
"Examples" section: Removed the (:=Fred Flintstone) example which is
not allowed by the protocol.
16.2. Editorial Changes
"String Search Filter Definition" section: Revised the last two
sentences in this section to improve clarity (the updated text now
begins with the text "Implementations SHOULD accept as input a string
that includes...."
Replaced all occurrences of "asterix" with the correctly spelled
"asterisk."
"Normative References" section: changed UTF-8 reference to point to
the UTF-8 Internet Draft.
"Intellectual Property Rights" section: added.
Author's Addresses section: New email address for Mark Smith.
"Full Copyright Statement" section: updated text to match latest IETF
guidelines.
This Internet Draft expires on 25 April 2004.

460
doc/drafts/draft-ietf-ldapbis-models-xx.txt
View file

@ -6,13 +6,13 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 1 March 2003
Expires in six months 27 October 2003
Obsoletes: RFC 2251, RFC 2252, RFC 2256
LDAP: Directory Information Models
<draft-ietf-ldapbis-models-07.txt>
<draft-ietf-ldapbis-models-09.txt>
@ -40,9 +40,10 @@ Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved. Please
see the Copyright section near the end of this document for more
information.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
@ -54,10 +55,9 @@ Abstract
Zeilenga LDAP Models [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Table of Contents
@ -67,53 +67,56 @@ Table of Contents
Table of Contents 2
1. Introduction 3
1.1. Relationship to Other LDAP Specifications
1.2. Relationship to ITU Specifications
1.3. Conventions 4
1.2. Relationship to X.501 4
1.3. Conventions
1.4. Common ABNF Productions
2. Model of Directory User Information 6
2.1. The Directory Information Tree
2.2. Naming of Entries 7
2.1. The Directory Information Tree 7
2.2. Naming of Entries
2.3. Structure of an Entry 8
2.4. Object Classes
2.4. Object Classes 9
2.5. Attribute Descriptions 11
2.6. Alias Entries 15
3. Directory Administrative and Operational Information 16
3. Directory Administrative and Operational Information 17
3.1. Subtrees
3.2. Subentries 17
3.3. The 'objectClass' attribute
3.4. Operational attributes 18
4. Directory Schema 20
4.1. Schema Definitions 21
4.2. Subschema Subentries 30
3.2. Subentries
3.3. The 'objectClass' attribute 18
3.4. Operational attributes
4. Directory Schema 21
4.1. Schema Definitions 22
4.2. Subschema Subentries 31
4.3. 'extensibleObject' 34
4.4. Subschema Discovery
4.4. Subschema Discovery 35
5. DSA (Server) Informational Model
5.1. Server-specific Data Requirements 35
6. Other Considerations 38
5.1. Server-specific Data Requirements 36
6. Other Considerations 39
6.1. Preservation of User Information
6.2. Short Names
6.3. Cache and Shadowing 39
7. Implementation Guidelines 40
6.3. Cache and Shadowing 40
7. Implementation Guidelines
7.1. Server Guidelines
7.2. Client Guidelines
8. Security Considerations 41
7.2. Client Guidelines 41
8. Security Considerations
9. IANA Considerations
10. Acknowledgments 42
11. Author's Address
12. References
12. References 43
12.1. Normative References
12.2. Informative References 43
12.2. Informative References 44
Appendix A. Changes
A.1 Changes to RFC 2251 44
A.2 Changes to RFC 2252 46
A.3 Changes to RFC 2256 47
Copyright
A.3 Changes to RFC 2256 48
Intellectual Property Rights
Zeilenga LDAP Models [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Full Copyright 49
1. Introduction
@ -161,20 +164,20 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
portions of sections 4 and 6. Appendix A.1 summaries changes to these
sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
[AuthMeth], and [Roadmap] documents.
Zeilenga LDAP Models [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
[AuthMeth], and [Roadmap] documents.
This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
summaries changes to these sections. The remainder of RFC 2252 is
obsoleted by [Syntaxes] and [Schema].
obsoleted by [Syntaxes].
This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
Appendix A.3 summarizes changes to these sections. The remainder of
@ -184,8 +187,8 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
1.2. Relationship to X.501
This document includes material, with and without adaptation, from the
[X.501]. Due to the adaptation, the material included in this
document takes precedence.
[X.501]. The material in this document takes precedence over that in
[X.501].
1.3. Conventions
@ -217,17 +220,17 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
SP = 1*SPACE ; one or more " "
Zeilenga LDAP Models [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "
NULL = %x00 ; null (0)
@ -254,36 +257,37 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
; Any UTF-8 character
UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6
UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF
UTF1 = %x00-7F
UTF2 = %xC0-DF 1(UTF0)
UTF3 = %xE0-EF 2(UTF0)
UTF4 = %xF0-F7 3(UTF0)
UTF5 = %xF8-FB 4(UTF0)
UTF6 = %xFC-FD 5(UTF0)
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0)
; Any octet
OCTET = %x00-FF
Object identifiers are represented in LDAP using a dot-decimal format
conforming to the ABNF:
Object identifiers (OIDs) [X.680] are represented in LDAP using a dot-
decimal format conforming to the ABNF:
numericoid = number *( DOT number )
Short names, also known as descriptors, are used as more readable
aliases for object identifiers. Short names are case insensitive and
conform to the ABNF:
descr = keystring
Zeilenga LDAP Models [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
conform to the ABNF:
descr = keystring
Where either an object identifier or a short name may be specified,
the following production is used:
@ -329,17 +333,16 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
provides alternative naming. A subentry holds administrative and/or
operational information.
The set of entries representing the DIB are organized hierarchically
in a tree structure known as the Directory Information Tree (DIT).
Zeilenga LDAP Models [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
The set of entries representing the DIB are organized hierarchically
in a tree structure known as the Directory Information Tree (DIT).
Section 2.1 describes the Directory Information Tree
Section 2.2 discusses naming of entries.
Section 2.3 discusses the structure of entries.
@ -386,16 +389,14 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
immediate subordinates of the entry's immediate superior (i.e., all
siblings).
The following are example string representations of RDNs [LDAPDN]:
Zeilenga LDAP Models [Page 7]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
The following are example string representations of RDNs [LDAPDN]:
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
@ -446,10 +447,9 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 8]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Two values are considered equivalent if they would match according to
@ -505,7 +505,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 9]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
allowed to be present in entries belonging to the class. As an entry
@ -561,7 +561,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 10]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Structural object classes are related to associated entries:
@ -617,7 +617,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 11]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2.5.1) and a set of zero or more attribute options (see Section
@ -673,7 +673,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 12]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
syntax of its supertype. An attribute type cannot be a subtype of an
@ -695,7 +695,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Not all options can be associated with attributes held in the
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
unrecognized.
@ -716,7 +716,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
conforming to the <option> production defined in Section 2.5 of this
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
@ -729,7 +729,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 13]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
An attribute description with N tagging options is considered a direct
@ -785,7 +785,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 14]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
precisely one attribute description. The description is indicated
@ -841,7 +841,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 15]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
NOTE - The name within the 'aliasedObjectName' is said to be
@ -897,7 +897,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 16]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
( 2.5.4.1 NAME 'aliasedObjectName'
@ -953,7 +953,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 17]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
subentry (e.g., 'subschema' for subschema subentries) to mimic the
@ -987,7 +987,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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
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
superclasses of remaining 'objectClass' values from being deleted.
@ -1009,13 +1009,13 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 18]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
A directory operational attribute is used to represent operational
and/or administrative information in the Directory Information Model.
This includes operational attributes maintained by the server (e.g.
'createTimeStamp') as well as operational attributes which hold values
'createTimestamp') as well as operational attributes which hold values
administrated by the user (e.g. 'ditContentRules').
A DSA-shared operational attribute is used to represent information of
@ -1065,7 +1065,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 19]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
@ -1121,7 +1121,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 20]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
( 2.5.18.2 NAME 'modifyTimestamp'
@ -1177,7 +1177,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 21]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
structural object classes of the entries;
@ -1233,7 +1233,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 22]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
qdstring = SQUOTE dstring SQUOTE
@ -1289,7 +1289,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 23]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
@ -1317,7 +1317,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oid ] ; subtype
[ SP "SUP" SP oid ] ; supertype
[ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule
@ -1345,7 +1345,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 24]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
EQUALITY, ORDERING, SUBSTRING provide the oid of the equality,
@ -1401,7 +1401,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 25]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Attribute Type Description. This bound is not part of the syntax name
@ -1457,7 +1457,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 26]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
MatchingRuleUseDescription = LPAREN WSP
@ -1486,7 +1486,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
terms of ASN.1 [X.680] and, optionally, have an octet string encoding
known as the LDAP-specific encoding. Commonly, the LDAP-specific
encoding is constrained to string of 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).
@ -1513,7 +1513,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 27]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
For DIT entries of a particular structural object class, a DIT content
@ -1569,7 +1569,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 28]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
<numericoid> is the object identifier of the structural object class
@ -1625,7 +1625,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 29]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
where:
@ -1681,7 +1681,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 30]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
<numericoid> is object identifier which identifies this name form;
@ -1737,7 +1737,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 31]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Subschema is held in (sub)entries belonging to the subschema auxiliary
@ -1793,7 +1793,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 32]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
4.2.3. 'matchingRules'
@ -1849,7 +1849,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 33]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
@ -1905,7 +1905,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 34]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Note that not all servers will implement this object class, and those
@ -1961,7 +1961,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 35]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
5.1. Server-specific Data Requirements
@ -1996,7 +1996,8 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
- supportedLDAPVersion: LDAP versions supported; and
- supportedSASLMechanisms: recognized SASL mechnanisms.
- supportedSASLMechanisms: recognized Simple Authentication and
Security Layers (SASL) [SASL] mechanisms.
The values of these attributes provided may depend on session specific
and other factors. For example, a server supporting the SASL EXTERNAL
@ -2011,15 +2012,16 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Section 4.4.
5.1.1. 'altServer'
Zeilenga LDAP Models [Page 36]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
5.1.1. 'altServer'
The 'altServer' attribute lists URLs referring to alternative servers
which may be contacted when this server becomes unavailable. If the
server does not know of any other servers which could be used this
@ -2065,17 +2067,16 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Object identifiers identifying response controls need not be listed.
Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in BCP 64 [RFC3383].
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
protocol mechanisms are detailed in BCP 64 [BCP64bis].
Zeilenga LDAP Models [Page 37]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
( 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 )
@ -2097,7 +2098,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
extended operation need not be listed.
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'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
@ -2123,15 +2124,15 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
5.1.6. 'supportedSASLMechanisms'
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
[RFC2222] which the server recognizes. The contents of this attribute
Zeilenga LDAP Models [Page 38]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
[RFC2222] which the server recognizes. The contents of this attribute
may depend on the current session state. If the server does not
support any SASL mechanisms this attribute will not be present.
@ -2179,15 +2180,15 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Implementations MUST be prepared that the same short name might be
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
Zeilenga LDAP Models [Page 39]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
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
@ -2196,24 +2197,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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 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.
BCP 64 [BCP64bis].
6.3. Cache and Shadowing
@ -2236,14 +2220,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
the names of attribute types and object classes defined in Section 3
and 4, respectively, of [Schema].
Zeilenga LDAP Models [Page 40]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Servers MUST ensure that entries conform to user and system schema
rules or other data model constraints.
@ -2260,6 +2236,14 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Servers MAY implement additional schema elements. Servers SHOULD
provide definitions of all schema elements they support in subschema
Zeilenga LDAP Models [Page 40]
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
(sub)entries.
@ -2292,14 +2276,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
9. IANA Considerations
Zeilenga LDAP Models [Page 41]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
It is requested that the Internet Assigned Numbers Authority (IANA)
update the LDAP descriptors registry as indicated the following
template:
@ -2317,6 +2293,13 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
The following descriptors (short names) should be updated to refer
to RFC XXXX.
Zeilenga LDAP Models [Page 41]
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
NAME Type OID
------------------------ ---- -----------------
alias O 2.5.6.1
@ -2349,13 +2332,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
10. Acknowledgments
Zeilenga LDAP Models [Page 42]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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
RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
@ -2364,7 +2340,8 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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.
This document is a product of the IETF LDAP Revison (LDAPBIS) Working
Group.
11. Author's Address
@ -2373,69 +2350,91 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
E-mail: <kurt@openldap.org>
Zeilenga LDAP Models [Page 42]
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
12. References
12.1. Normative References
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
ietf-ldapbis-bcp64-xx.txt, a work in progress.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.
[LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
in progress.
[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.
[SASL] Melnikov, A. (Editor), "Simple Authentication and
Security Layer (SASL)",
draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", draft-yergeau-rfc2279bis-xx.txt, a work in
Zeilenga LDAP Models [Page 43]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
[Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation
of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a
work in progress.
progress.
[LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[ISO10646] International Organization for Standardization,
"Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane", ISO/IEC
10646-1 : 1993.
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[Schema] K. Dally (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in progress.
[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).
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
: 1993.
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
[X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", 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
@ -2463,9 +2462,10 @@ A.1 Changes to RFC 2251
Zeilenga LDAP Models [Page 44]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
A.1.1 Section 3.2 of RFC 2251
@ -2503,7 +2503,7 @@ A.1.2 Section 3.4 of RFC 2251
Changes:
- 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
'supportedExtension'.
@ -2521,7 +2521,7 @@ A.1.2 Section 3.4 of RFC 2251
Zeilenga LDAP Models [Page 45]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
- Remove inconsistent text regarding handling of the
@ -2577,7 +2577,7 @@ A.2.1 Section 4 of RFC 2252
Zeilenga LDAP Models [Page 46]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
specification "descr is the syntactic representation of an object
@ -2633,7 +2633,7 @@ A.2.3 Section 7 of RFC 2252
Zeilenga LDAP Models [Page 47]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
interacts with precluded attributes.
@ -2662,11 +2662,43 @@ A.3 Changes to RFC 2256
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.
Zeilenga LDAP Models [Page 48]
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Full Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
@ -2677,38 +2709,6 @@ Copyright 2003, The Internet Society. All Rights Reserved.
copyrights defined in the Internet Standards process must be followed,
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
Zeilenga LDAP Models [Page 48]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

3894
doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
View file

File diff suppressed because it is too large Load diff

212
doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt
View file

@ -6,13 +6,13 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 1 March 2003
Expires in six months 30 June 2003
Obsoletes: RFC 2251-2256, 2829-2830, 3377
LDAP: Technical Specification Road Map
<draft-ietf-ldapbis-roadmap-02.txt>
<draft-ietf-ldapbis-roadmap-03.txt>
Status of this Memo
@ -39,10 +39,10 @@ Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please 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
@ -57,7 +57,7 @@ Abstract
Zeilenga LDAP: TS Road Map [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
Conventions
@ -80,7 +80,8 @@ Conventions
LDAP: String Representation of Distinguished Names [LDAPDN],
LDAP: String Representation of Search Filters [Filters],
LDAP: Uniform Resource Locator [LDAPURL],
LDAP: Syntaxes [Syntaxes], and
LDAP: Syntaxes and Matching Rules [Syntaxes],
LDAP: Internationalized String Preparation [LDAPprep], and
LDAP: User Schema [Schema].
The terms "LDAP" and "LDAPv3" are commonly used to informally refer to
@ -93,27 +94,26 @@ Conventions
this document but may be defined in some future document(s).
IANA (Internet Assigned Numbers Authority) considerations for LDAP
described in BCP 64 [RFC3383] apply fully to this revision of the LDAP
technical specification.
described in BCP 64 [BCP64bis] apply fully to this revision of the
LDAP technical specification.
2. Relationship to X.500
This technical specification defines LDAP in terms of [X.500] as an
X.500 access mechanism. An LDAP server MUST act in accordance with
X.500(1993) series of International Telephone Union (ITU)
Recommendations when providing the service. However, it is not
required that an LDAP server make use of any X.500 protocols in
providing this service, e.g. LDAP can be mapped onto any other
directory system so long as the X.500 data and service models
X.500(1993) series of International Telecommunication Union - Telecom
Standardization (ITU-T) Recommendations when providing the service.
However, it is not required that an LDAP server make use of any X.500
protocols in providing this service, e.g. LDAP can be mapped onto any
other directory system so long as the X.500 data and service models
[X.501][X.511] as used in LDAP is not violated in the LDAP interface.
Zeilenga LDAP: TS Road Map [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
This technical specification explicitly incorporates portions of
@ -137,10 +137,13 @@ INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
[Models] replaces portions of RFC 2251, RFC 2252 and RFC 2256.
[Protocol] replaces the majority RFC 2251 and portions of RFC 2252.
[AuthMeth] replaces RFC 2829, RFC 2830, and portions of RFC 2251.
[Syntax] replaces the majority of RFC 2252 and portions of RFC 2256.
[Syntaxes] replaces the majority of RFC 2252 and portions of RFC 2256.
[Schema] replaces the majority of RFC 2256. [LDAPDN] replaces RFC
2253. [Filters] replaces RFC 2254. [LDAPURL] replaces RFC 2255.
[LDAPprep] is new to this revision of the LDAP technical
specification.
Each document of this specification contains appendices summarizing
changes to all sections of the specifications they replace. Appendix
A.1 of this document details changes made to RFC 3377. Appendix A.2
@ -163,57 +166,75 @@ INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
E-mail: <kurt@openldap.org>
7. References
Zeilenga LDAP: TS Road Map [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
7. References
7.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
ietf-ldapbis-bcp64-xx.txt, a work in progress.
[Models] K. Zeilenga (editor), "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
in progress.
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.
[Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation
of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a
work in progress.
[Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
Representation of Search Filters",
draft-ietf-ldapbis-filter-xx.txt, a work in progress.
[LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Schema] K. Dally (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in progress.
[LDAPprep] Zeilenga, K., "LDAP: Internationalized String
Preparation", draft-ietf-ldapbis-strpro-xx.txt, a work
in progress.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[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.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.
Zeilenga LDAP: TS Road Map [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.511] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Abstract Service Definition", X.511(1993).
7.2. Informative References
@ -221,40 +242,67 @@ INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
None.
Zeilenga LDAP: TS Road Map [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
Appendix A. Changes to Previous Documents
This appendix outlines changes this document makes relative
to the documents it replaces (in whole or in part).
This appendix outlines changes this document makes relative to the
documents it replaces (in whole or in part).
Appendix A.1. Changes to RFC 3377
This document is nearly a complete rewrite of RFC 3377 as
much of the material of RFC 3377 is no longer applicable.
These changes include defining the terms "LDAP" and
"LDAPv3" to refer to this revision of the technical
specification.
This document is nearly a complete rewrite of RFC 3377 as much of the
material of RFC 3377 is no longer applicable. The changes include
redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
the technical specification.
Appendix A.2. Changes to Section 3.3 of RFC 2251
The section was modified slightly (the word "document" was
replaced with "technical specification") to clarify that it
applies to the entire LDAP technical specification.
The section was modified slightly (the word "document" was replaced
with "technical specification") to clarify that it applies to the
entire LDAP technical specification.
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
Zeilenga LDAP: TS Road Map [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
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
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,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
@ -265,19 +313,27 @@ Copyright 2003, The Internet Society. All Rights Reserved.
copyrights defined in the Internet Standards process must be followed,
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.
Zeilenga LDAP: TS Road Map [Page 5]
Zeilenga LDAP: TS Road Map [Page 6]

410
doc/drafts/draft-ietf-ldapbis-strprep-xx.txt
View file

@ -6,12 +6,12 @@
Internet-Draft Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 26 May 2003
Expires in six months 27 October 2003
LDAP: Internationalized String Preparation
<draft-ietf-ldapbis-strprep-00.txt>
<draft-ietf-ldapbis-strprep-02.txt>
Status of this Memo
@ -46,10 +46,10 @@ Status of this Memo
Abstract
The previous Lightweight Directory Access Protocol (LDAP) technical
specifications did not precisely define how string matching is to be
performed. This lead to a number of usability and interoperability
problems. This document defines string preparation algorithms for
matching rules defined for use in LDAP.
specifications did not precisely define how character string matching
is to be performed. This lead to a number of usability and
interoperability problems. This document defines string preparation
algorithms for character-based matching rules defined for use in LDAP.
@ -57,7 +57,7 @@ Abstract
Zeilenga LDAPprep [Page 1]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
Conventions
@ -113,7 +113,7 @@ Conventions
Zeilenga LDAPprep [Page 2]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
The caseIgnoreMatch matching rule [X.520], for example, is simply
@ -130,22 +130,24 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
(Zs) property as a space, and another implementation may view any
character with the whitespace (WS) category as a space.
The lack of precise specification for string matching has led to
significant interoperability problems. When used in certificate chain
validation, security vulnerabilities can arise. To address these
problems, this document defines precise algorithms for preparing
strings for matching.
The lack of precise specification for character string matching has
led to significant interoperability problems. When used in
certificate chain validation, security vulnerabilities can arise. To
address these problems, this document defines precise algorithms for
preparing character strings for matching.
1.3. Relationship to "stringprep"
The string preparation algorithms described in this document are based
upon the "stringprep" approach [RFC3454]. In "stringprep", presented
and stored values are first prepared for comparison and so that a
character-by-character comparison yields the "correct" result.
The character string preparation algorithms described in this document
are based upon the "stringprep" approach [StringPrep]. In
"stringprep", presented and stored values are first prepared for
comparison and so that a character-by-character comparison yields the
"correct" result.
The approach used here is a refinement of the "stringprep" [RFC3454]
approach. Each algorithm involves two additional preparation steps.
The approach used here is a refinement of the "stringprep"
[StringPrep] approach. Each algorithm involves two additional
preparation steps.
a) prior to applying the Unicode string preparation steps outlined in
"stringprep", the string is transcoded to Unicode;
@ -154,24 +156,24 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
"stringprep", characters insignificant to the matching rules are
removed.
Hence, preparation of strings for X.500 matching involves the
following steps:
Hence, preparation of character strings for X.500 matching involves
the following steps:
1) Transcode
2) Map
3) Normalize
4) Prohibit
5) Check Bidi (Bidirectional)
6) Insignificant Character Removal
Zeilenga LDAPprep [Page 3]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
6) Insignificant Character Removal
These steps are described in Section 2.
@ -181,8 +183,8 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
[Roadmap] which obsoletes the previously defined LDAP technical
specification [RFC3377] in its entirety.
This document details new LDAP internationalized string preparation
algorithms used by [Syntaxes] and possible other technical
This document details new LDAP internationalized character string
preparation algorithms used by [Syntaxes] and possible other technical
specifications defining LDAP syntaxes and/or matching rules.
@ -190,15 +192,17 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
LDAP is defined [Roadmap] in X.500 terms as an X.500 access mechanism.
As such, there is a strong desire for alignment between LDAP and X.500
syntax and semantics. The string preparation algorithms described in
this document are based upon "Internationalized String Matching Rules
for X.500" [XMATCH] proposal to ITU/ISO Joint Study Group 2.
syntax and semantics. The character string preparation algorithms
described in this document are based upon "Internationalized String
Matching Rules for X.500" [XMATCH] proposal to ITU/ISO Joint Study
Group 2.
2. String Preparation
The following six-step process SHALL be applied to each presented and
attribute value in preparation for string match rule evaluation.
attribute value in preparation for character string matching rule
evaluation.
1) Transcode
2) Map
@ -207,11 +211,23 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
5) Check bidi
6) Insignificant Character Removal
Failure in any step is be cause the assertion to be Undefined.
Failure in any step causes the assertion to evaluate to Undefined.
This process is intended to act upon non-empty character strings. If
the string to prepare is empty, this process is not applied and the
assertion is evaluated to Undefined.
The character repertoire of this process is Unicode 3.2 [Unicode].
Zeilenga LDAPprep [Page 4]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
2.1. Transcode
Each non-Unicode string value is transcoded to Unicode.
@ -221,22 +237,11 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
PrintableString [X.680] value are transcoded directly to Unicode.
Zeilenga LDAPprep [Page 4]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
UniversalString, UTF8String, and bmpString [X.680] values need not be
transcoded as they are Unicode-based strings (in the case of
bmpString, a subset of Unicode).
If the implementation is unable or unwilling to perform the
transcoding as described above, or the transcoding fails, this step
fails and the assertion is evaluated to Undefined.
The transcoded string is the output string.
The output is the transcoded string.
2.2. Map
@ -259,44 +264,55 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Zp) are mapped to SPACE (U+0020).
For case ignore, numeric, and stored prefix string matching rules,
characters are case folded per B.2 of [RFC3454].
characters are case folded per B.2 of [StringPrep].
The output is the mapped string.
2.3. Normalize
The input string is be normalized to Unicode Form KC (compatibility
composed) as described in [UAX15].
composed) as described in [UAX15]. The output is the normalized
string.
2.4. Prohibit
All Unassigned, Private Use, and non-character code points are
prohibited. Surrogate codes (U+D800-DFFFF) are prohibited.
The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
The first code point of a string is prohibited from being a combining
Zeilenga LDAPprep [Page 5]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
2.4. Prohibit
All Unassigned code points are prohibited. Unassigned code points are
listed in Table A.1 of [StringPrep].
Private Use (U+E000-F8FF, F0000-FFFFD, 100000-10FFFD) code points are
prohibited.
All non-character code points (U+FDD0-FDEF, FFFE-FFFF, 1FFFE-1FFFF,
2FFFE-2FFFF, 3FFFE-3FFFF, 4FFFE-4FFFF, 5FFFE-5FFFF, 6FFFE-6FFFF,
7FFFE-7FFFF, 8FFFE-8FFFF, 9FFFE-9FFFF, AFFFE-AFFFF, BFFFE-BFFFF,
CFFFE-CFFFF, DFFFE-DFFFF, EFFFE-EFFFF, FFFFE-FFFFF, 10FFFE-10FFFF) are
prohibited.
Surrogate codes (U+D800-DFFFF) are prohibited.
The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
The first code point of a string is prohibited from being a combining
character.
Empty strings are prohibited.
The step fails and the assertion is evaluated to Undefined if the
input string contains any prohibited code point. The output string is
the input string.
The step fails if the input string contains any prohibited code point.
The output is the input string.
2.5. Check bidi
There are no bidirectional restrictions. The output string is the
input string.
There are no bidirectional restrictions. The output is the input
string.
2.5. Insignificant Character Removal
@ -305,21 +321,31 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
removed. The characters to be removed differ from matching rule to
matching rule.
Section 2.6.1 applies to case ignore and exact string matching.
Section 2.6.2 applies to numericString matching.
Section 2.6.3 applies to telephoneNumber matching
Section 2.5.1 applies to case ignore and exact string matching.
Section 2.5.2 applies to numericString matching.
Section 2.5.3 applies to telephoneNumber matching
2.6.1. Insignificant Space Removal
2.5.1. Insignificant Space Removal
For the purposes of this section, a space is defined to be the SPACE
(U+0020) code point followed by no combining marks.
NOTE - The previous steps ensure that the string cannot contain any
Zeilenga LDAPprep [Page 6]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
code points in the separator class, other than SPACE (U+0020).
The following spaces are regarded as not significant and are to be
removed:
If the input string consists entirely of spaces or is empty, the
output is a string consisting of exactly one space (e.g. " ").
Otherwise, the following spaces are removed:
- leading spaces (i.e. those preceding the first character that is
not a space);
- trailing spaces (i.e. those following the last character that is
@ -327,19 +353,8 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
- multiple consecutive spaces (these are taken as equivalent to a
single space character).
A string consisting entirely of spaces is equivalent to a string
containing exactly one space.
For example, removal of spaces from the Form KC string:
"<SPACE><SPACE>foo<SPACE><SPACE>bar<SPACE><SPACE>"
Zeilenga LDAPprep [Page 6]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
would result in the output string:
"foo<SPACE>bar"
and the Form KC string:
@ -348,38 +363,61 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
"<SPACE>".
2.6.2. numericString Insignificant Character Removal
2.5.2. numericString Insignificant Character Removal
For the purposes of this section, a space is defined to be the SPACE
(U+0020) code point followed by no combining marks.
All spaces are regarded as not significant and are to be removed.
All spaces are regarded as not significant. If the input string
consists entirely of spaces or is empty, the output is a string
consisting of exactly one space (e.g. " "). Otherwise, all spaces are
to be removed.
For example, removal of spaces from the Form KC string:
"<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>" would result in
the output string:
"<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
would result in the output string:
"123456"
and the Form KC string:
"<SPACE><SPACE><SPACE>"
would result in an empty output string.
would result in the output string:
"<SPACE>".
2.6.3. telephoneNumber Insignificant Character Removal
2.5.3. telephoneNumber Insignificant Character Removal
For the purposes of this section, a hyphen is defined to be
HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
Zeilenga LDAPprep [Page 7]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
(U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by no
combining marks and a space is defined to be the SPACE (U+0020) code
point followed by no combining marks.
All hyphens and spaces are regarded as not significant and are to be
All hyphens and spaces are considered insignificant. If the string
contains only spaces and hyphens or is empty, then the output is a
string consisting of one space. Otherwise, all hyphens and spaces are
removed.
For example, removal of hyphens and spaces from the Form KC string:
"<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
would result in the output string:
"123456"
and the Form KC string:
"<HYPHEN><HYPHEN><HYPHEN>"
would result in the output string:
"<SPACE>".
3. Security Considerations
"Preparation for International Strings ('stringprep')" [RFC3454]
"Preparation for International Strings ('stringprep')" [StringPrep]
security considerations generally apply to the algorithms described
here.
@ -388,14 +426,6 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Appendix A and B of this document were authored by Howard Chu
<hyc@symas.com> of Symas Corporation (based upon information provided
Zeilenga LDAPprep [Page 7]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
in RFC 1345).
@ -403,14 +433,25 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
The approach used in this document is based upon design principles and
algorithms described in "Preparation of Internationalized Strings
('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some
('stringprep')" [StringPrep] by Paul Hoffman and Marc Blanchet. Some
additional guidance was drawn from Unicode Technical Standards,
Technical Reports, and Notes.
This document is a product of the IETF LDAP Revision (LDAPBIS) Working
Group.
6. Author's Address
Kurt Zeilenga
Zeilenga LDAPprep [Page 8]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
E-mail: <kurt@openldap.org>
@ -421,14 +462,14 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ('stringprep')", RFC 3454,
December 2002.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[StringPrep] Hoffman P. and M. Blanchet, "Preparation of
Internationalized Strings ('stringprep')",
draft-hoffman-rfc3454bis-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
@ -445,13 +486,6 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
Zeilenga LDAPprep [Page 8]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
[UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
Unicode Normalization Forms, Version 3.2.0".
<http://www.unicode.org/unicode/reports/tr15/tr15-22.html>,
@ -466,6 +500,14 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Character Sets for the International Teletex Service",
T.61, 1988.
Zeilenga LDAPprep [Page 9]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
7.2. Informative References
[X.500] International Telecommunication Union -
@ -491,7 +533,7 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
2000.
[XMATCH] Zeilenga, K., "Internationalized String Matching Rules
for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt a
for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt, a
work in progress.
[RFC1345] Simonsen, K., "Character Mnemonics & Character Sets",
@ -500,17 +542,9 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Appendix A. Teletex (T.61) to Unicode
Zeilenga LDAPprep [Page 9]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
This appendix defines an algorithm for transcoding [T.61] characters
to [Unicode] characters for use in string preparation for LDAP
matching rules. This appendix is a normative.
matching rules. This appendix is normative.
The transcoding algorithm is derived from the T.61-8bit definition
provided in [RFC1345]. With a few exceptions, the T.61 character
@ -522,6 +556,14 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
The codes from x80 to x9f are also equivalent to the corresponding
Unicode code points. This is specified for completeness only, as
Zeilenga LDAPprep [Page 10]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
these codes are control characters, and will be mapped to nothing in
the LDAP String Preparation Mapping step.
@ -532,9 +574,9 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Undefined matching result. For diagnostic purposes, this algorithm
does not fail for undefined input codes. Instead, undefined codes in
the input are mapped to the Unicode REPLACEMENT CHARACTER (U+FFFD).
As the LDAP String Preparation Probhibit step disallows the
REPLACEMENT CHARACTER from appearing in its output, this transcoding
yields the desired effect.
As the LDAP String Preparation Prohibit step disallows the REPLACEMENT
CHARACTER from appearing in its output, this transcoding yields the
desired effect.
Note: RFC 1345 listed the non-spacing accent codepoints as residing in
the range starting at (U+E000). In the current Unicode
@ -556,14 +598,6 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
e8| 0141 | 00d8 | 0152 | 00ba | 00de | 0166 | 014a | 0149 |
f0| 0138 | 00e6 | 0111 | 00f0 | 0127 | 0131 | 0133 | 0140 |
f8| 0142 | 00f8 | 0153 | 00df | 00fe | 0167 | 014b | ?? |
Zeilenga LDAPprep [Page 10]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
--+------+------+------+------+------+------+------+------+
Table A.1: Mapping of 8-bit T.61 codes to Unicode
@ -579,12 +613,19 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Appendix B. Additional Teletex (T.61) to Unicode Tables
Zeilenga LDAPprep [Page 11]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
All of the accented characters in T.61 have a corresponding code point
in Unicode. For the sake of completeness, the combined character
codes are presented in the following tables. This is informational
only; for matching purposes it is sufficient to map the non-spacing
accent and exchange the order of the character pair as specified in
Appendix A.
Appendix A. This appendix is informative.
B.1. Combinations with SPACE
@ -612,14 +653,6 @@ B.2. Combinations for xc1: (Grave accent)
40| ?? | 00c0 | ?? | ?? | ?? | 00c8 | ?? | ?? |
48| ?? | 00cc | ?? | ?? | ?? | ?? | 01f8 | 00d2 |
50| ?? | ?? | ?? | ?? | ?? | 00d9 | ?? | 1e80 |
Zeilenga LDAPprep [Page 11]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
58| ?? | 1ef2 | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e0 | ?? | ?? | ?? | 00e8 | ?? | ?? |
68| ?? | 00ec | ?? | ?? | ?? | ?? | 01f9 | 00f2 |
@ -635,6 +668,14 @@ B.3. Combinations for xc2: (Acute accent)
C, L, N, R, S, and Z. Unicode also defines G, K, M, P, and W. All of
these combinations are present in Table B.3.
Zeilenga LDAPprep [Page 12]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 00c1 | ?? | 0106 | ?? | 00c9 | ?? | 01f4 |
@ -669,13 +710,6 @@ B.4. Combinations for xc3: (Circumflex)
Table B.4: Mapping of T.61 Circumflex Accent Combinations
Zeilenga LDAPprep [Page 12]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
B.5. Combinations for xc4: (Tilde)
T.61 has predefined characters for combinations with A, I, O, U, and
@ -690,6 +724,14 @@ B.5. Combinations for xc4: (Tilde)
58| ?? | 1ef8 | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e3 | ?? | ?? | ?? | 1ebd | ?? | ?? |
68| ?? | 0129 | ?? | ?? | ?? | ?? | 00f1 | 00f5 |
Zeilenga LDAPprep [Page 13]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
70| ?? | ?? | ?? | ?? | ?? | 0169 | 1e7d | ?? |
78| ?? | 1ef9 | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
@ -724,14 +766,6 @@ B.7. Combinations for xc6: (Breve)
Unicode also defines E, I, and O. All of these combinations are
present in Table B.7.
Zeilenga LDAPprep [Page 13]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 0102 | ?? | ?? | ?? | 0114 | ?? | 011e |
@ -746,6 +780,14 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Table B.7: Mapping of T.61 Breve Accent Combinations
Zeilenga LDAPprep [Page 14]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
B.8. Combinations for xc7: (Dot Above)
T.61 has predefined characters for C, E, G, I, and Z. Unicode also
@ -780,14 +822,6 @@ B.9. Combinations for xc8: (Diaeresis)
58| 1e8c | 0178 | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e4 | ?? | ?? | ?? | 00eb | ?? | ?? |
68| 1e27 | 00ef | ?? | ?? | ?? | ?? | ?? | 00f6 |
Zeilenga LDAPprep [Page 14]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
70| ?? | ?? | ?? | ?? | 1e97 | 00fc | ?? | 1e85 |
78| 1e8d | 00ff | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
@ -802,6 +836,14 @@ B.10. Combinations for xca: (Ring Above)
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 00c5 | ?? | ?? | ?? | ?? | ?? | ?? |
Zeilenga LDAPprep [Page 15]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
48| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
50| ?? | ?? | ?? | ?? | ?? | 016e | ?? | ?? |
58| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
@ -836,14 +878,6 @@ B.11. Combinations for xcb: (Cedilla)
B.12. Combinations for xcd: (Double Acute Accent)
T.61 has predefined characters for O, and U. These combinations are
Zeilenga LDAPprep [Page 15]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
present in Table B.12.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
@ -858,6 +892,14 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
B.13. Combinations for xce: (Ogonek)
Zeilenga LDAPprep [Page 16]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
T.61 has predefined characters for A, E, I, and U. Unicode also
defines the combination for O. All of these combinations are present
in Table B.13.
@ -892,20 +934,11 @@ B.14. Combinations for xcf: (Caron)
68| 021f | 01d0 | 01f0 | 01e9 | 013e | ?? | 0148 | 01d2 |
70| ?? | ?? | 0159 | 0161 | 0165 | 01d4 | ?? | ?? |
78| ?? | ?? | 017e | ?? | ?? | ?? | ?? | ?? |
Zeilenga LDAPprep [Page 16]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
--+------+------+------+------+------+------+------+------+
Table B.14: Mapping of T.61 Caron Accent Combinations
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
@ -915,6 +948,14 @@ Intellectual Property Rights
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
Zeilenga LDAPprep [Page 17]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
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
@ -951,5 +992,20 @@ Full Copyright
Zeilenga LDAPprep [Page 17]
Zeilenga LDAPprep [Page 18]

1556
doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt
View file

File diff suppressed because it is too large Load diff

484
doc/drafts/draft-ietf-ldapbis-url-xx.txt
View file

@ -7,13 +7,13 @@
Network Working Group Mark Smith, Editor
Request for Comments: DRAFT Netscape Communications Corp.
Obsoletes: RFC 2255 Tim Howes
Expires: 28 August 2003 Opsware, Inc.
Expires: 25 April 2004 Opsware, Inc.
28 February 2003
25 October 2003
LDAP: Uniform Resource Locator
<draft-ietf-ldapbis-url-03.txt>
<draft-ietf-ldapbis-url-04.txt>
@ -57,7 +57,7 @@ Copyright (C) The Internet Society (2003). All Rights Reserved.
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
3. Table of Contents
@ -67,20 +67,22 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
3. Table of Contents..............................................2
4. Introduction...................................................2
5. URL Definition.................................................2
5.1. Escaping Using the Method.................................4
6. Defaults for Fields of the LDAP URL............................5
7. Examples.......................................................5
8. Security Considerations........................................7
9. Acknowledgements...............................................8
10. Normative References...........................................9
11. Informative References.........................................9
12. Authors' Address...............................................9
13. Full Copyright Statement.......................................10
14. Appendix A: Changes Since RFC 2255.............................10
14.1. Technical Changes...........................................10
14.2. Editorial Changes...........................................11
15. Appendix B: Changes Since Previous Document Revision...........13
15.1. Technical Changes...........................................13
15.2. Editorial Changes...........................................13
7. Examples.......................................................6
8. Security Considerations........................................8
9. Normative References...........................................8
10. Informative References.........................................9
11. Intellectual Property Rights...................................9
12. Acknowledgements...............................................10
13. Authors' Address...............................................10
14. Full Copyright Statement.......................................11
15. Appendix A: Changes Since RFC 2255.............................11
15.1. Technical Changes...........................................11
15.2. Editorial Changes...........................................12
16. Appendix B: Changes Since Previous Document Revision...........13
16.1. Technical Changes...........................................14
16.2. Editorial Changes...........................................14
4. Introduction
@ -106,37 +108,42 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
5. URL Definition
An LDAP URL begins with the protocol prefix "ldap" and is defined by
the following grammar, following the ABNF notation defined in
[RFC2234].
Smith & Howes Intended Category: Standards Track [Page 2]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
the following grammar, following the ABNF notation defined in
[RFC2234].
ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn
[QUESTION [attributes] [QUESTION [scope]
[QUESTION [filter] [QUESTION extensions]]]]]
scheme = "ldap"
hostport = <hostport from Section 3.2.2 of [RFC2396]>
; as updated by [RFC2732] to allow IPv6 literal addresses
; as updated by [RFC2732] to allow IPv6 literal addresses
dn = <distinguishedName from Section 3 of [LDAPDN]>
; see the "Escaping Using the % Method" section below.
attributes = attrdesc *(COMMA attrdesc)
attrdesc = <AttributeDescription from Section 4.1.4 of [Protocol]>
/ ASTERIX
/ ASTERISK
; see the "Escaping Using the % Method" section below.
scope = "base" / "one" / "sub"
filter = <filter from Section 4 of [Filters]>
; see the "Escaping Using the % Method" section below.
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid / oiddescr
exvalue = <LDAPString from section 4.1.2 of [Protocol]>
; see the "Escaping Using the % Method" section below.
oid = <LDAPOID from section 4.1.2 of [Protocol]>
oiddescr = <name from section 3.3 of [LDAPIANA]>
oiddescr = <name from section 3.3 of [RFC3383]>
EXCLAMATION = %x21 ; exclamation mark ("!")
ASTERIX = %x2A ; asterix ("*")
ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
SLASH = %x5C; forward slash ("/")
@ -157,6 +164,14 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
The scope construct is used to specify the scope of the search to
perform in the given LDAP server. The allowable scopes are "base"
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
for a base object search, "one" for a one-level search, or "sub" for
a subtree search.
@ -164,14 +179,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
within the specified scope during the search. It has the format
specified in [Filters].
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
The extensions construct provides the LDAP URL with an extensibility
mechanism, allowing the capabilities of the URL to be extended in the
future. Extensions are a simple comma-separated list of type=value
@ -199,18 +206,29 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
The extension type (extype) MAY be specified using the oid form
(e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use
of the oiddesc form SHOULD be restricted to registered object
identifier descriptive names. See [LDAPIANA] for registration
details and usage guidelines for descriptive names.
identifier descriptive names. See [RFC3383] for registration details
and usage guidelines for descriptive names.
No LDAP URL extensions are defined in this document. Other documents
or a future version of this document MAY define one or more
extensions.
5.1. Escaping Using the % Method
A generated LDAP URL MUST consist only of the restricted set of
characters included in the uric production that is defined in section
2 of [RFC2396]. Implementations SHOULD accept other valid UTF-8
strings as input. An octet MUST be escaped using the % method
described in section 2.4 of [RFC2396] in any of these situations:
strings [UTF-8] as input. An octet MUST be escaped using the %
method described in section 2.4 of [RFC2396] in any of these
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
situations:
The octet is not in the reserved set defined in section 2.2 of
[RFC2396] or in the unreserved set defined in section 2.3 of
@ -221,13 +239,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
It is a comma character ',' that occurs inside an extension value.
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
6. Defaults for Fields of the LDAP URL
Some fields of the LDAP URL are optional, as described above. In the
@ -263,6 +274,16 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
If extensions is omitted, no extensions are assumed.
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
7. Examples
The following are some example LDAP URLs using the format defined
@ -277,13 +298,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
Both of these URLs correspond to a base object search of the
"o=University of Michigan,c=US" entry using a filter of
"(objectclass=*)", requesting all attributes.
@ -318,28 +332,28 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
the LDAP entry named "o=Question?,c=US" is given below, illustrating
the use of the escaping mechanism on the reserved character '?'.
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
ldap://ldap2.example.com/o=Question%3f,c=US?mail
The next example illustrates the interaction between the LDAP string
representation of filters quoting mechanism and URL quoting
mechanisms.
ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04)
The filter in this example uses the LDAP escaping mechanism of \ to
encode three zero or null bytes in the value. In LDAP, the filter
would be written as (int=\00\00\00\04). Because the \ character must
be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
ldap://ldap3.example.com/o=Babsco,c=US???(four-octet=%5c00%5c00%5c00%5c04)
IP The filter in this example uses the LDAP escaping mechanism of \
to encode three zero or null bytes in the value. In LDAP, the filter
would be written as (four-octet=\00\00\00\04). Because the \
character must be escaped in a URL, the \'s are escaped as %5c in the
URL encoding.
The next example illustrates the interaction between the LDAP string
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
representation of DNs quoting mechanism and URL quoting mechanisms.
ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US
@ -374,6 +388,14 @@ name extension (the value associated with the extension is an LDAP DN).
the e-bindname extension.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
8. Security Considerations
General URL security considerations discussed in [RFC2396] are
@ -388,14 +410,6 @@ name extension (the value associated with the extension is an LDAP DN).
with this policy. If a client chooses to reuse an existing
connection when resolving one or more LDAP URL, it MUST ensure that
the connection is compatible with the URL and that no security
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
policies are violated.
Sending authentication information, no matter the mechanism, may
@ -427,7 +441,88 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
search, etc. The security implications of resolving an LDAP URL are
the same as those of resolving an LDAP search query.
9. Acknowledgements
9. Normative References
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in
progress.
[Filters] Smith, M. and Howes, T., "LDAP: String Representation of
Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
progress.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels," RFC 2119, BCP 14, March 1997.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-
ietf-ldapbis-protocol-xx.txt, a work in progress.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access Protocol
(LDAP)", RFC 3383, September 2002.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a work in
progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
draft-yergeau-rfc2279bis-xx.txt, a work in progress.
10. Informative References
None.
11. 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
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
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.
12. Acknowledgements
The LDAP URL format was originally defined at the University of
Michigan. This material is based upon work supported by the National
@ -445,54 +540,7 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
thanks for their contributions.
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
10. Normative References
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in
progress.
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
ldapbis-iana-xx.txt, a work in progress.
[Filters] Smith, M. and Howes, T., "LDAP: String Representation of
Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
progress. [RFC2119] Bradner, S., "Key Words for use in RFCs to
Indicate Requirement Levels," RFC 2119, BCP 14, March 1997.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-
ietf-ldapbis-protocol-xx.txt, a work in progress.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a work in
progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
11. Informative References
None.
12. Authors' Address
13. Authors' Address
Mark Smith, Editor
Netscape Communications Corp.
@ -500,15 +548,7 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
Sunnyvale, CA 94089
USA
+1 650 937-3477
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
mcs@netscape.com
MarkCSmithWork@aol.com
Tim Howes
Opsware, Inc.
@ -516,9 +556,17 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
Sunnyvale, CA 94085
USA
+1 408 744-7509
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
howes@opsware.com
13. Full Copyright Statement
14. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
@ -546,48 +594,46 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
15. Appendix A: Changes Since RFC 2255
14. Appendix A: Changes Since RFC 2255
14.1. Technical Changes
15.1. Technical Changes
The following technical changes were made to the contents of the "URL
Definition" section:
Revised all of the ABNF to use common productions from [Models].
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
Added note and references to [RFC2732] to allow literal IPv6
addresses inside the hostport portion of the URL.
Added missing ASTERIX as an alternative for the attrdesc part of the
Added missing ASTERISK as an alternative for the attrdesc part of the
URL. It is believed that existing implementations of RFC 2255
already support this.
Added angle brackets around free-form prose in the "dn", "hostport",
"attrdesc", "filter", and "exvalue" rules.
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
Changed the ABNF for ldapurl to group the dn component with the
preceding slash.
Changed the extype rule to be an LDAPOID from [Protocol] or an OID
description from [LDAPIANA].
description from [RFC3383].
Changed the text about extension types so it references [LDAPIANA].
Changed the text about extension types so it references [RFC3383].
Reordered rules to more closely follow the order the elements appear
in the URL.
"Bindname Extension": removed due to lack of known implementations.
14.2. Editorial Changes
15.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
@ -612,14 +658,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
"URL Definition" section: removed second copy of ldapurl grammar and
following two paragraphs (editorial error in RFC 2255). Fixed line
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
break within '!' sequence. Reworded last paragraph to clarify which
characters must be URL escaped. Added text to indicate that LDAP
URLs are used for references and referrals. Added text that refers
@ -630,6 +668,14 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
"URL Processing" section: clarified that connections MAY be reused
only if the open connection is compatible with the URL. Added text
Smith & Howes Intended Category: Standards Track [Page 12]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
to indicate that use of security services is encouraged and that they
SHOULD be used when updates are involved. Removed "dn" from
discussion of authentication methods. Added note that the client MAY
@ -639,9 +685,11 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
example.net hostnames. Added missing '?' to the LDAP URL example
whose filter contains three null bytes. Removed space after one
comma within a DN. Revised the bindname example to use e-bindname.
Added an example that demonstrates the interaction between DN
escaping and URL escaping. Added some examples to show URL
equivalence with respect to the dn portion of the URL.
Changed the name of an attribute used in one example from "int" to
"four-octet" to avoid potential confusion. Added an example that
demonstrates the interaction between DN escaping and URL escaping.
Added some examples to show URL equivalence with respect to the dn
portion of the URL.
"Security Considerations" section: Added a note about connection
reuse. Added a note about using strong authentication methods for
@ -654,11 +702,11 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
"Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the
document. Added references to RFCs 2234 and 2829. Updated RFC 1738
references to the appropriate sections within RFC 2396. Updated the
references to refer to LDAPBis WG documents. Removed the reference to
the LDAP Attribute Syntaxes document and added references to the LDAP
IANA and Roadmap documents.
document. Added references to RFCs 2234, 2829, and 3383. Updated
RFC 1738 references to the appropriate sections within RFC 2396.
Updated the references to refer to LDAPBis WG documents. Removed the
reference to the LDAP Attribute Syntaxes document and added a
reference to the Roadmap document.
"Informative References" section: added for clarity.
@ -668,64 +716,72 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
Copyright: updated the year.
16. Appendix B: Changes Since Previous Document Revision
Smith & Howes Intended Category: Standards Track [Page 12]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
15. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the last published
revision, draft-ietf-ldapbis-url-02.txt. Note that when appropriate
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-url-03.txt. Note that when appropriate
these changes are also included in Appendix A, but are also included
here for the benefit of the people who have already reviewed draft-
ietf-ldapbis-url-02.txt. This section will be removed before this
ietf-ldapbis-url-03.txt. This section will be removed before this
document is published as an RFC.
15.1. Technical Changes
"URL Definition" section: revised all of the ABNF to use common
productions from [Models] and added note and references to [RFC2732]
to allow literal IPv6 addresses inside the hostport portion of the
URL.
15.2. Editorial Changes
"Status of this Memo" section: updated boilerplate to match current
I-D guidelines.
"URL Definition" section: replaced misleading phrase "MAY define
other extensions" with "MAY define one or more extensions" (this
document no longer defines any extensions). Rewrote the last
paragraph of this section to more clearly describe the escaping rules
and to reference [RFC2396] accurately.
"Examples" section: added an example that demonstrates the
interaction between DN escaping and URL escaping and clarified the
text that introduces the LDAP filter escaping interaction example.
"Acknowledgements" section: added Hallvard Furuseth.
"Normative References" section: added a reference to [RFC2732].
"Informative References" section: added for clarity.
Copyright: updated the year to 2003.
"Authors' Address" section: updated Tim's contact information.
Appendix A: added an older editorial change that was accidently
overlooked (Changed document title to include "LDAP:" prefix).
This Internet Draft expires on 28 August 2003.
Smith & Howes Intended Category: Standards Track [Page 13]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
16.1. Technical Changes
None.
16.2. Editorial Changes
"URL Definition" section: added comments in the ABNF to point the
reader to the "Escaping Using the % Method" section, which was
changed into a section of its own to highlight the importance of
escaping the URL components correctly.
"Examples" section: changed the name of an attribute used in one
example from "int" to "four-octet" to avoid potential confusion.
Replaced all occurrences of "asterix" with the correctly spelled
"asterisk."
"Normative References" section: changed UTF-8 reference to point to
the UTF-8 Internet Draft; replace [LDAPIANA] Internet Draft reference
with a reference to RFC 3383.
"Intellectual Property Rights" section: added.
Author's Addresses section: New email address for Mark Smith.
"Full Copyright Statement" section: updated text to match latest IETF
guidelines.
This Internet Draft expires on 25 April 2004.
Smith & Howes Intended Category: Standards Track [Page 14]

1277
doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
View file

File diff suppressed because it is too large Load diff

1298
doc/drafts/draft-ietf-ldup-lcup-xx.txt
View file

File diff suppressed because it is too large Load diff

176
doc/drafts/draft-zeilenga-ldap-adlist-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
Expires in six months 20 December 2002
Expires in six months 26 October 2003
LDAP: Requesting Attributes by Object Class
<draft-zeilenga-ldap-adlist-04.txt>
<draft-zeilenga-ldap-adlist-06.txt>
Status of this Memo
@ -21,9 +21,9 @@ Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Informational document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions Working Group
mailing list <ldapext@ietf.org>. Please send editorial comments
directly to the author <Kurt@OpenLDAP.org>.
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -38,10 +38,10 @@ Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2002, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please 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
@ -57,7 +57,7 @@ Abstract
Zeilenga Requesting Attributes by Object Class [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
1. Overview
@ -82,14 +82,21 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
[RFC2256].
This extension is intended to be used where the user is in direct
control of the parameters of the LDAP search operation.
control of the parameters of the LDAP search operation, such as when
entering a LDAP URL [RFC2255] into a web browser.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
DSA stands for Directory System Agent (or server).
DSE stands for DSA-specific Entry.
2. Return of all Attributes of an Object Class
3. Return of all Attributes of an Object Class
This extension allows object class identifiers is to be provided in
the attributes field of the LDAP SearchRequest [RFC2251]. For each
@ -101,6 +108,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
unrecognized attribute description.
This extension redefines the attributes field of the SearchRequest to
Zeilenga Requesting Attributes by Object Class [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
be a DescriptionList described by the following ASN.1 [X.680] data
type:
@ -109,13 +124,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
The Description is string conforming to the ABNF [RFC2234]:
Zeilenga Requesting Attributes by Object Class [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
Description = AttributeDescription | ObjectClassDescription.
ObjectClassDescription = "+" ObjectClass *( ";" options )
@ -129,9 +137,11 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
zero options in the attributes field of a SearchRequest. Other uses
may be defined in future specifications.
Servers supporting this feature SHOULD publish the Object Identifier
1.3.6.1.4.1.4203.1.11.2 as a value of the 'supportedFeatures'
[FEATURES] attribute in the root DSE.
Servers supporting this feature SHOULD publish the object identifier
(OID) 1.3.6.1.4.1.4203.1.11.2 as a value of the 'supportedFeatures'
[FEATURES] attribute in the root DSE. Clients supporting this feature
SHOULD NOT use the feature unless they have knowledge the server
supports it.
3. Security Considerations
@ -147,29 +157,30 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
4. IANA Considerations
This OID 1.3.6.1.4.1.4203.1.11.2 to identify the LDAP "OC AD List?
feature. This OID was assigned [ASSIGN] by OpenLDAP Foundation, under
its IANA-assigned private enterprise allocation [PRIVATE], for use in
this specification.
The OID 1.3.6.1.4.1.4203.1.11.2 is used to identify the LDAP "OC AD
List" feature. This OID was assigned [ASSIGN] by OpenLDAP Foundation,
under its IANA-assigned private enterprise allocation [PRIVATE], for
use in this specification.
Registration of this protocol mechansism is requested per BCP 64
Registration of this protocol mechanism is requested per BCP 64
[RFC3383].
Subject: Request for LDAP Protocol Mechansism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.5.2
Description: OC AD Lists
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
Specification: RFCxxxx
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
Comments: none
Zeilenga Requesting Attributes by Object Class [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.5.2
Description: OC AD Lists
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
Specification: RFC XXXX
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
Comments: none
5. Author's Address
@ -181,58 +192,66 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
6. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
[FEATURES] Zeilenga, K., "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt, a work in progress.
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 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).
7. Informative References
[RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
September 2002.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
Zeilenga Requesting Attributes by Object Class [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
Copyright 2002, The Internet Society. All Rights Reserved.
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
December, 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for
use with LDAPv3", RFC 2256, December 1997.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
Full Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
@ -243,25 +262,6 @@ Copyright 2002, The Internet Society. All Rights Reserved.
copyrights defined in the Internet Standards process must be followed,
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.

106
doc/drafts/draft-zeilenga-ldap-assert-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 11 May 2003
Expires in six months 25 October 2003
The LDAP Assertion Control
<draft-zeilenga-ldap-assert-00.txt>
<draft-zeilenga-ldap-assert-01.txt>
Status of this Memo
@ -22,8 +22,8 @@ Status of this Memo
revision, submitted to the IESG for consideration as a Standard Track
document. Distribution of this memo is unlimited. Technical
discussion of this document will take place on the IETF LDAP
Extensions Working Group mailing list <ldapext@ietf.org>. Please send
editorial comments directly to the author <Kurt@OpenLDAP.org>.
Extensions mailing list <ldapext@ietf.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -48,30 +48,30 @@ Abstract
This document defines the Lightweight Directory Access Protocol (LDAP)
Assertion Control which allows a client to specify that a directory
operation should only be processed if the assertion when applied to
the target entry of the operation. It can be used to construct "test
and set" and "test and clear" operations.
operation should only be processed if an assertion applied to the
target entry of the operation is true. It can be used to construct
"test and set" and "test and clear" and other conditional operations.
Zeilenga LDAP Assertion Control [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
1. Overview
This document defines the Lightweight Directory Access Protocol (LDAP)
[RFC3377] assertion control. The assertion control allows the client
to specify a condition which allows the operation to be processed
normally only when true. Otherwise the operation fails.
to specify a condition which must be true for the operation to be
processed normally. Otherwise the operation fails.
The control can be used with the Modify operation [RFC2251] to perform
atomic "test and set" and "test and clear" operations as the the
asserted condition is evaluated as an integral part the operation.
The control may be attached to other update operations to support
conditional add, delete, and renaming of objects.
atomic "test and set" and "test and clear" operations as the asserted
condition is evaluated as an integral part the operation. The control
may be attached to other update operations to support conditional add,
delete, and renaming of objects.
The control may also be used with the search operation. Here the
assertion is applied to the base object of the search before searching
@ -83,13 +83,12 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
2. Terminology
Protocol elements are described using ASN.1 [X.680]. The term
"BER-encoded" means the element is to be encoded using the Basic
Encoding Rules [X.690] under the restrictions detailed in Section 5.1
of [RFC2251].
Protocol elements are described using ASN.1 [X.680] with implicit
tags. The term "BER-encoded" means the element is to be encoded using
the Basic Encoding Rules [X.690] under the restrictions detailed in
Section 5.1 of [RFC2251].
DN stands for Distinguished Name.
DSA stands for Directory System Agent (i.e., a directory server).
DSA stands for Directory System Agent (or server).
DSE stands for DSA-specific Entry.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@ -104,30 +103,25 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
[RFC2251, Section 4.5.1]. The criticality may be TRUE or FALSE.
There is no corresponding response control.
Servers implementing this technical specification SHOULD publish
IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute
[RFC2252] in their root DSE.
The control is appropriate for both LDAP interrogation and update
operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
(rename), and Search. It is inappropriate for Abandon, Bind nor
Unbind operations. It is also inappropriate for the Start TLS
[RFC2830] operation.
Zeilenga LDAP Assertion Control [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
The control is appropriate for both LDAP interrogation and update
operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
(rename), and Search. It is not appropriate for Abandon, Bind nor
Unbind operations. Nor is it appropriate for the Start TLS [RFC2830]
operation.
When the control is attached to an LDAP request, the processing of the
request is conditional on the evaluation of the Filter as applied
against the target of the operation. If the Filter evaluates to TRUE,
then the request is processed normally. If the Filter evaluates to
FALSE, then assertionFailed (IANA-ASSIGNED-CODE) resultCode is
returned and no further processing is performed.
FALSE or Undefined, then assertionFailed (IANA-ASSIGNED-CODE)
resultCode is returned and no further processing is performed.
For Add, Compare, and ModifyDN the target is indicated by the entry
field in the request. For Modify, the target is indicated by the
@ -135,23 +129,29 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
type. For the Compare operation and all update operations, the
evaluation of the assertion MUST be performed as an integral part of
the operation. That is, the evaluation of the assertion and the
normal processing SHALL be done as one atomic action.
normal processing of the operation SHALL be done as one atomic action.
For search operation, the target is indicated by the baseObject field
and the evaluation is done after "finding" but before "searching"
[RFC2251]. Hence, if the evaluation fails, no entries or
continuations references are returned.
Servers implementing this technical specification SHOULD publish the
object identifier IANA-ASSIGNED-OID as a value of the
'supportedControl' attribute [RFC2252] in their root DSE. A server
MAY choose to advertise this extension only when the client is
authorized to use it.
Other documents may specify how this control applies to other LDAP
operations. In doing so, they must how the target entry is
operations. In doing so, they must state how the target entry is
determined.
3. Security Considerations
4. Security Considerations
The filter may, like other values of the request, contain sensitive
information. When so, this information should be appropriately
protected.
The filter may, like other components of the request, contain
sensitive information. When so, this information should be
appropriately protected.
As with any general assertion mechanism, the mechanism can be used to
determine directory content. Hence, the mechanism SHOULD be subject
@ -169,16 +169,16 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
Zeilenga LDAP Assertion Control [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
4. IANA Considerations
5. IANA Considerations
4.1. Object Identifier
5.1. Object Identifier
It is requested that IANA register upon Standards Action an LDAP
Object Identifier [RFC3383] to identify the LDAP Assertion Control
defined in this document.
It is requested that IANA assign upon Standards Action an LDAP Object
Identifier [RFC3383] to identify the LDAP Assertion Control defined in
this document.
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
@ -188,7 +188,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
Comments:
Identifies the LDAP Assertion Control
4.2 LDAP Protocol Mechanism
5.2 LDAP Protocol Mechanism
Registration of this protocol mechanism [RFC3383] is requested.
@ -203,7 +203,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
Comments: none
4.3 LDAP Result Code
5.3 LDAP Result Code
Assignment of an LDAP Result Code [RFC3383] called 'assertionFailed'
is requested.
@ -217,7 +217,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
Comments: none
5. Acknowledgments
6. Acknowledgments
The assertion control concept is attributed to Morteza Ansari.
@ -225,17 +225,17 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
Zeilenga LDAP Assertion Control [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
6. Author's Address
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
7. Normative References
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
@ -252,7 +252,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
September 2002.
8. Informative References
9. Informative References
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
@ -281,7 +281,7 @@ Intellectual Property Rights
Zeilenga LDAP Assertion Control [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
copyrights, patents or patent applications, or other proprietary

188
doc/drafts/draft-zeilenga-ldap-authzid-xx.txt
View file

@ -6,12 +6,12 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 May 2002
Expires in six months 1 November 2002
LDAP "Who am I?" Operation
<draft-zeilenga-ldap-authzid-06.txt>
<draft-zeilenga-ldap-authzid-08.txt>
Status of this Memo
@ -23,8 +23,8 @@ Status of this Memo
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extension Working Group
mailing list <ietf-ldapext@netscape.com>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
mailing list <ldapext@ietf.org>. Please send editorial comments
directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -57,7 +57,7 @@ Abstract
Zeilenga LDAP "Who am I?" [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
Conventions
@ -70,27 +70,20 @@ Conventions
1. Background and Intent of Use
This specification describes a Lightweight Directory Access Protocol
(LDAP) [RFC2251] extended operation which clients can use to obtain
the primary authorization identity in its primary form which the
server has associated with the user or application entity.
Servers often associate multiple authorization identities with the
client and each authorization identity may be represented by multiple
authzId [RFC2829] strings. This operation requests and returns the
authzId the server considers to be primary. In the specification, the
term "the authorization identity" and "the authzid" are to generally
read as "the primary authorization identity" and the "the primary
authzid", respectively.
(LDAP) [RFC3377] operation which clients can use to obtain the primary
authorization identity in its primary form which the server has
associated with the user or application entity. The operation is
called the "Who am I?" operation.
This specification is intended to replace the existing [AUTHCTL]
mechanism which uses Bind request and response controls to request and
return the authorization identity. Bind controls are not protected by
the security layers established by the Bind operation which they are
transferred as part of. While it is possible to establish security
layers prior to the Bind operation, it is often desirable to only use
security layers established by the Bind operation. An extended
operation sent after a Bind operation is protected by the security
layers established by the Bind operation.
layers using Start TLS [RFC2830] prior to the Bind operation, it is
often desirable to use security layers established by the Bind
operation. An extended operation sent after a Bind operation is
protected by the security layers established by the Bind operation.
There are other cases where it is desirable to request the
authorization identity which the server associated with the client
@ -101,26 +94,31 @@ Conventions
Control. The "Who am I?" operation can also be used prior to the Bind
operation.
The LDAP "Who am I?" operation is named after the UNIX whoami(1)
command. The whoami(1) command displays the effective user id.
Servers often associate multiple authorization identities with the
client and each authorization identity may be represented by multiple
authzId [RFC2829] strings. This operation requests and returns the
authzId the server considers to be primary. In the specification, the
term "the authorization identity" and "the authzId" are generally to
be read as "the primary authorization identity" and the "the primary
authzId", respectively.
2. The "Who am I?" Operation
The "Who am I?" operation is defined as an LDAP Extended Operation
[RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
(OID). This section details the syntax of the operation's whoami
Zeilenga LDAP "Who am I?" [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
[RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
(OID). This section details the syntax of the operation's whoami
request and response messages.
whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
2.1. The whoami Request
@ -130,48 +128,54 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
example, a whoami request could be encoded as the sequence of octets
(in hex):
30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
2.2. The whoami Response
The whoami response is an ExtendedResponse where the responseName
field is absent and, if present, the response field is empty or an
field is absent and the response field, if present, is empty or an
authzId [RFC2829]. For example, a whoami response returning the
authzid "u:kurt@OPENLDAP.ORG" (in response to the example request)
authzId "u:kurt@OPENLDAP.ORG" (in response to the example request)
would be encoded as the sequence of octets (in hex):
30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
75 3a 6b 75 72 74 40 4f 50 45 4e 4c 44 41 50 2e
4f 52 47
3. Operational Semantics
The function of the "Who am I?" operation is to request that the
server returns the authorization identity it currently associates with
the client. The client requests this authorization identity by
issuing a whoami Request. The server responds to this request with a
whoami Response.
The "Who am I?" operation provides a mechanism, a whoami Request, for
the client to request that the server returns the authorization
identity it currently associates with the client and provides a
mechanism, a whoami Response, for the server to respond to that
request.
If the server is willing and able to provide the authorization
identity it associates with the client, the server SHALL return a
whoami Response with a success resultCode. If the server is treating
the client as an anonymous entity, the response field is empty.
Otherwise the server is to provide the authzId [RFC2829] representing
the authorization identity it currently associates with the client in
the response field.
the client as an anonymous entity, the response field is present but
empty. Otherwise the server provides the authzId [RFC2829]
representing the authorization identity it currently associates with
the client in the response field.
If the server is unwilling or unable to provide the authorization
identity it associates with the client, the server SHALL return a
whoami Response with an appropriate non-success resultCode (such as
operationsError, protocolError, confidentialityRequired,
insufficientAccessRights, busy, unavailable, unwillingToPerform, or
other) and an absent response field.
Zeilenga LDAP "Who am I?" [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
operationsError, protocolError, confidentialityRequired,
insufficientAccessRights, busy, unavailable, unwillingToPerform, or
other) and an absent response field.
As described in [RFC2251] and [RFC2829], an LDAP session has an
"anonymous" association until the client has been successfully
authenticated using the Bind operation. Clients MUST NOT invoke the
@ -183,10 +187,10 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
4. Extending the "Who am I?" operation with controls
Future specifications may extend the "Who am I?" operation using the
control mechanism. When extended by controls, the "Who am I?"
operation requests and returns the authorization identity the server
associates with the client in a particular context indicated by the
controls.
control mechanism [RFC2251]. When extended by controls, the "Who am
I?" operation requests and returns the authorization identity the
server associates with the client in a particular context indicated by
the controls.
4.1. Proxied Authorization Control
@ -204,7 +208,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
it associates with the assumed identity.
When a Proxied Authorization Control is be attached to the "Who Am I?"
operation, the operation requests the return of the authzid the server
operation, the operation requests the return of the authzId the server
associates with the identity asserted in the Proxied Authorization
Control. The TBD result code is used to indicate that the server does
not allow the client to assume the asserted identity. [[Note to RFC
@ -216,33 +220,50 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
Identities associated with users may be sensitive information. When
so, security layers [RFC2829][RFC2830] should be established to
protect this information. This mechanism is specifically designed to
allow security layers established by a Bind operation to protect the
integrity and/or confidentiality of the authorization identity.
Zeilenga LDAP "Who am I?" [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
protect this information. This mechanism is specifically designed to
allow security layers established by a Bind operation to protect the
integrity and/or confidentiality of the authorization identity.
Servers may place access control or other restrictions upon the use of
this operation.
As with any other extended operations, general LDAP considerations
apply. These are detailed in [RFC2251], [RFC2829], and [RFC2830].
As with any other extended operations, general LDAP security
considerations [RFC3377] apply.
6. IANA Considerations
No IANA assignments are requested.
This OID 1.3.6.1.4.1.4203.1.11.3 to identify the LDAP "Who Am I?
extended operation. This OID was assigned [ASSIGN] by OpenLDAP
Foundation, under its IANA-assigned private enterprise allocation
[PRIVATE], for use in this specification.
This document uses the OID 1.3.6.1.4.1.4203.1.11.3 to identify the
LDAP "Who Am I? extended operation. This OID was assigned [ASSIGN] by
OpenLDAP Foundation under its IANA assigned private enterprise
allocation [PRIVATE] for use in this specification.
Registration of this protocol mechansism is requested [RFC3383].
Subject: Request for LDAP Protocol Mechansism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.11.3
Description: Who am I?
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFCxxxx
Author/Change Controller: IESG
Comments: none
7. Acknowledgment
@ -251,6 +272,17 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
"Authentication Response Control" [AUTHCTL] by Rob Weltman, Mark Smith
and Mark Wahl.
The LDAP "Who am I?" operation takes it name from the UNIX whoami(1)
command. The whoami(1) command displays the effective user id.
Zeilenga LDAP "Who am I?" [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
8. Author's Address
@ -274,18 +306,19 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[PROXYCTL] R. Weltman, "LDAP Proxied Authentication Control", draft-
weltman-ldapv3-proxy-xx.txt (a work in progress).
Zeilenga LDAP "Who am I?" [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
10. Informative References
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
@ -299,6 +332,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
Copyright 2002, The Internet Society. All Rights Reserved.
Zeilenga LDAP "Who am I?" [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
@ -335,5 +376,20 @@ Copyright 2002, The Internet Society. All Rights Reserved.
Zeilenga LDAP "Who am I?" [Page 6]
Zeilenga LDAP "Who am I?" [Page 7]

254
doc/drafts/draft-zeilenga-ldap-cancel-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 3 May 2003
Expires in six months 25 October 2003
LDAP Cancel Extended Operation
<draft-zeilenga-ldap-cancel-08.txt>
LDAP Cancel Operation
<draft-zeilenga-ldap-cancel-10.txt>
1. Status of this Memo
@ -21,9 +21,9 @@ Expires in six months 3 May 2003
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extension Working Group
mailing list <ldapext@ietf.org>. Please send editorial comments
directly to the author <Kurt@OpenLDAP.org>.
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -38,10 +38,10 @@ Expires in six months 3 May 2003
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please 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
@ -57,20 +57,23 @@ Abstract
Zeilenga LDAP Cancel [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
Conventions
Terminology
Protocol elements are described using ASN.1 [X.680] with implicit
tags. The term "BER-encoded" means the element is to be encoded using
the Basic Encoding Rules [X.690] under the restrictions detailed in
Section 5.1 of [RFC2251].
DSA stands for Directory System Agent (or server).
DSE stands for DSA-specific Entry.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
Protocol elements are described using ASN.1 [X.680]. The term
"BER-encoded" means the element is to be encoded using the Basic
Encoding Rules [X.690] under the restrictions detailed in Section 5.1
of [RFC2251].
1. Background and Intent of Use
@ -83,10 +86,10 @@ Conventions
X.511 Directory Access Protocol (DAP) [X.511] provides an Abandon
operation which does have a response and also requires the abandoned
operation to return a response indicating it was canceled. The Cancel
operation is modeled after the DAP Abandon operation.
operation to return a response indicating it was canceled. The LDAP
Cancel operation is modeled after the DAP Abandon operation.
The Cancel operation SHOULD be used instead of the LDAP Abandon
The LDAP Cancel operation SHOULD be used instead of the LDAP Abandon
operation when the client needs an indication of the outcome. This
operation may be used to cancel both interrogation and update
operations.
@ -106,18 +109,17 @@ Conventions
2.1. Cancel Request
The Cancel request is an ExtendedRequest with the requestName field
containing the IANA-0IGNED-OID and a requestValue field which contains
Zeilenga LDAP Cancel [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
a BER-encoded cancelRequestValue value. The cancelID field contains
the message id associated with the operation to be canceled.
The Cancel request is an ExtendedRequest with the requestName field
containing the IANA-ASSIGNED-OID and a requestValue field which
contains a BER-encoded cancelRequestValue value. The cancelID field
contains the message id associated with the operation to be canceled.
2.2. Cancel Response
@ -143,10 +145,10 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
cancel an outstanding operation issued within the same session.
The client requests the cancelation of an outstanding operation by
issuing a Cancel Response with a cancelID with the message id
identifying the outstanding operation. The Cancel Request itself has
a distinct message id. Clients SHOULD NOT request cancelation of an
operation multiple times.
issuing a Cancel Response with a cancelID set to the message id of the
outstanding operation. The Cancel Request itself has a distinct
message id. Clients SHOULD NOT request cancelation of an operation
multiple times.
If the server is willing and able to cancel the outstanding operation
identified by the cancelId, the server SHALL return a Cancel Response
@ -162,22 +164,24 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
knowledge of the operation requested to be canceled.
The cannotCancel resultCode is returned if the identified operation
does not support cancelation or the cancel operation could not be
performed. The following classes of operations are not cancelable:
Zeilenga LDAP Cancel [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
does not support cancelation or the cancel operation could not be
performed. The following classes of operations are not cancelable:
- operations which have no response,
- operations which associate or disassociate authentication and/or
- operations which create, alter, or destroy authentication and/or
authorization associations,
- operations which establish or tear-down security services, and
- operations which establish, alter, or tear-down security services,
and
- operations which abandon or cancel other operations.
@ -187,20 +191,22 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
The tooLate resultCode is returned to indicate that it is too late to
cancel the outstanding operation. For example, the server may return
tooLate for a request to cancel an outstanding modify operation which
as already commited updates to the underlying datastore.
as already committed updates to the underlying data store.
Servers SHOULD indicate their support for this extended operation by
providing IANA-ASSIGNED-OID as a value of the supportedExtension
providing IANA-ASSIGNED-OID as a value of the 'supportedExtension'
attribute type in their root DSE. A server MAY choose to advertise
this extension only when the client is authorized to use this
operation.
this extension only when the client is authorized to use it.
4. Security Considerations
This operation is intended to allow a user to cancel operations they
previously issued. No user should be allowed to cancel an operation
issued by another user.
This operation is intended to allow user to cancel operations they
previously issued during the current LDAP association. In certain
cases, such as when the Proxy Authorization Control is in use,
different outstanding operations may be processed under different LDAP
associations. Servers MUST NOT allow a user to cancel an operation
belonging to another user.
Some operations should not be cancelable for security reasons. This
specification disallows cancelation of Bind operation and Start TLS
@ -215,28 +221,26 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
Registration of the following values [RFC3383] is requested.
5.1. Object Identifier
It is requested that IANA register upon Standards Action an LDAP
Object Identifier to identify the LDAP Cancel Extended Operation as
defined in this document.
Zeilenga LDAP Cancel [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
The following registration template is suggested:
5.1. Object Identifier
It is requested that IANA register upon Standards Action an LDAP
Object Identifier to identify the LDAP Cancel Operation as defined in
this document.
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFCXXXX
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the LDAP Cancel Extended Operation
Identifies the LDAP Cancel Operation
5.2. LDAP Protocol Mechanism
@ -244,13 +248,13 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
It is requested that IANA register upon Standards Action the LDAP
Protocol Mechanism described in this document.
Subject: Request for LDAP Protocol Mechansism Registration
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID
Description: LDAP Cancel Extended Operation
Description: LDAP Cancel Operation
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFCXXXX
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
in 2
@ -268,78 +272,112 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
Result Code Name: noSuchOperation
Result Code Name: tooLate
Result Code Name: cannotCancel
Specification: RFCXXXX
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: request four consecutive result codes be assigned
6. Acknowledgment
The LDAP Cancel operation is modeled after the X.511 DAP Abandon
Zeilenga LDAP Cancel [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
6. Acknowledgment
The LDAP Cancel operation is modeled after the X.511 DAP Abandon
operation.
7. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
[RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
Directory Access Protocol (v3): Extension for Transport
Layer Security", RFC 2830, May 2000.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol
(v3): Technical Specification", RFC 3377, September 2002.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification
of Basic Notation", X.680, 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).
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", X.690, 1994.
[X.690] International Telecommunication Union -
Telecommunication Standardization Sector, "Specification
of ASN.1 encoding rules: Basic Encoding Rules (BER),
Canonical Encoding Rules (CER), and Distinguished
Encoding Rules (DER)", X.690(1997) (also ISO/IEC
8825-1:1998).
8. Informative References
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
September 2002.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[X.511] ITU-T, "The Directory: Abstract Service Definition", X.511,
1993.
[X.511] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Abstract Service Definition", X.511(1993).
9. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
Copyright 2003, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
Zeilenga LDAP Cancel [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
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
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
@ -347,44 +385,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
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.

458
doc/drafts/draft-zeilenga-ldap-rfc2596-xx.txt
View file

@ -6,12 +6,12 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 1 March 2002
Expires in six months 9 December 2002
Obsoletes: RFC 2596
Language Tags and Ranges in LDAP
draft-zeilenga-ldap-rfc2596-01.txt
draft-zeilenga-ldap-rfc2596-04.txt
Status of Memo
@ -23,9 +23,8 @@ Status of Memo
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions Working Group
(LDAPext) mailing list <ietf-ldapext@netscape.com>. Please send
editorial comments directly to the document editor
<Kurt@OpenLDAP.org>.
(LDAPext) mailing list <ldapext@ietf.org>. Please send editorial
comments directly to the document editor <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -55,9 +54,10 @@ Abstract
Zeilenga Language Tags and Ranges in LDAP [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Conventions
@ -69,7 +69,7 @@ Conventions
1. Background and Intended Use
The Lightweight Directory Access Protocol (LDAP) [Roadmap] provides a
The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a
means for clients to interrogate and modify information stored in a
distributed directory system. The information in the directory is
maintained as attributes of entries. Most of these attributes have
@ -79,8 +79,8 @@ Conventions
This document describes how language tags and ranges [RFC3066] are
carried in LDAP and are to be interpreted by LDAP implementations.
All implementations MUST be prepared to accept language tags and
ranges in the LDAP protocol.
All LDAP implementations MUST be prepared to accept language tags and
ranges.
This document replaces RFC 2596. Appendix A summaries changes made
since RFC 2596.
@ -88,8 +88,7 @@ Conventions
Appendix B discusses differences from X.500(1997) "contexts"
mechanism.
Appendix A and B are provided for information purposes and are not a
normative part of this specification.
Appendix A and B are provided for informational purposes only.
The remainder of this section provides a summary of Language Tags,
Language Ranges, and Attribute Descriptions.
@ -98,89 +97,81 @@ Conventions
1.1. Language Tags
Section 2 of BCP 47 [RFC3066] describes the language tag format which
is used in LDAP. Briefly, it is a string of ASCII alphabetic
characters and hyphens. Examples include "fr", "en-US" and "ja-JP".
Language tags are case insensitive. For example, the language tag
"en-us" is the same as "EN-US".
is used in LDAP. Briefly, it is a string of ASCII letters and
hyphens. Examples include "fr", "en-US" and "ja-JP". Language tags
are case insensitive. That is, the language tag "en-us" is the same
as "EN-US".
Section 2 of this document details use of language tags in LDAP.
1.2. Language Ranges
Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
Zeilenga Language Tags and Ranges in LDAP [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
Language ranges are used to specify sets of language tags.
A language range matches a language tag if it exactly equals the tag,
or if it exactly equals a prefix of the tag such that the first
character following the prefix is "-". The special tag "*" matches
all tags.
A language range matches a language tag if it is exactly equal to the
tag, or if it is exactly equal to a prefix of the tag such that the
first character following the prefix is "-". That is, the language
range "de" matches the language tags "de" and "de-CH" but not "den".
The special language range "*" matches all language tags.
Due to restrictions upon option naming in LDAP, this document uses a
different language range syntax. However, the semantics of language
ranges in LDAP is consistent with BCP 47.
Due to attribute description option naming restrictions in LDAP, this
document defines a different language range syntax. However, the
semantics of language ranges in LDAP is consistent with BCP 47.
Section 3 of this document details use of language ranges in LDAP.
1.3. Attribute Descriptions
This section provides an overview of attributes in LDAP. LDAP
attributes are defined in [Models].
This section provides an overview of attribute descriptions in LDAP.
LDAP attributes and attribute descriptions are defined in [RFC2251].
An attribute consists of a type, a set of zero or more associated
tagging options, and a set of one or more values. The type and the
options are combined into the AttributeDescription.
AttributeDescriptions can also contain options which are not part of
the attribute, but indicate some other function such as the transfer
encoding.
the attribute, but indicate some other function (such as range
assertion or transfer encoding).
An attribute with one or more tagging options is a direct subtype of
each attribute of the same with all but one of the tagging options.
If the attribute's type is a direct subtype of some other type, then
the attribute is also a direct subtype of the attribute whose
description consists of the the supertype and all of the tagging
options. That is, CN;x-bar;x-foo is a direct subtype of CN;x-bar,
CN;x-foo, and name;x-bar;x-foo. Note that CN is a subtype of name.
If the attribute description contains an unrecognized option, the
attribute description is treated as an unrecognized attribute type.
As language tags are intended to stored with the attribute, they are
to treated as tagging options as described in Section 2. Language
range are used only to match against language ranges and are not
stored with the attribute. They are not treated tagging options (nor
as transfer options), but as described in Section 3.
An AttributeDescription with one or more tagging options is a direct
subtype of each AttributeDescription of the same type with all but one
of the tagging options. If the AttributeDescription's type is a
direct subtype of some other type, then the AttributeDescription is
also a direct subtype of the AttributeDescription which consists of
the supertype and all of the tagging options. That is,
"CN;x-bar;x-foo" is a direct subtype of "CN;x-bar", "CN;x-foo", and
"name;x-bar;x-foo". Note that "CN" is a subtype of "name".
2. Use of Language Tags in LDAP
This section describes how LDAP implementations MUST interpret
Zeilenga Language Tags and Ranges in LDAP [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
language tags in performing operations.
Servers which support storing attributes with language tag options in
the Directory Information Tree (DIT) SHOULD allow any attribute type
it recognizes that has the Directory String, IA5 String, or other
textual string syntax to have language tag options associated with it.
Servers MAY allow language options to be associated with other
textual string syntaxes to have language tag options associated with
it. Servers MAY allow language options to be associated with other
attributes types.
Zeilenga Language Tags and Ranges in LDAP [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Clients SHOULD NOT assume servers are capable of storing attributes
with language tags in the directory.
@ -194,8 +185,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
2.1. Language Tag Options
A language tag option associates a natural language with values of an
attribute. An attribute description MAY contain multiple language tag
options. An entry MAY contain multiple attributes with same attribute
attribute. An attribute description may contain multiple language tag
options. An entry may contain multiple attributes with same attribute
type but different combinations of language tag (and other) options.
A language tag option conforms to the following ABNF [RFC2234]:
@ -216,17 +207,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
DIGIT = %x30-39 ; 0-9
A language tag option is a tagging option [Models]. A language tag
option has no effect on the syntax of the attribute's values nor their
transfer encoding.
Zeilenga Language Tags and Ranges in LDAP [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
A language tag option is a tagging option. A language tag option has
no effect on the syntax of the attribute's values nor their transfer
encoding.
Examples of valid AttributeDescription:
@ -237,6 +220,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
description;x-foobar
CN
Zeilenga Language Tags and Ranges in LDAP [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Notes: The last two have no language tag options. The x-foobar option
is fictious and used for example purposes.
@ -249,13 +240,13 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
type or its subtypes and contains each of the presented (and possibly
other) options is to be matched.
Thus for example a filter of an equality match of type
Thus, for example, a filter of an equality match of type
"name;lang-en-US" and assertion value "Billy Ray", against the
following directory entry
following directory entry:
dn: SN=Ray,DC=example,DC=com
objectclass: top DOES NOT MATCH (wrong type)
objectclass: person DOES NOT MATCH (wrong type)
objectclass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
@ -267,7 +258,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
SN: Ray DOES NOT MATCH (no lang-,
wrong value)
(Note that "CN" and "SN" are subtypes of "name".)
Note that "CN" and "SN" are subtypes of "name".
It is noted that providing a language tag option in a search filter
AttributeDescription will filter out desirable values where the tag
@ -276,14 +267,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
If the server does not support storing attributes with language tag
options in the DIT, then any assertion which includes a language tag
Zeilenga Language Tags and Ranges in LDAP [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
option will not match as such it is an unrecognized attribute type.
No error would be returned because of this; a presence assertion would
evaluate to FALSE and all other assertions to Undefined.
@ -292,12 +275,20 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
attribute type and the assertion value need match the value in the
directory.
Thus for example a filter of an equality match of type "name" and
assertion value "Billy Ray", against the following directory entry
Thus, for example, a filter of an equality match of type "name" and
dn: SN=Ray,DC=example,DC=net
objectclass: top DOES NOT MATCH (wrong type)
Zeilenga Language Tags and Ranges in LDAP [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
assertion value "Billy Ray", against the following directory entry:
dn: SN=Ray,DC=example,DC=com
objectclass: person DOES NOT MATCH (wrong type)
objectclass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US;x-foobar: Billy Ray MATCHES
@ -310,19 +301,20 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
2.3. Requested Attributes in Search
Clients can provide language tag options in AttributeDescription in
the requested attribute list in a search request.
Clients can provide language tag options in each AttributeDescription
in the requested attribute list in a search request.
If language tag options are provided in an attribute description, then
only attributes in a directory entry whose attribute descriptions have
the same attribute type or its subtype and the provided language tags
options are to be returned. Thus if a client requests just the
attribute "name;lang-en", the server would return "name;lang-en" and
the same attribute type or its subtype and contains each of the
presented (and possibly other) language tag options are to be
returned. Thus if a client requests just the attribute
"name;lang-en", the server would return "name;lang-en" and
"CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr".
Clients can provide in the attribute list multiple
AttributeDescription which have the same base attribute type but
different options. For example a client could provide both
AttributeDescriptions which have the same base attribute type but
different options. For example, a client could provide both
"name;lang-en" and "name;lang-fr", and this would permit an attribute
with either language tag option to be returned. Note there would be
no need to provide both "name" and "name;lang-en" since all subtypes
@ -333,13 +325,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
include language tag options are to be ignored, just as if they were
unknown attribute types.
Zeilenga Language Tags and Ranges in LDAP [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
If a request is made specifying all attributes or an attribute is
requested without providing a language tag option, then all attribute
values regardless of their language tag option are returned.
@ -347,18 +332,24 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
For example, if the client requests a "description" attribute, and a
matching entry contains the following attributes:
Zeilenga Language Tags and Ranges in LDAP [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
objectclass: top
objectclass: organization
O: Software GmbH
description: software
description: software products
description;lang-en: software products
description;lang-de: Softwareprodukte
postalAddress: Berlin 8001 Germany
postalAddress;lang-de: Berlin 8001 Deutschland
The server would return:
description: software
description: software products
description;lang-en: software products
description;lang-de: Softwareprodukte
@ -369,11 +360,12 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
a compare request AttributeValueAssertion. This is to be treated by
servers the same as the use of language tag options in a search filter
with an equality match, as described in Section 2.2. If there is no
attribute in the entry with the same subtype and language tag options,
the noSuchAttributeType error will be returned.
attribute in the entry with the same attribute type or its subtype and
and contains each of the presented (or possibly other) language tag
options, the noSuchAttributeType error will be returned.
Thus for example a compare request of type "name" and assertion value
"Johann", against an entry containing the following attributes:
Thus, for example, a compare request of type "name" and assertion
value "Johann", against an entry containing the following attributes:
objectclass: top
objectclass: person
@ -388,14 +380,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
would fail with the noSuchAttributeType error.
If the server does not support storing attributes with language tag
Zeilenga Language Tags and Ranges in LDAP [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
options in the DIT, then any comparison which includes a language tag
option will always fail to locate an attribute, and
noSuchAttributeType will be returned.
@ -404,25 +388,30 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
2.5. Add Operation
Clients can provide language options in AttributeDescription in
Zeilenga Language Tags and Ranges in LDAP [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
attributes of a new entry to be created.
A client can provide multiple attributes with the same attribute type
and value, so long as each attribute has a different set of language
tag options.
For example, the following is a legal request.
For example, the following is a valid request:
dn: CN=John Smith,DC=example,DC=com
objectclass: top
objectclass: person
objectclass: residentialPerson
name: John Smith
CN: John Smith
CN;lang-en: John Smith
SN: Smith
SN;lang-en;lang-en-US: Smith
SN;lang-en: Smith
streetAddress: 1 University Street
streetAddress;lang-en: 1 University Street
streetAddress;lang-en-US: 1 University Street
streetAddress;lang-fr: 1 rue Universite
houseIdentifier;lang-fr: 9e etage
@ -444,14 +433,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
"delete", then if the stored values to be deleted have language tag
options, then those language tag options MUST be provided in the
modify operation, and if the stored values to be deleted do not have
Zeilenga Language Tags and Ranges in LDAP [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
any language tag option, then no language tag option is to be
provided.
@ -463,6 +444,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
3. Use of Language Ranges in LDAP
Zeilenga Language Tags and Ranges in LDAP [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Since the publication of RFC 2596, it has become apparent that there
is a need to provide a mechanism for a client to request attributes
based upon set of language tag options whose tags all begin with the
@ -479,20 +468,10 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
language-range-option = "lang-" [ Language-Tag "-" ]
where the Language-Tag production is as defined in BCP 47 [RFC3066].
This production and those it imports from [RFC2234] are provided here
for convenience:
This production and those it imports from [RFC2234] are provided in
Section 2.1 for convenience.
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
A language range option matches a language tag option if language
A language range option matches a language tag option if the language
range option less the trailing "-" matches exactly the language tag or
if the language range option (including the trailing "-") matches a
prefix of the language tag option. Note that the language range
@ -501,15 +480,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Examples of valid AttributeDescription containing language range
options:
Zeilenga Language Tags and Ranges in LDAP [Page 9]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
givenName;lang-en-
CN;lang-
SN;lang-de-;lang-gem-
O;lang-x-;x-foobar
A language range option is not a tagging option. Attributes cannot be
@ -521,23 +494,32 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
the syntax of the attribute values.
Servers SHOULD support assertion of language ranges for any attribute
which they allow to stored with language tags.
type which they allow to be stored with language tags.
3.1. Search Filter
If a language range option is present in an AttributeDescription in an
Zeilenga Language Tags and Ranges in LDAP [Page 9]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
assertion, then for each entry within scope, the values of each
attribute whose AttributeDescription consists of the same attribute
type or its subtypes and contains a language tag option matching the
language range option are to be returned.
Thus for example a filter of an equality match of type "name;lang-en-"
and assertion value "Billy Ray", against the following directory entry
Thus, for example, a filter of an equality match of type
"name;lang-en-" and assertion value "Billy Ray", against the following
directory entry:
dn: SN=Ray,DC=example,DC=com
objectclass: top DOES NOT MATCH (wrong type)
objectclass: person DOES NOT MATCH (wrong type)
objectclass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
@ -549,7 +531,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
SN: Ray DOES NOT MATCH (no lang-,
wrong value)
(Note that "CN" and "SN" are subtypes of "name".)
Note that "CN" and "SN" are subtypes of "name".
If the server does not support storing attributes with language tag
options in the DIT, then any assertion which includes a language range
@ -558,16 +540,11 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
evaluate to FALSE and all other assertions to Undefined.
Zeilenga Language Tags and Ranges in LDAP [Page 10]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
3.2. Requested Attributes in Search
Clients can provide language range options in AttributeDescription in
the requested attribute list in a search request.
Clients can provide language range options in each
AttributeDescription in the requested attribute list in a search
request.
If a language range option is provided in an attribute description,
then only attributes in a directory entry whose attribute descriptions
@ -578,7 +555,15 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
nor "name;lang-fr".
Clients can provide in the attribute list multiple
AttributeDescription which have the same base attribute type but
AttributeDescriptions which have the same base attribute type but
Zeilenga Language Tags and Ranges in LDAP [Page 10]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
different options. For example a client could provide both
"name;lang-en-" and "name;lang-fr-", and this would permit an
attribute whose type was name or subtype of name and with a language
@ -599,8 +584,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
is no attribute in the entry with the same subtype and a matching
language tag option, the noSuchAttributeType error will be returned.
Thus for example a compare request of type "name;lang-" and assertion
value "Johann", against the entry with the following attributes:
Thus, for example, a compare request of type "name;lang-" and
assertion value "Johann", against the entry with the following
attributes:
objectclass: top
objectclass: person
@ -612,14 +598,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
range option "lang-" matches any language tag option.)
However, if the client issued a compare request of type "name;lang-de"
Zeilenga Language Tags and Ranges in LDAP [Page 11]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
and assertion value "Sibelius" against the above entry, the request
would fail with the noSuchAttributeType error.
@ -632,13 +610,22 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
4. Discovering Language Option Support
A server SHOULD indicate that it supports storing attributes with
language tag options in the DIT by publishing OID.TDB as a value of
the supportedFeatures [FEATURES] attribute in the root DSE.
language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4
as a value of the "supportedFeatures" [FEATURES] attribute in the root
Zeilenga Language Tags and Ranges in LDAP [Page 11]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
DSE.
A server SHOULD indicate that it supports language range matching of
attributes with language tag options stored in the DIT by publishing
OID.TDB as a value of the supportedFeatures [FEATURES] attribute in
the root DSE.
1.3.6.1.4.1.4203.1.5.5 as a value of the "supportedFeatures"
[FEATURES] attribute in the root DSE.
A server MAY restrict use of language tag options to a subset of the
attribute types it recognizes. This document does not define a
@ -653,51 +640,96 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
fulfill the user's language needed. These options are not known to
raise specific security considerations. However, the reader should
consider general directory security issues detailed in the LDAP
technical specification [Roadmap].
technical specification [RFC3377].
6. Acknowledgments
6. IANA Considerations
This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
The OIDs 1.3.6.1.4.1.4203.1.5.4 and 1.3.6.1.4.1.4203.1.5.5 identify
the features described above. These OIDs were assigned [ASSIGN] by
OpenLDAP Foundation, under its IANA-assigned private enterprise
allocation [PRIVATE], for use in this specification.
This document borrows from a number of IETF documents including BCP
47.
Registration of these protocol mechanisms [RFC3383] is requested.
Subject: Request for LDAP Protocol Mechanism Registration
7. Normative References
Object Identifier: 1.3.6.1.4.1.4203.1.5.4
Description: Language Tag Options
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Object Identifier: 1.3.6.1.4.1.4203.1.5.5
Description: Language Range Options
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
Specification: RFCxxxx
Author/Change Controller: IESG
Zeilenga Language Tags and Ranges in LDAP [Page 12]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Comments: none
7. Acknowledgments
This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
This document also borrows from a number of IETF documents including
BCP 47 by H. Alvestrand.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47 (also RFC 3066), January 2001.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Models] K. Zeilenga (editor), "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
8. Informative References
9. Informative References
[X.501] "The Directory: Models", ITU-T Recommendation X.501, 1997.
[X.501] ITU, "The Directory: Models", ITU-T Recommendation X.501,
1997.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
Zeilenga Language Tags and Ranges in LDAP [Page 13]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Appendix A. Differences from RFC 2596
@ -719,19 +751,13 @@ Appendix B. Differences from X.500(1997)
matches a value in the directory without a language code.
b) LDAP references BCP 47 [RFC3066], which allows for IANA
registration of new tags as well as unregistered tags.
c) LDAP supports language ranges.
c) LDAP supports language ranges (new in this revision).
d) LDAP does not allow language tags (and ranges) in distinguished
names.
e) X.500 describes subschema administration procedures to allow
language codes to be associated with particular attributes types.
Zeilenga Language Tags and Ranges in LDAP [Page 13]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
@ -754,6 +780,14 @@ Copyright 2002, The Internet Society. All Rights Reserved.
"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
Zeilenga Language Tags and Ranges in LDAP [Page 14]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
@ -783,5 +817,27 @@ Copyright 2002, The Internet Society. All Rights Reserved.
Zeilenga Language Tags and Ranges in LDAP [Page 14]
Zeilenga Language Tags and Ranges in LDAP [Page 15]

184
doc/drafts/draft-zeilenga-ldap-t-f-xx.txt
View file

@ -6,12 +6,12 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 3 May 2003
Expires in six months 25 October 2003
LDAP Absolute True and False Filters
<draft-zeilenga-ldap-t-f-05.txt>
<draft-zeilenga-ldap-t-f-07.txt>
Status of this Memo
@ -22,9 +22,9 @@ Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions Working Group
mailing list <ldapext@ietf.org>. Please send editorial comments
directly to the author <Kurt@OpenLDAP.org>.
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -39,10 +39,10 @@ Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please 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
@ -57,10 +57,10 @@ Abstract
Zeilenga LDAP True & False Filters [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
1. Background and Intended Use
1. Background
The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
True and False assertions. An 'and' filter with zero elements always
@ -69,17 +69,21 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
specific Entries (DSEs) which do not necessarily have 'objectClass'
attributes. That is, where "(objectClass=*)" may evaluate to False.
While LDAPv2 [RFC1777] placed no restriction on the number of elements
in 'and' and 'or' filter sets, the LDAPv2 string representation
[RFC1960] could not represent empty 'and' and 'or' filter sets. Due
to this, absolute True or False filters were (unfortunately)
eliminated from LDAPv3 [RFC3377].
While LDAPv2 [RFC1777][RFC3494] placed no restriction on the number of
elements in 'and' and 'or' filter sets, the LDAPv2 string
representation [RFC1960] could not represent empty 'and' and 'or'
filter sets. Due to this, absolute True or False filters were
(unfortunately) eliminated from LDAPv3 [RFC3377].
This documents extends LDAPv3 to support absolute True and False
matches by allowing empty 'and' and 'or' in Search filters [RFC2251]
and extends the filter string representation [RFC2254] to allow empty
filter lists.
This feature is intended to allow a more direct mapping between DAP
and LDAP (as needed to implement DAP-to-LDAP gateways).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
@ -97,25 +101,26 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
False. This filter is represented by the string "(|)".
Servers supporting this feature SHOULD publish the Object Identifier
1.3.6.1.4.1.4203.1.5.3 as a value of the supportedFeatures [FEATURES]
attribute in the root DSE.
(OID) 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
[FEATURES] attribute in the root DSE.
Clients supporting this feature SHOULD NOT use the feature unless they
have knowledge the server supports it.
Zeilenga LDAP True & False Filters [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
3. Security Considerations
The (re)introduction of absolute True and False filters is not
believed to raise any new security considerations.
Zeilenga LDAP True & False Filters [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
Implementors of this (or any) LDAPv3 extension should be familiar with
general LDAPv3 security considerations [RFC3377].
@ -135,7 +140,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
Specification: RFCxxxx
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
@ -149,58 +154,102 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
6. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2254] T. Howes, "A String Representation of LDAP Search Filters",
RFC 2254, December 1997.
[RFC2254] Howes, T., "A String Representation of LDAP Search
Filters", RFC 2254, December 1997.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Zeilenga LDAP True & False Filters [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[FEATURES] Zeilenga, K., "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt, a work in progress.
7. Informative References
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol", RFC 1777, March 1995.
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol", RFC 1777, March 1995.
[RFC1960] T. Howes, "A String Representation of LDAP Search Filters",
RFC 1960, June 1996.
[RFC1960] Howes, T., "A String Representation of LDAP Search
Filters", RFC 1960, June 1996.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
version 2 (LDAPv2) to Historic Status", RFC 3494, March
2003.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 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).
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
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
Zeilenga LDAP True & False Filters [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
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
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,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
@ -211,17 +260,24 @@ Copyright 2003, The Internet Society. All Rights Reserved.
copyrights defined in the Internet Standards process must be followed,
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.
Zeilenga LDAP True & False Filters [Page 4]
Zeilenga LDAP True & False Filters [Page 5]

1123
doc/drafts/draft-zeilenga-ldap-user-schema-xx.txt
View file

File diff suppressed because it is too large Load diff

192
doc/drafts/draft-zeilenga-ldap-uuid-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 11 May 2003
Expires in six months 25 October 2003
The LDAP entryUUID operational attribute
<draft-zeilenga-ldap-uuid-00.txt>
<draft-zeilenga-ldap-uuid-02.txt>
Status of this Memo
@ -21,9 +21,9 @@ Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extension Working Group
mailing list <ldapext@ietf.org>. Please send editorial comments
directly to the author <Kurt@OpenLDAP.org>.
document will take place on the IETF LDAP Extensions mailing list
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -55,9 +55,9 @@ Abstract
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 1]
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 1]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
INTERNET-DRAFT LDAP entryUUID 25 October 2003
1. Background and Intended Use
@ -69,11 +69,11 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
DN which previously identified another (now renamed or deleted)
object.
This document describes the 'entryUUID' operational attribute holds
the Universally Unique Identifier (UUID) [ISO11578] assigned to the
object by the server. Clients may use this attribute to distinguish
objects identified by a distinguished name or to locate an object
after renaming.
This document describes the 'entryUUID' operational attribute which
holds the Universally Unique Identifier (UUID) [ISO11578] assigned to
the object by the server. Clients may use this attribute to
distinguish objects identified by a distinguished name or to locate an
object after renaming.
This document defines the UUID syntax, the 'uuidMatch' and
'uuidOrderingMatch' matching rules, the 'entryUUID' attribute type.
@ -91,32 +91,42 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
2.1 UUID Syntax
A Universally Unique Identifier (UUID) [ISO11578] is a 16-octet value
which identifies object. The ASN.1 [X.690] type UUID is defined to
represent UUIDs.
A Universally Unique Identifier (UUID) [ISO11578] is a 16-octet
(128-bit) value which identifies an object. The ASN.1 [X.690] type
UUID is defined to represent UUIDs.
UUID ::= OCTET STRING{16} -- constrained to an UUID [ISO 11578]
UUID ::= OCTET STRING (SIZE(16))
-- constrained to an UUID [ISO 11578]
In LDAP, values of the UUID are encoded using the string
representation described in [ISO11578]. For example,
597ae2f6-16a6-1027-98f4-d28b5365dc14.
In LDAP, values of the UUID type are encoded using the [ASCII]
character string representation described in [ISO11578]. For example,
"597ae2f6-16a6-1027-98f4-d28b5365dc14".
The following is a LDAP syntax description [RFC2252] suitable for
publication in the subschema.
( IANA-ASSIGNED-OID.1 DESC 'UUID' )
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 2]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
2.2 'uuidMatch' Matching Rule
The 'uuidMatch' matching rule compares an asserted UUID with a stored
UUID for equality. Its semantics are same as octetStringMatch
UUID for equality. Its semantics are same as the octetStringMatch
[X.520][RFC2252] matching rule. The rule differs from
octetStringMatch in that the assertion value is encoded using the UUID
string representation instead of the normal OCTET STRING string
representation.
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 2]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
[X.520][RFC2252].
The following is a LDAP matching rule description [RFC2252] suitable
for publication in the subschema.
( IANA-ASSIGNED-OID.2 NAME 'uuidMatch'
SYNTAX IANA-ASSIGNED-OID.1 )
@ -125,22 +135,43 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
2.3 'uuidOrderingMatch' Matching Rule
The 'uuidOrderingMatch' matching rule compares an asserted UUID
with a stored UUID for ordering. Its semantics are the same as
octetStringOrderingMatch [X.520][RFC2252].
with a stored UUID for ordering. Its semantics are the same as the
octetStringOrderingMatch [X.520][RFC2252] matching rule. The rule
differs from octetStringOrderingMatch in that the assertion value
is encoded using the UUID string representation instead of the
normal OCTET STRING string representation.
The following is a LDAP matching rule description [RFC2252] suitable
for publication in the subschema.
( IANA-ASSIGNED-OID.3 NAME 'uuidMatch'
SYNTAX IANA-ASSIGNED-OID.1 )
It is noted that not all UUID variants have a defined ordering and,
even where so, servers are not obligated to assign UUIDs in any
particular order. This matching rule is provided for completeness.
2.4. 'entryUUID' attribute
The 'entryUUID' operational attribute provides the Universally Unique
Identifier (UUID) [ISO11578] assigned to the entry.
The following is a LDAP attribute type description [RFC2252] suitable
for publication in the subschema.
( IANA-ASSIGNED-OID.4 NAME 'entryUUID'
DESC 'UUID of the entry'
EQUALITY uuidMatch
ORDERING uuidOrderingMatch
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 3]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
SYNTAX IANA-ASSIGNED-OID.1
SINGLE-VALUE
NO-USER-MODIFICATION
@ -164,14 +195,6 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
4.1. Object Identifier Registration
It is requested that IANA register upon Standards Action an LDAP
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 3]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
Object Identifier for use in this technical specification.
Subject: Request for LDAP OID Registration
@ -198,6 +221,13 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
Author/Change Controller: IESG
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 4]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
4.3. Registration of the uuidOrderingMatch descriptor
It is requested that IANA register upon Standards Action the LDAP
@ -220,14 +250,6 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): entryUUID
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 4]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
Object Identifier: IANA-ASSIGNED-OID.4
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
@ -239,7 +261,8 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
5. Acknowledgments
This document is based upon discussions in the LDAP Update and
Duplication Protocols (LDUP) WG.
Duplication Protocols (LDUP) WG. Members of the concluded LDAP
Extensions (LDAPEXT) Working Group provided review.
6. Author's Address
@ -254,6 +277,13 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 5]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
@ -266,6 +296,9 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
"Information technology - Open Systems Interconnection -
Remote Procedure Call", ISO/IEC 11578:1996.
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
@ -276,14 +309,6 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
ISO/IEC 9594-6:1994).
[X.680] International Telecommunication Union -
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 5]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
@ -294,16 +319,27 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[UUIDinfo] The Open Group, "Universally Unique Identifier" section
of "CDE 1.1: Remote Procedure Calls",
<http://www.opengroup.org/onlinepubs/9629399/apdxa.htm>,
April 1997.
[UUIDinfo] The Open Group, "Universally Unique Identifier" appendix
of the CAE Specification "DCE 1.1: Remote Procedure
Calls", Document Number C706,
<http://www.opengroup.org/products/publications/catalog/c706.htm>
(appendix available at:
<http://www.opengroup.org/onlinepubs/9629399/apdxa.htm>),
August 1997.
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 6]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
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
@ -332,14 +368,6 @@ Full Copyright
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 6]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
@ -363,33 +391,5 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 7]
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 7]

1011
doc/drafts/draft-zeilenga-ldapext-vlv-xx.txt
View file

File diff suppressed because it is too large Load diff