upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2026-01-21 22:34:08 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update drafts

Browse source
This commit is contained in:
Kurt Zeilenga 2003-05-31 22:47:07 +00:00
parent 412f510868
commit 304410c7a0
34 changed files with 25285 additions and 4253 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

File diff suppressed because it is too large Load diff

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

@ -0,0 +1,731 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 4 May 2003
Obsoletes: 2253
LDAP: String Representation of Distinguished Names
<draft-ietf-ldapbis-dn-10.txt>
Status of Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
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
<ietf-ldapbis@openldap.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
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
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.
Abstract
The X.500 Directory uses distinguished names (DNs) as primary keys to
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.
Conventions
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].
1. Background and Intended Usage
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].
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.
It is important to have a common format to be able to unambiguously
represent a distinguished name. The primary goal of this
specification is ease of encoding and decoding. A secondary goal is
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).
This document defines the string representation of Distinguished Names
used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
algorithm for converting a DN from its ASN.1 structured representation
to a string. Section 3 details how to convert a DN from a string to a
ASN.1 structured representation.
While other documents may define other algorithms for converting a DN
from its ASN.1 structured representation to a string, all algorithms
MUST produce strings which adhere to the requirements of Section 3.
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].
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.
This specification assumes familiarity with X.500 [X.500], and the
concept of Distinguished Name [X.501][Models].
2. Converting DistinguishedName from ASN.1 to a String
X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
name. The following is a variant provided for discussion purposes.
DistinguishedName ::= RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
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
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
LDAP implementations.
2.1. Converting the RDNSequence
If the RDNSequence is an empty sequence, the result is the empty or
zero length string.
Otherwise, the output consists of the string encodings of each
RelativeDistinguishedName in the RDNSequence (according to Section
2.2), starting with the last element of the sequence and moving
backwards toward the first.
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.
Where there is a multi-valued RDN, the outputs from adjoining
AttributeTypeAndValues are separated by a plus sign ("+" U+002B)
character.
2.3. Converting AttributeTypeAndValue
The AttributeTypeAndValue is encoded as the string representation of
the AttributeType, followed by an equals ("=" U+003D) character,
followed by the string representation of the AttributeValue. The
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
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
mechanism to allow its knowledge of registered short names to be
updated.
2.4. Converting an AttributeValue from ASN.1 to a String
If the AttributeType is of the dotted-decimal form, the AttributeValue
is represented by an number sign ("#" U+0023) character followed by
the hexadecimal encoding of each of the octets of the BER encoding of
the X.500 AttributeValue. This form is also used when the syntax of
the AttributeValue does not have a native string encoding defined for
it or the native string encoding is not restricted to UTF-8 encoded
UCS (or a subset of UCS) characters. This form may also be used in
other cases, such as when a reversible string representation is
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
- a space (" " U+0020) or number sign ("#" U+0023) occurring at
the beginning of the string;
- a space (" " U+0020) character occurring at the end of the
string;
- one of the characters """, "+", ",", ";", "<", ">", or "\"
(U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C
respectively);
- the null (U+0000) character.
Other characters may be escaped.
Each octet of the character to be escaped is replaced by a backslash
and two hex digits, which form a single octet in the code of the
character. Alternatively, if and only if the character to be escaped
is one of
" ", """, "#", "+", ",", ";", "<", "=", ">", or "\"
(U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
U+003C, U+003D, U+003E, U+005C respectively)
it can be prefixed by a backslash ("\" U+0005C).
Examples of the escaping mechanism are shown in Section 4.
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
(UCS) [ISO10646]. The structure of this string representation is
specified using the following Augmented BNF [RFC2234] grammar:
distinguishedName = [ relativeDistinguishedName
*( COMMA relativeDistinguishedName ) ]
relativeDistinguishedName = attributeTypeAndValue
*( PLUS attributeTypeAndValue )
attributeTypeAndValue = attributeType EQUALS attributeValue
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)
[ *( stringchar / pair ) ( trailchar / pair ) ] ]
leadchar = LUTF1 / UTFMB
LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
trailchar = TUTF1 / UTFMB
TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
stringchar = SUTF1 / UTFMB
SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
pair = ESC ( ESC / special / hexpair )
special = escaped / SPACE / SHARP / EQUALS
escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
hexstring = SHARP 1*hexpair
hexpair = HEX HEX
where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
<EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
<SPACE>, <SHARP>, <UTFMB> are defined in [Models].
Each <attributeType>, either a <descr> or a <numericoid>, refers to an
attribute type of an attribute value assertion (AVA). The
<attributeType> is followed by a <EQUALS> and an <attributeValue>.
The <attributeValue> is either in <string> or <hexstring> form.
If in <string> form, a LDAP string representation asserted value can
be obtained by replacing (left-to-right, non-recursively) each <pair>
appearing in the <string> as follows:
replace <ESC><ESC> with <ESC>;
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
relative distinguished name.
Zero or more relative distinguished names, separated by <COMMA>, for a
distinguished name.
Implementations MUST recognize AttributeType name strings
(descriptors) listed in the following table, but MAY recognize other
name strings.
String X.500 AttributeType
------ --------------------------------------------
CN commonName (2.5.4.3)
L localityName (2.5.4.7)
ST stateOrProvinceName (2.5.4.8)
O organizationName (2.5.4.10)
OU organizationalUnitName (2.5.4.11)
C countryName (2.5.4.6)
STREET streetAddress (2.5.4.9)
DC domainComponent (0.9.2342.19200300.100.1.25)
UID userId (0.9.2342.19200300.100.1.1)
Implementations MAY recognize other DN string representations
(such as that described in RFC 1779). However, as there is no
requirement that alternative DN string representations to be
recognized (and, if so, how), implementations SHOULD only generate
DN strings in accordance with Section 2 of this document.
4. Examples
This notation is designed to be convenient for common forms of
name. This section gives a few examples of distinguished names
written using this notation. First is a name containing three
relative distinguished names (RDNs):
UID=jsmith,DC=example,DC=net
Here is an example name containing three RDNs, in which the first
RDN is multi-valued:
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
character:
CN=Before\0dAfter,DC=example,DC=net
An example name in which an RDN was of an unrecognized type. The
value is the BER encoding of an OCTET STRING containing two octets
0x48 and 0x69.
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
Finally, an example of an RDN commonName value consisting of 5
letters:
Unicode Letter Description UCS code UTF-8 Escaped
------------------------------- -------- ------ --------
LATIN CAPITAL LETTER L U+004C 0x4C L
LATIN SMALL LETTER U U+0075 0x75 u
LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
LATIN SMALL LETTER I U+0069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
could be written in printable ASCII (useful for debugging purposes):
CN=Lu\C4\8Di\C4\87
5. Security Considerations
The following security considerations are specific to the handling of
distinguished names. LDAP security considerations are discussed in
[Protocol] and other documents comprising the LDAP Technical
Specification [Roadmap].
5.1. Disclosure
Distinguished Names typically consist of descriptive information about
the entries they name, which can be people, organizations, devices or
other real-world objects. This frequently includes some of the
following kinds of information:
- 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
5.2. Use of Distinguished Names in Security Applications
The transformations of an AttributeValue value from its X.501 form to
an LDAP string representation are not always reversible back to the
same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules)
form. An example of a situation which requires the DER form of a
distinguished name is the verification of an X.509 certificate.
For example, a distinguished name consisting of one RDN with one AVA,
in which the type is commonName and the value is of the TeletexString
choice with the letters 'Sam' would be represented in LDAP as the
string CN=Sam. Another distinguished name in which the value is still
'Sam' but of the PrintableString choice would have the same
representation CN=Sam.
Applications which require the reconstruction of the DER form of the
value SHOULD NOT use the string representation of attribute syntaxes
when converting a distinguished name to the LDAP format. Instead,
they SHOULD use the hexadecimal form prefixed by the number sign ('#')
as described in the first paragraph of Section 2.3.
6. Acknowledgment
This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
This document is a product of the IETF LDAPBIS Working Group.
7. Document Editor's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
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
Zeilenga LDAP: Distinguished Names [Page 9]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
Specifications: ABNF", RFC 2234, November 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[Models] K. Zeilenga (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
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.
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC
10646-1 : 1993.
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.
Zeilenga LDAP: Distinguished Names [Page 10]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
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
section discusses presentation issues associated with non-translated
DN strings. Presentation of translated DN strings issues are not
discussed in this appendix. Transcoding issues are also not discussed
in this appendix.
This appendix provides guidance for applications presenting DN strings
to users. This section is not comprehensive, it does not discuss all
presentation issues which implementors may face.
Not all user interfaces are capable of displaying the full set of UCS
characters. Some UCS characters are not displayable.
It is recommended that human interfaces use the optional hex pair
escaping mechanism (Section 2.3) to produce a string representation
suitable for display to the user. For example, an application can
generate a DN string for display which escapes all non-printable
characters appearing in the AttributeValue's string representation (as
demonstrated in the final example of Section 4).
When a DN string is displayed in free form text, it is often necessary
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
Section 3 will note that characters "<" (U+003C) and ">" (U+003E) may
only appear in the DN string if escaped. These characters are
intended to be used in free form text to distinguish a DN string from
surrounding text. For example, <CN=Sam\ > distinguished the string
representation of the DN comprised of one RDN consisting of the AVA:
the commonName (CN) value "Sam " from the surrounding text. It should
be noted to the user that the wrapping "<" and ">" characters are not
part of the DN string.
DN strings can be quite long. It is often desirable to line-wrap
overly long DN strings in presentations. Line wrapping should be done
by inserting white space after the RDN separator character or, if
necessary, after the AVA separator character. It should be noted to
the user that the inserted white space is not part of the DN string
and is to be removed before use in LDAP. For example,
The following DN string is long:
CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
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.
Another alternative is to use the LDAP Data Interchange Format (LDIF)
[RFC2849]. For example,
# This entry has a long DN...
dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
CN: Kurt D. Zeilenga
SN: Zeilenga
objectClass: person
Appendix B. Changes made since RFC 2253
This appendix is provided for informational purposes only, it is not a
normative part of this specification.
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
canonical string representation.
- 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
and clarified escaping for when multiple octet UTF-8 characters
are present.
- Rewrote Section 3 to use ABNF as defined in RFC 2234.
- Rewrote Section 3 ABNF to be consistent with 2.4.
- Updated Section 3 to describe how to parse elements of the
grammar.
- Rewrote examples.
- Added reference to documentations containing general LDAP security
considerations.
- 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.
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
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
Internet organizations, except as needed for the purpose of
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.
Zeilenga LDAP: Distinguished Names [Page 13]

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

@ -0,0 +1,675 @@
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
LDAP: String Representation of Search Filters
<draft-ietf-ldapbis-filter-04.txt>
1. Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Discussion of this document should take place on the LDAP (v3)
Revision (ldapbis) Working Group mailing list <ietf-
ldapbis@openldap.org>.
Copyright (C) The Internet Society (2003). All Rights Reserved.
2. Abstract
LDAP search filters are transmitted in the LDAP protocol using a
binary representation that is appropriate for use on the network.
This document defines a human-readable string representation of LDAP
search filters that is appropriate for use in LDAP URLs and in other
applications.
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
3. Table of Contents
1. Status of this Memo............................................1
2. Abstract.......................................................1
3. Table of Contents..............................................2
4. Introduction...................................................2
5. LDAP Search Filter Definition..................................2
6. String Search Filter Definition................................4
7. Examples.......................................................5
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
4. Introduction
The Lightweight Directory Access Protocol (LDAP) [Protocol] defines a
network representation of a search filter transmitted to an LDAP
server. Some applications may find it useful to have a common way of
representing these search filters in a human-readable form; LDAP URLs
are an example of one such application. This document defines a
human-readable string format for representing the full range of
possible LDAP version 3 search filters, including extended match
filters.
This document is an integral part of the LDAP Technical
Specification [Roadmap].
This document replaces RFC 2254. Changes to RFC 2254 are summarized
in Appendix A.
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].
5. LDAP Search Filter Definition
An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as
follows:
Smith & Howes Intended Category: Standards Track [Page 2]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF Filter,
or [1] SET SIZE (1..MAX) OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- at least one must be present,
-- initial and final can occur at most once
substrings SEQUENCE OF CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue } }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
AttributeDescription ::= LDAPString
-- Constrained to attributedescription
-- [Models]
AttributeValue ::= OCTET STRING
MatchingRuleId ::= LDAPString
AssertionValue ::= OCTET STRING
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- ISO 10646 characters
where the LDAPString above is limited to the UTF-8 encoding [RFC2279]
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
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
STRING have the form defined in [Syntaxes]. The Filter is encoded
for transmission over a network using the Basic Encoding Rules
defined in [ASN.1], with simplifications described in [Protocol].
6. String Search Filter Definition
The string representation of an LDAP search filter is a string of
UTF-8 encoded ISO 10646-1 characters that is defined by the following
grammar, following the ABNF notation defined in [RFC2234]. The
productions used that are not defined here are defined in section 1.3
(Common ABNF Productions) of [Models] unless otherwise noted. The
filter format uses a prefix notation.
filter = LPAREN filtercomp RPAREN
filtercomp = and / or / not / item
and = AMPERSAND filterlist
or = VERTBAR filterlist
not = EXCLAMATION filter
filterlist = 1*filter
item = simple / present / substring / extensible
simple = attr filtertype assertionvalue
filtertype = equal / approx / greater / less
equal = EQUALS
approx = TILDE EQUALS
greater = RANGLE EQUALS
less = LANGLE EQUALS
extensible = attr [dnattrs] [matchingrule] COLON EQUALS assertionvalue
/ [dnattrs] matchingrule COLON EQUALS assertionvalue
/ COLON EQUALS assertionvalue
present = attr EQUALS ASTERIX
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
any = ASTERIX *(assertionvalue ASTERIX)
final = assertionvalue
attr = attributedescription
; The attributedescription rule is defined in
; Section 2.5 of [Models].
dnattrs = COLON "dn"
matchingrule = COLON oid
assertionvalue = valueencoding
; The <valueencoding> rule is used to encode an
; <AssertionValue> from Section 4.1.6 of [Protocol].
valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
; RPAREN, ASTERIX, and ESC.
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
EXCLAMATION = %x21 ; exclamation mark ("!")
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
ASTERIX = %x2A ; asterix ("*")
COLON = %x3A ; colon (":")
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
TILDE = %x7E ; tilde ("~")
Note that although both the <substring> and <present> productions in
the grammar above can produce the "attr=*" construct, this construct
is used only to denote a presence filter.
The <valueencoding> rule ensures that the entire filter string is a
valid UTF-8 string and provides that the octets that represent the
ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
representing the value of the encoded octet.
This simple escaping mechanism eliminates filter-parsing ambiguities
and allows any filter that can be represented in LDAP to be
represented as a NUL-terminated string. Other octets that are part of
the <normal> set may be escaped using this mechanism, for example,
non-printing ASCII characters.
For AssertionValues that contain UTF-8 character data, each octet of
the character to be escaped is replaced by a backslash and two hex
digits, which form a single octet in the code of the character.
For example, the filter checking whether the "cn" attribute contained
a value with the character "*" anywhere in it would be represented as
"(cn=*\2a*)".
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.
7. Examples
This section gives a few examples of search filters written using
this notation.
(cn=Babs Jensen)
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*)
(seeAlso=)
The following examples illustrate the use of extensible matching.
(cn:1.2.3.4.5:=Fred Flintstone)
(cn:=Betty Rubble)
(sn:dn:2.4.6.8.10:=Barney Rubble)
(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".
The second example demonstrates use of a MatchingRuleAssertion form
without a matchingRule.
The third example illustrates the use of the ":dn" notation to
indicate that matching rule "2.4.6.8.10" should be used when making
comparisons, and that the attributes of an entry's distinguished name
should be considered part of the entry when evaluating the match.
The fourth example denotes an equality match, except that DN
components should be considered part of the entry when doing the
match.
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 following examples illustrate the use of the escaping mechanism.
(o=Parens R Us \28for all your parenthetical needs\29)
(cn=*\2A*)
(filename=C:\5cMyFile)
(bin=\00\00\00\04)
(sn=Lu\c4\8di\c4\87)
(1.3.6.1.4.1.1466.0=\04\02\48\69)
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 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.
The fourth example shows a filter searching for the four-byte value
0x00000004, illustrating the use of the escaping mechanism to
represent arbitrary data, including NUL characters.
The fifth example illustrates the use of the escaping mechanism to
represent various non-ASCII UTF-8 characters.
The sixth and final example demonstrates assertion of a BER encoded
value.
8. Security Considerations
This memo describes a string representation of LDAP search filters.
While the representation itself has no known security implications,
LDAP search filters do. They are interpreted by LDAP servers to
select entries from which data is retrieved. LDAP servers should
take care to protect the data they maintain from unauthorized access.
Please refer to the Security Considerations sections of [Protocol]
and [AuthMeth] for more information.
9. Normative References
[ASN.1] Specification of ASN.1 encoding rules: Basic, Canonical, and
Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms", draft-ietf-ldapbis-authmeth-
xx.txt, a work in progress.
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 1993.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-
ietf-ldapbis-protocol-xx.txt, a work in progress.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 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.
10. Informative References
None.
11. Acknowledgments
This document replaces RFC 2254 by Tim Howes. Changes included in
this revised specification are based upon discussions among the
authors, discussions within the LDAP (v3) Revision Working Group
(ldapbis), and discussions within other IETF Working Groups. The
contributions of individuals in these working groups is gratefully
acknowledged.
12. Authors' Address
Mark Smith, Editor
Netscape Communications Corp.
360 W. Caribbean Drive
Sunnyvale, CA 94089
USA
+1 650 937-3477
mcs@netscape.com
Tim Howes
Opsware, Inc.
599 N. Mathilda Ave.
Sunnyvale, CA 94085
USA
+1 408 744-7509
howes@opsware.com
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.
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
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
Internet organizations, except as needed for the purpose of
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 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.
14. Appendix A: Changes Since RFC 2254
14.1. Technical Changes
The following technical changes were made to the contents of the
"String Search Filter Definition" section:
Added statement that the string representation is a string of UTF-8
encoded ISO 10646-1 characters.
Revised all of the ABNF to use common productions from [Models].
Replaced the "value" rule with a new "assertionvalue" rule within the
"simple", "extensible", and "substring" ("initial", "any", and
"final") rules. This matches a change made in [Syntaxes].
Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
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.
Added a third option to the "extensible" production to allow creation
of a MatchingRuleAssertion that only has a matchValue.
Added a statement about expected behavior in light of RFC 2254's lack
of a clear definition of "string representation."
14.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
IESG Note: removed note about lack of satisfactory mandatory
authentication mechanisms.
Header and "Authors' Addresses" sections: added Mark Smith as the
document editor and updated affiliation and contact information.
"Table of Contents" section: added.
Copyright: updated the year.
"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
this document (instead of RFC 1960). Added reference to the [Roadmap]
document.
"LDAP Search Filter Definition" section: made corrections to the
LDAPv3 search filter ABNF so it matches that used in [Protocol].
Clarified the definition of 'value' (now 'assertionvalue') to take
into account the fact that it is not precisely an AttributeAssertion
from [Protocol] section 4.1.6 (special handling is required for some
characters). Added a note that each octet of a character to be
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
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.
"Informative References" section: added for clarity.
"Acknowledgments" section: added.
"Appendix A: Changes Since RFC 2254" section: added.
"Appendix B: Changes Since Previous Document Revision" section:
added.
15. 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
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
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.
Smith & Howes Intended Category: Standards Track [Page 12]

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

File diff suppressed because it is too large Load diff

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

File diff suppressed because it is too large Load diff

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

@ -0,0 +1,283 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 1 March 2003
Obsoletes: RFC 2251-2256, 2829-2830, 3377
LDAP: Technical Specification Road Map
<draft-ietf-ldapbis-roadmap-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.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
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
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.
Abstract
The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in
accordance with X.500 data and service models. This document provides
a roadmap of the LDAP Technical Specification.
Zeilenga LDAP: TS Road Map [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
Conventions
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].
1. The LDAP Technical Specification
The technical specification detailing version 3 of the Lightweight
Directory Access Protocol (LDAP), an Internet Protocol, consists of
this document and the following documents:
LDAP: Directory Information Models [Models],
LDAP: The Protocol [Protocol],
LDAP: Authentication Methods and Connection Level Security
Mechanisms [AuthMeth],
LDAP: String Representation of Distinguished Names [LDAPDN],
LDAP: String Representation of Search Filters [Filters],
LDAP: Uniform Resource Locator [LDAPURL],
LDAP: Syntaxes [Syntaxes], and
LDAP: User Schema [Schema].
The terms "LDAP" and "LDAPv3" are commonly used to informally refer to
the protocol specified by this technical specification. The LDAP
suite, as defined here, should be formally identified in other
documents by a normative reference to this document.
Extensions to LDAP may be specified in other documents. Nomenclature
denoting such combinations of LDAP-plus-extension(s) is not defined by
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.
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.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
This technical specification explicitly incorporates portions of
X.500(93). Later revisions of X.500 do not automatically apply.
3. Security Considerations
LDAP security considerations are discussed in each document comprising
the technical specification.
4. Relationship to Obsolete Specifications
This technical specification, as defined in Section 1, obsoletes
entirely the previously defined LDAP technical specification [RFC3377]
(which consists of RFC 2251-2256, RFC 2829-2830 and [RFC3377] itself).
The technical specification was significantly reorganized.
This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
[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.
[Schema] replaces the majority of RFC 2256. [LDAPDN] replaces RFC
2253. [Filters] replaces RFC 2254. [LDAPURL] replaces RFC 2255.
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
of this document details changes made to Section 3.3 of RFC 2251.
5. Acknowledgments
This document is based largely on RFC 3377 by J. Hodges and R.
Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The
document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
Kille, a product of the ASID Working Group.
This document is a product of the IETF LDAPBIS Working Group.
6. Author's Address
Kurt Zeilenga
E-mail: <kurt@openldap.org>
7. References
Zeilenga LDAP: TS Road Map [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
7.1. Normative References
[RFC2119] S. Bradner, "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.
[Models] K. Zeilenga (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.
[AuthMeth] R. Harrison (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.
[Filters] M. Smith (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.
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
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.
[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.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.
7.2. Informative References
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).
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.
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.
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
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
Internet organizations, except as needed for the purpose of
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.
Zeilenga LDAP: TS Road Map [Page 5]

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

@ -0,0 +1,955 @@
Internet-Draft Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 26 May 2003
LDAP: Internationalized String Preparation
<draft-ietf-ldapbis-strprep-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.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
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
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
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.
Zeilenga LDAPprep [Page 1]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Conventions
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].
Character names in this document use the notation for code points and
names from the Unicode Standard [Unicode]. For example, the letter
"a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
In the lists of mappings and the prohibited characters, the "U+" is
left off to make the lists easier to read. The comments for character
ranges are shown in square brackets (such as "[CONTROL CHARACTERS]")
and do not come from the standard.
Note: a glossary of terms used in Unicode can be found in [Glossary].
Information on the Unicode character encoding model can be found in
[CharModel].
1. Introduction
1.1. Background
A Lightweight Directory Access Protocol (LDAP) [Roadmap] matching rule
[Syntaxes] defines an algorithm for determining whether a presented
value matches an attribute value in accordance with the criteria
defined for the rule. The proposition may be evaluated to True,
False, or Undefined.
True - the attribute contains a matching value,
False - the attribute contains no matching value,
Undefined - it cannot be determined whether the attribute contains
a matching value or not.
For instance, the caseIgnoreMatch matching rule may be used to compare
whether the commonName attribute contains a particular value without
regard for case and insignificant spaces.
1.2. X.500 String Matching Rules
"X.520: Selected attribute types" [X.520] provides (amongst other
things) value syntaxes and matching rules for comparing values
commonly used in the Directory. These specifications are inadequate
for strings composed of characters from the Universal Character Set
(UCS) [ISO10646], a superset of Unicode [Unicode].
Zeilenga LDAPprep [Page 2]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
The caseIgnoreMatch matching rule [X.520], for example, is simply
defined as being a case insensitive comparison where insignificant
spaces are ignored. For printableString, there is only one space
character and case mapping is bijective, hence this definition is
sufficient. However, for UCS-based string types such as
universalString, this is not sufficient. For example, a case
insensitive matching implementation which folded lower case characters
to upper case would yield different different results than an
implementation which used upper case to lower case folding. Or one
implementation may view space as referring to only SPACE (U+0020), a
second implementation may view any character with the space separator
(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.
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 approach used here is a refinement of the "stringprep" [RFC3454]
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;
b) after applying the Unicode string preparation steps outlined in
"stringprep", characters insignificant to the matching rules are
removed.
Hence, preparation of 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
These steps are described in Section 2.
1.4. Relationship to the LDAP Technical Specification
This document is a integral part of the LDAP technical specification
[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
specifications defining LDAP syntaxes and/or matching rules.
1.5. Relationship to X.500
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.
2. String Preparation
The following six-step process SHALL be applied to each presented and
attribute value in preparation for string match rule evaluation.
1) Transcode
2) Map
3) Normalize
4) Prohibit
5) Check bidi
6) Insignificant Character Removal
Failure in any step is be cause the assertion to be Undefined.
The character repertoire of this process is Unicode 3.2 [Unicode].
2.1. Transcode
Each non-Unicode string value is transcoded to Unicode.
TeletexString [X.680][T.61] values are transcoded to Unicode as
described in Appendix A.
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.
2.2. Map
SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and
VARIATION SELECTORs (U+180B-180D,FF00-FE0F) code points are also
mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
mapped to nothing.
CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
(U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
All other control code points (e.g., Cc) or code points with a control
function (e.g., Cf) are mapped to nothing.
ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code points
with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or
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].
2.3. Normalize
The input string is be normalized to Unicode Form KC (compatibility
composed) as described in [UAX15].
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
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.
2.5. Check bidi
There are no bidirectional restrictions. The output string is the
input string.
2.5. Insignificant Character Removal
In this step, characters insignificant to the matching rule are to be
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
2.6.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
code points in the separator class, other than SPACE (U+0020).
The following spaces are regarded as not significant and are to be
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
not a space);
- 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:
"<SPACE><SPACE><SPACE>"
would result in the output string:
"<SPACE>".
2.6.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.
For example, removal of spaces from the Form KC 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.
2.6.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
(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
removed.
3. Security Considerations
"Preparation for International Strings ('stringprep')" [RFC3454]
security considerations generally apply to the algorithms described
here.
4. Contributors
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).
5. Acknowledgments
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
additional guidance was drawn from Unicode Technical Standards,
Technical Reports, and Notes.
6. Author's Address
Kurt Zeilenga
E-mail: <kurt@openldap.org>
7. References
7.1. Normative References
[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.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-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.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
as amended by the "Unicode Standard Annex #27: Unicode
3.1" (http://www.unicode.org/reports/tr27/) and by the
"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>,
March 2002.
[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).
[T.61] CCITT (now ITU), "Character Repertoire and Coded
Character Sets for the International Teletex Service",
T.61, 1988.
7.2. Informative References
[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.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.520] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Selected Attribute Types", X.520(1993) (also
ISO/IEC 9594-6:1994).
[Glossary] The Unicode Consortium, "Unicode Glossary",
<http://www.unicode.org/glossary/>.
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
#17, Character Encoding Model", UTR17,
<http://www.unicode.org/unicode/reports/tr17/>, August
2000.
[XMATCH] Zeilenga, K., "Internationalized String Matching Rules
for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt a
work in progress.
[RFC1345] Simonsen, K., "Character Mnemonics & Character Sets",
RFC 1345, June 1992.
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.
The transcoding algorithm is derived from the T.61-8bit definition
provided in [RFC1345]. With a few exceptions, the T.61 character
codes from x00 to x7f are equivalent to the corresponding [Unicode]
code points, and their values are left unchanged by this algorithm.
E.g. the T.61 code x20 is identical to (U+0020). The exceptions are
for these T.61 codes that are undefined: x23, x24, x5c, x5e, x60, x7b,
x7d, and x7e.
The codes from x80 to x9f are also equivalent to the corresponding
Unicode code points. This is specified for completeness only, as
these codes are control characters, and will be mapped to nothing in
the LDAP String Preparation Mapping step.
The remaining T.61 codes are mapped below in Table A.1. Table
positions marked "??" are undefined.
Input strings containing undefined T.61 codes SHALL produce an
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.
Note: RFC 1345 listed the non-spacing accent codepoints as residing in
the range starting at (U+E000). In the current Unicode
standard, the (U+E000) range is reserved for Private Use, and
the non-spacing accents are in the range starting at (U+0300).
The tables here use the (U+0300) range for these accents.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
a0| 00a0 | 00a1 | 00a2 | 00a3 | 0024 | 00a5 | 0023 | 00a7 |
a8| 00a8 | ?? | ?? | 00ab | ?? | ?? | ?? | ?? |
b0| 00b0 | 00b1 | 00b2 | 00b3 | 00d7 | 00b5 | 00b6 | 00b7 |
b8| 00f7 | ?? | ?? | 00bb | 00bc | 00bd | 00be | 00bf |
c0| ?? | 0300 | 0301 | 0302 | 0303 | 0304 | 0306 | 0307 |
c8| 0308 | ?? | 030a | 0327 | 0332 | 030b | 0328 | 030c |
d0| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
d8| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
e0| 2126 | 00c6 | 00d0 | 00aa | ?? | 0126 | 0132 | 013f |
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
T.61 also defines a number of accented characters that are formed by
combining an accent prefix followed by a base character. These
prefixes are in the code range xc1 to xcf. If a prefix character
appears at the end of a string, the result is undefined. Otherwise
these sequences are mapped to Unicode by substituting the
corresponding non-spacing accent code (as listed in Table A.1) for the
accent prefix, and exchanging the order so that the base character
precedes the accent.
Appendix B. Additional Teletex (T.61) to Unicode Tables
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.
B.1. Combinations with SPACE
Accents may be combined with a <SPACE> to generate the accent by
itself. For each accent code, the result of combining with <SPACE> is
listed in Table B.1.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
c0| ?? | 0060 | 00b4 | 005e | 007e | 00af | 02d8 | 02d9 |
c8| 00a8 | ?? | 02da | 00b8 | ?? | 02dd | 02db | 02c7 |
--+------+------+------+------+------+------+------+------+
Table B.1: Mapping of T.61 Accents with <SPACE> to Unicode
B.2. Combinations for xc1: (Grave accent)
T.61 has predefined characters for combinations with A, E, I, O, and
U. Unicode also defines combinations for N, W, and Y. All of these
combinations are present in Table B.2.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
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 |
70| ?? | ?? | ?? | ?? | ?? | 00f9 | ?? | 1e81 |
78| ?? | 1ef3 | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Table B.2: Mapping of T.61 Grave Accent Combinations
B.3. Combinations for xc2: (Acute accent)
T.61 has predefined characters for combinations with A, E, I, O, U, Y,
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.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 00c1 | ?? | 0106 | ?? | 00c9 | ?? | 01f4 |
48| ?? | 00cd | ?? | 1e30 | 0139 | 1e3e | 0143 | 00d3 |
50| 1e54 | ?? | 0154 | 015a | ?? | 00da | ?? | 1e82 |
58| ?? | 00dd | 0179 | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e1 | ?? | 0107 | ?? | 00e9 | ?? | 01f5 |
68| ?? | 00ed | ?? | 1e31 | 013a | 1e3f | 0144 | 00f3 |
70| 1e55 | ?? | 0155 | 015b | ?? | 00fa | ?? | 1e83 |
78| ?? | 00fd | 017a | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Table B.3: Mapping of T.61 Acute Accent Combinations
B.4. Combinations for xc3: (Circumflex)
T.61 has predefined characters for combinations with A, E, I, O, U, Y,
C, G, H, J, S, and W. Unicode also defines the combination for Z.
All of these combinations are present in Table B.4.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 00c2 | ?? | 0108 | ?? | 00ca | ?? | 011c |
48| 0124 | 00ce | 0134 | ?? | ?? | ?? | ?? | 00d4 |
50| ?? | ?? | ?? | 015c | ?? | 00db | ?? | 0174 |
58| ?? | 0176 | 1e90 | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e2 | ?? | 0109 | ?? | 00ea | ?? | 011d |
68| 0125 | 00ee | 0135 | ?? | ?? | ?? | ?? | 00f4 |
70| ?? | ?? | ?? | 015d | ?? | 00fb | ?? | 0175 |
78| ?? | 0177 | 1e91 | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
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
N. Unicode also defines E, V, and Y. All of these combinations are
present in Table B.5.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 00c3 | ?? | ?? | ?? | 1ebc | ?? | ?? |
48| ?? | 0128 | ?? | ?? | ?? | ?? | 00d1 | 00d5 |
50| ?? | ?? | ?? | ?? | ?? | 0168 | 1e7c | ?? |
58| ?? | 1ef8 | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e3 | ?? | ?? | ?? | 1ebd | ?? | ?? |
68| ?? | 0129 | ?? | ?? | ?? | ?? | 00f1 | 00f5 |
70| ?? | ?? | ?? | ?? | ?? | 0169 | 1e7d | ?? |
78| ?? | 1ef9 | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Table B.5: Mapping of T.61 Tilde Accent Combinations
B.6. Combinations for xc5: (Macron)
T.61 has predefined characters for combinations with A, E, I, O, and
U. Unicode also defines Y, G, and AE. All of these combinations are
present in Table B.6.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 0100 | ?? | ?? | ?? | 0112 | ?? | 1e20 |
48| ?? | 012a | ?? | ?? | ?? | ?? | ?? | 014c |
50| ?? | ?? | ?? | ?? | ?? | 016a | ?? | ?? |
58| ?? | 0232 | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 0101 | ?? | ?? | ?? | 0113 | ?? | 1e21 |
68| ?? | 012b | ?? | ?? | ?? | ?? | ?? | 014d |
70| ?? | ?? | ?? | ?? | ?? | 016b | ?? | ?? |
78| ?? | 0233 | ?? | ?? | ?? | ?? | ?? | ?? |
e0| ?? | 01e2 | ?? | ?? | ?? | ?? | ?? | ?? |
f0| ?? | 01e3 | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Table B.6: Mapping of T.61 Macron Accent Combinations
B.7. Combinations for xc6: (Breve)
T.61 has predefined characters for combinations with A, U, and G.
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 |
48| ?? | 012c | ?? | ?? | ?? | ?? | ?? | 014e |
50| ?? | ?? | ?? | ?? | ?? | 016c | ?? | ?? |
58| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 0103 | ?? | ?? | ?? | 0115 | ?? | 011f |
68| ?? | 012d | ?? | ?? | ?? | ?? | 00f1 | 014f |
70| ?? | ?? | ?? | ?? | ?? | 016d | ?? | ?? |
78| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Table B.7: Mapping of T.61 Breve Accent Combinations
B.8. Combinations for xc7: (Dot Above)
T.61 has predefined characters for C, E, G, I, and Z. Unicode also
defines A, O, B, D, F, H, M, N, P, R, S, T, W, X, and Y. All of these
combinations are present in Table B.8.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 0226 | 1e02 | 010a | 1e0a | 0116 | 1e1e | 0120 |
48| 1e22 | 0130 | ?? | ?? | ?? | 1e40 | 1e44 | 022e |
50| 1e56 | ?? | 1e58 | 1e60 | 1e6a | ?? | ?? | 1e86 |
58| 1e8a | 1e8e | 017b | ?? | ?? | ?? | ?? | ?? |
60| ?? | 0227 | 1e03 | 010b | 1e0b | 0117 | 1e1f | 0121 |
68| 1e23 | ?? | ?? | ?? | ?? | 1e41 | 1e45 | 022f |
70| 1e57 | ?? | 1e59 | 1e61 | 1e6b | ?? | ?? | 1e87 |
78| 1e8b | 1e8f | 017c | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Table B.8: Mapping of T.61 Dot Above Accent Combinations
B.9. Combinations for xc8: (Diaeresis)
T.61 has predefined characters for A, E, I, O, U, and Y. Unicode also
defines H, W, X, and t. All of these combinations are present in
Table B.9.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 00c4 | ?? | ?? | ?? | 00cb | ?? | ?? |
48| 1e26 | 00cf | ?? | ?? | ?? | ?? | ?? | 00d6 |
50| ?? | ?? | ?? | ?? | ?? | 00dc | ?? | 1e84 |
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 | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Table B.8: Mapping of T.61 Diaeresis Accent Combinations
B.10. Combinations for xca: (Ring Above)
T.61 has predefined characters for A, and U. Unicode also defines w
and y. All of these combinations are present in Table B.10.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 00c5 | ?? | ?? | ?? | ?? | ?? | ?? |
48| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
50| ?? | ?? | ?? | ?? | ?? | 016e | ?? | ?? |
58| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e5 | ?? | ?? | ?? | ?? | ?? | ?? |
68| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
70| ?? | ?? | ?? | ?? | ?? | 016f | ?? | 1e98 |
78| ?? | 1e99 | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Table B.10: Mapping of T.61 Ring Above Accent Combinations
B.11. Combinations for xcb: (Cedilla)
T.61 has predefined characters for C, G, K, L, N, R, S, and T.
Unicode also defines E, D, and H. All of these combinations are
present in Table B.11.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | ?? | ?? | 00c7 | 1e10 | 0228 | ?? | 0122 |
48| 1e28 | ?? | ?? | 0136 | 013b | ?? | 0145 | ?? |
50| ?? | ?? | 0156 | 015e | 0162 | ?? | ?? | ?? |
58| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | ?? | ?? | 00e7 | 1e11 | 0229 | ?? | 0123 |
68| 1e29 | ?? | ?? | 0137 | 013c | ?? | 0146 | ?? |
70| ?? | ?? | 0157 | 015f | 0163 | ?? | ?? | ?? |
78| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Table B.11: Mapping of T.61 Cedilla Accent Combinations
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 |
--+------+------+------+------+------+------+------+------+
48| ?? | ?? | ?? | ?? | ?? | ?? | ?? | 0150 |
50| ?? | ?? | ?? | ?? | ?? | 0170 | ?? | ?? |
68| ?? | ?? | ?? | ?? | ?? | ?? | ?? | 0151 |
70| ?? | ?? | ?? | ?? | ?? | 0171 | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Table B.12: Mapping of T.61 Double Acute Accent Combinations
B.13. Combinations for xce: (Ogonek)
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.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 0104 | ?? | ?? | ?? | 0118 | ?? | ?? |
48| ?? | 012e | ?? | ?? | ?? | ?? | ?? | 01ea |
50| ?? | ?? | ?? | ?? | ?? | 0172 | ?? | ?? |
58| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 0105 | ?? | ?? | ?? | 0119 | ?? | ?? |
68| ?? | 012f | ?? | ?? | ?? | ?? | ?? | 01eb |
70| ?? | ?? | ?? | ?? | ?? | 0173 | ?? | ?? |
78| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Table B.13: Mapping of T.61 Ogonek Accent Combinations
B.14. Combinations for xcf: (Caron)
T.61 has predefined characters for C, D, E, L, N, R, S, T, and Z.
Unicode also defines A, I, O, U, G, H, j,and K. All of these
combinations are present in Table B.14.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 01cd | ?? | 010c | 010e | 011a | ?? | 01e6 |
48| 021e | 01cf | ?? | 01e8 | 013d | ?? | 0147 | 01d1 |
50| ?? | ?? | 0158 | 0160 | 0164 | 01d3 | ?? | ?? |
58| ?? | ?? | 017d | ?? | ?? | ?? | ?? | ?? |
60| ?? | 01ce | ?? | 010d | 010f | 011b | ?? | 01e7 |
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
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
Internet organizations, except as needed for the purpose of
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.
Zeilenga LDAPprep [Page 17]

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

File diff suppressed because it is too large Load diff

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

@ -0,0 +1,731 @@
Network Working Group Mark Smith, Editor
Request for Comments: DRAFT Netscape Communications Corp.
Obsoletes: RFC 2255 Tim Howes
Expires: 28 August 2003 Opsware, Inc.
28 February 2003
LDAP: Uniform Resource Locator
<draft-ietf-ldapbis-url-03.txt>
1. Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Discussion of this document should take place on the LDAP (v3)
Revision (ldapbis) Working Group mailing list <ietf-
ldapbis@openldap.org>.
Copyright (C) The Internet Society (2003). All Rights Reserved.
2. Abstract
This document describes a format for an LDAP Uniform Resource Locator
(URL). An LDAP URL describes an LDAP search operation that is used
to retrieve information from an LDAP directory, or, in the context of
an LDAPv3 referral or reference, an LDAP URL describes a service
where an LDAP operation may be progressed.
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
3. Table of Contents
1. Status of this Memo............................................1
2. Abstract.......................................................1
3. Table of Contents..............................................2
4. Introduction...................................................2
5. URL Definition.................................................2
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
4. Introduction
LDAP is the Lightweight Directory Access Protocol, defined in
[Protocol]. This document specifies the LDAP URL format for version
3 of LDAP and clarifies how LDAP URLs are resolved. This document
also defines an extension mechanism for LDAP URLs, so that future
documents can extend their functionality, for example, to provide
access to new LDAPv3 extensions as they are defined. Note: not all
of the parameters of the LDAP search operation described in
[Protocol] can be expressed using the format defined in this
document.
This document is an integral part of the LDAP Technical Specification
[Roadmap].
This document replaces RFC 2255. See Appendix A for a list of changes
relative to RFC 2255.
The key words "MUST", "MAY", and "SHOULD" used in this document are
to be interpreted as described in [RFC2119].
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
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
dn = <distinguishedName from Section 3 of [LDAPDN]>
attributes = attrdesc *(COMMA attrdesc)
attrdesc = <AttributeDescription from Section 4.1.4 of [Protocol]>
/ ASTERIX
scope = "base" / "one" / "sub"
filter = <filter from Section 4 of [Filters]>
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid / oiddescr
exvalue = <LDAPString from section 4.1.2 of [Protocol]>
oid = <LDAPOID from section 4.1.2 of [Protocol]>
oiddescr = <name from section 3.3 of [LDAPIANA]>
EXCLAMATION = %x21 ; exclamation mark ("!")
ASTERIX = %x2A ; asterix ("*")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
SLASH = %x5C; forward slash ("/")
The "ldap" prefix indicates an entry or entries residing in the LDAP
server running on the given hostname at the given portnumber. Note
that the hostport may contain literal IPv6 addresses as specified in
[RFC2732].
The dn is an LDAP Distinguished Name using the string format
described in [LDAPDN]. It identifies the base object of the LDAP
search or the target of a non-search operation.
The attributes construct is used to indicate which attributes should
be returned from the entry or entries. Individual attrdesc names are
as defined for AttributeDescription in [Protocol].
The scope construct is used to specify the scope of the search to
perform in the given LDAP server. The allowable scopes are "base"
for a base object search, "one" for a one-level search, or "sub" for
a subtree search.
The filter is used to specify the search filter to apply to entries
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
pairs, where the =value portion MAY be omitted for options not
requiring it. Each type=value pair is a separate extension. These
LDAP URL extensions are not necessarily related to any of the LDAPv3
extension mechanisms. Extensions may be supported or unsupported by
the client resolving the URL. An extension prefixed with a '!'
character (ASCII 33) is critical. An extension not prefixed with a
'!' character is non-critical.
If an extension is supported by the client, the client MUST obey the
extension if the extension is critical. The client SHOULD obey
supported extensions that are non-critical.
If an extension is unsupported by the client, the client MUST NOT
process the URL if the extension is critical. If an unsupported
extension is non-critical, the client MUST ignore the extension.
If a critical extension cannot be processed successfully by the
client, the client MUST NOT process the URL. If a non-critical
extension cannot be processed successfully by the client, the client
SHOULD ignore the extension.
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.
No LDAP URL extensions are defined in this document. Other documents
or a future version of this document MAY define one or more
extensions.
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:
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
[RFC2396].
It is the single Reserved character '?' and occurs inside a dn,
filter, or other element of an LDAP URL.
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
absence of any other specification, the following general defaults
SHOULD be used when a field is absent. Note: other documents MAY
specify different defaulting rules; for example, section 4.1.11 of
[Protocol] specifies a different rule for determining the correct DN
to use when it is absent in an LDAP URL that is returned as a
referral.
hostport
The default LDAP port is TCP port 389. If no hostport is given,
the client must have some apriori knowledge of an appropriate LDAP
server to contact.
dn
If no dn is given, the default is the zero-length DN, "".
attributes
If the attributes part is omitted, all user attributes of the
entry or entries should be requested (e.g., by setting the
attributes field AttributeDescriptionList in the LDAP search
request to a NULL list, or (in LDAPv3) by requesting the special
attribute name "*").
scope
If scope is omitted, a scope of "base" is assumed.
filter
If filter is omitted, a filter of "(objectClass=*)" is assumed.
extensions
If extensions is omitted, no extensions are assumed.
7. Examples
The following are some example LDAP URLs using the format defined
above. The first example is an LDAP URL referring to the University
of Michigan entry, available from an LDAP server of the client's
choosing:
ldap:///o=University%20of%20Michigan,c=US
The next example is an LDAP URL referring to the University of
Michigan entry in a particular ldap server:
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.
The next example is an LDAP URL referring to only the postalAddress
attribute of the University of Michigan entry:
ldap://ldap1.example.net/o=University%20of%20Michigan,
c=US?postalAddress
The corresponding LDAP search operation is the same as in the
previous example, except that only the postalAddress attribute is
requested.
The next example is an LDAP URL referring to the set of entries found
by querying the given LDAP server on port 6666 and doing a subtree
search of the University of Michigan for any entry with a common name
of "Babs Jensen", retrieving all attributes:
ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen)
The next example is an LDAP URL referring to all children of the c=GB
entry:
ldap://ldap1.example.com/c=GB?objectClass?one
The objectClass attribute is requested to be returned along with the
entries, and the default filter of "(objectclass=*)" is used.
The next example is an LDAP URL to retrieve the mail attribute for
the LDAP entry named "o=Question?,c=US" is given below, illustrating
the use of the escaping mechanism on the reserved character '?'.
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.
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
The DN encoded in the above URL is:
o=An Example\2c Inc.,c=US
That is, the left-most RDN value is:
An Example, Inc.
The following three URLs that are equivalent, assuming that the
defaulting rules specified in section 4 of this document are used:
ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?
These three URLs all point to the root DSE on the ldap.example.net
server.
The final two examples show use of a hypothetical, experimental bind
name extension (the value associated with the extension is an LDAP DN).
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
The two URLs are the same, except that the second one marks the e-
bindname extension as critical. Notice the use of the % encoding
method to encode the commas within the distinguished name value in
the e-bindname extension.
8. Security Considerations
General URL security considerations discussed in [RFC2396] are
relevant for LDAP URLs.
The use of security mechanisms when processing LDAP URLs requires
particular care, since clients may encounter many different servers
via URLs, and since URLs are likely to be processed automatically,
without user intervention. A client SHOULD have a user-configurable
policy about which servers to connect to using which security
mechanisms, and SHOULD NOT make connections that are inconsistent
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
violate a user's privacy requirements. In the absence of specific
policy permitting authentication information to be sent to a server,
a client should use an anonymous connection. (Note that clients
conforming to previous LDAP URL specifications, where all connections
are anonymous and unprotected, are consistent with this
specification; they simply have the default security policy.) Simply
opening a connection to another server may violate some users'
privacy requirements, so clients should provide the user with a way
to control URL processing.
Some authentication methods, in particular reusable passwords sent to
the server, may reveal easily-abused information to the remote server
or to eavesdroppers in transit, and should not be used in URL
processing unless explicitly permitted by policy. Confirmation by
the human user of the use of authentication information is
appropriate in many circumstances. Use of strong authentication
methods that do not reveal sensitive information is much preferred.
If the URL represents a referral for an update operation, strong
authentication methods SHOULD be used. Please refer to the Security
Considerations section of [AuthMeth] for more information.
The LDAP URL format allows the specification of an arbitrary LDAP
search operation to be performed when evaluating the LDAP URL.
Following an LDAP URL may cause unexpected results, for example, the
retrieval of large amounts of data, the initiation of a long-lived
search, etc. The security implications of resolving an LDAP URL are
the same as those of resolving an LDAP search query.
9. Acknowledgements
The LDAP URL format was originally defined at the University of
Michigan. This material is based upon work supported by the National
Science Foundation under Grant No. NCR-9416667. The support of both
the University of Michigan and the National Science Foundation is
gratefully acknowledged.
This document is an update to RFC 2255 by Tim Howes and Mark Smith.
Changes included in this revised specification are based upon
discussions among the authors, discussions within the LDAP (v3)
Revision Working Group (ldapbis), and discussions within other IETF
Working Groups. The contributions of individuals in these working
groups is gratefully acknowledged. Several people in particular have
made valuable comments on this document; RL "Bob" Morgan, Mark Wahl,
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
Mark Smith, Editor
Netscape Communications Corp.
360 W. Caribbean Drive
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
Tim Howes
Opsware, Inc.
599 N. Mathilda Ave.
Sunnyvale, CA 94085
USA
+1 408 744-7509
howes@opsware.com
13. Full Copyright Statement
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 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
Internet organizations, except as needed for the purpose of
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 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.
14. Appendix A: Changes Since RFC 2255
14.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
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.
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].
Changed the text about extension types so it references [LDAPIANA].
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
Changed document title to include "LDAP:" prefix.
IESG Note: removed note about lack of satisfactory mandatory
authentication mechanisms.
"Status of this Memo" section: updated boilerplate to match current
I-D guidelines.
"Abstract" section: separated from introductory material.
"Table of Contents" section: added.
"Introduction" section: new section; separated from the Abstract.
Changed the text indicate that RFC 2255 is replaced by this document
(instead of RFC 1959). Added text to indicate that LDAP URLs are
used for references and referrals. Fixed typo (replaced the nonsense
phrase "to perform to retrieve" with "used to retrieve"). Added a
note to let the reader know that not all of the parameters of the
LDAP search operation described in [Protocol] can be expressed using
this format.
"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
to the ABNF from RFC 2234.
"Defaults for Fields of the LDAP URL" section: added; formed by
moving text about defaults out of the "URL Definition" section.
"URL Processing" section: clarified that connections MAY be reused
only if the open connection is compatible with the URL. Added text
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
interrogate the server to determine the most appropriate method.
"Examples" section: Modified examples to use example.com and
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.
"Security Considerations" section: Added a note about connection
reuse. Added a note about using strong authentication methods for
updates. Added a reference to RFC 2829. Added note that simply
opening a connection may violate some users' privacy requirements.
"Acknowledgements" section: added statement about this being an
update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
Hallvard Furuseth.
"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.
"Informative References" section: added for clarity.
Header and "Authors' Address" sections: added "editor" next to Mark
Smith's name. Updated affiliation and contact information.
Copyright: updated the year.
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
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
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]

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

File diff suppressed because it is too large Load diff

BIN
doc/drafts/draft-ietf-ldapext-matchedval-xx.txt
View file

Binary file not shown.

1708
doc/drafts/draft-leach-uuids-guids-xx.txt
View file

File diff suppressed because it is too large Load diff

336
doc/drafts/draft-legg-ldap-acm-admin-xx.txt
View file

@ -5,13 +5,13 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-acm-admin-01.txt Adacel Technologies
Intended Category: Standards Track September 18, 2002
draft-legg-ldap-acm-admin-02.txt Adacel Technologies
Intended Category: Standards Track February 25, 2003
Access Control Administration in LDAP
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Status of this Memo
@ -39,7 +39,7 @@ Intended Category: Standards Track September 18, 2002
to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
author.
This Internet-Draft expires on 18 March 2003.
This Internet-Draft expires on 25 August 2003.
1. Abstract
@ -55,39 +55,36 @@ Intended Category: Standards Track September 18, 2002
Legg Expires 18 March 2003 [Page 1]
Legg Expires 25 August 2003 [Page 1]
INTERNET-DRAFT Access Control Administration September 18, 2002
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 RFC 2119 [RFC2119].
INTERNET-DRAFT Access Control Administration February 25, 2003
2. Table of Contents
1. Abstract .................................................... 1
2. Table of Contents ........................................... 2
3. Introduction ................................................ 2
4. Access Control Administrative Areas ......................... 3
5. Access Control Scheme Indication ............................ 3
6. Access Control Information .................................. 4
7. Access Control Subentries ................................... 4
8. Applicable Access Control Information ....................... 5
9. Security Considerations ..................................... 5
10. Acknowledgements ........................................... 6
11. Normative References ....................................... 6
12. Informative References ..................................... 6
13. Copyright Notice ........................................... 7
14. Author's Address ........................................... 7
1. Abstract ...................................................... 1
2. Table of Contents ............................................. 2
3. Introduction .................................................. 2
4. Conventions ................................................... 2
5. Access Control Administrative Areas ........................... 3
6. Access Control Scheme Indication .............................. 3
7. Access Control Information .................................... 4
8. Access Control Subentries ..................................... 4
9. Applicable Access Control Information ......................... 5
10. Security Considerations ...................................... 6
11. Acknowledgements ............................................. 6
12. IANA Considerations .......................................... 6
13. Normative References ......................................... 7
14. Informative References ....................................... 7
15. Copyright Notice ............................................. 7
16. Author's Address ............................................. 8
3. Introduction
This document adapts the X.500 directory administrative model [X501],
as it pertains to access control administration, for use by the
Lightweight Directory Access Protocol (LDAP) [RFC2251].
Lightweight Directory Access Protocol (LDAP) [RFC3377].
The administrative model [ADMIN] partitions the Directory Information
Tree (DIT) for various aspects of directory data administration, e.g.
@ -102,25 +99,31 @@ INTERNET-DRAFT Access Control Administration September 18, 2002
employing access control schemes but does not define a particular
access control scheme. Two access control schemes known as Basic
Access Control and Simplified Access Control are defined by [BAC].
Other access control schemes MAY be defined by other documents.
Other access control schemes may be defined by other documents.
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
4. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Legg Expires 25 August 2003 [Page 2]
INTERNET-DRAFT Access Control Administration February 25, 2003
document are to be interpreted as described in RFC 2119 [RFC2119].
Schema definitions are provided using LDAP description formats
[RFC2252]. Note that the LDAP descriptions have been rendered with
additional white-space and line breaks for the sake of readability.
Legg Expires 18 March 2003 [Page 2]
INTERNET-DRAFT Access Control Administration September 18, 2002
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
4. Access Control Administrative Areas
5. Access Control Administrative Areas
The specific administrative area [ADMIN] for access control is termed
an Access Control Specific Area (ACSA). The root of the ACSA is
@ -148,7 +151,7 @@ INTERNET-DRAFT Access Control Administration September 18, 2002
Control Information (ACI).
5. Access Control Scheme Indication
6. Access Control Scheme Indication
The access control scheme (e.g. Basic Access Control [BAC]) in force
in an ACSA is indicated by the accessControlScheme operational
@ -161,19 +164,21 @@ INTERNET-DRAFT Access Control Administration September 18, 2002
( 2.5.24.1 NAME 'accessControlScheme'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
Legg Expires 25 August 2003 [Page 3]
INTERNET-DRAFT Access Control Administration February 25, 2003
SINGLE-VALUE USAGE directoryOperation )
An access control scheme conforming to the access control framework
Legg Expires 18 March 2003 [Page 3]
INTERNET-DRAFT Access Control Administration September 18, 2002
described in this document MUST define a distinct OBJECT IDENTIFIER
value to identify it through the accessControlScheme attribute.
Object Identifier Descriptors for access control scheme identifiers
may be registered with IANA [RFC3383].
Only administrative entries for ACSPs are permitted to contain an
accessControlScheme attribute. If the accessControlScheme attribute
@ -187,7 +192,7 @@ INTERNET-DRAFT Access Control Administration September 18, 2002
attribute of the ACSP.
6. Access Control Information
7. Access Control Information
There are three categories of Access Control Information (ACI):
entry, subentry and prescriptive.
@ -212,22 +217,23 @@ INTERNET-DRAFT Access Control Administration September 18, 2002
subentries are within the subtree or subtree refinement.
7. Access Control Subentries
8. Access Control Subentries
Each subentry which contains prescriptive ACI MUST have
Legg Expires 25 August 2003 [Page 4]
INTERNET-DRAFT Access Control Administration February 25, 2003
accessControlSubentry as a value of its objectClass attribute. Such
a subentry is called an access control subentry.
The LDAP description [RFC2252] for the accessControlSubentry
auxiliary object class is:
Legg Expires 18 March 2003 [Page 4]
INTERNET-DRAFT Access Control Administration September 18, 2002
( 2.5.17.1 NAME 'accessControlSubentry' AUXILIARY )
A subentry of this object class MUST contain at least one
@ -244,7 +250,7 @@ INTERNET-DRAFT Access Control Administration September 18, 2002
within a given ACSA may arbitrarily overlap.
8. Applicable Access Control Information
9. Applicable Access Control Information
Although particular items of ACI may specify attributes or values as
the protected items, ACI is logically associated with entries.
@ -270,19 +276,19 @@ INTERNET-DRAFT Access Control Administration September 18, 2002
administrative point as the subentry for which the decision is
being made.
Legg Expires 25 August 2003 [Page 5]
INTERNET-DRAFT Access Control Administration February 25, 2003
(3) Subentry ACI from the administrative point associated with the
subentry.
9. Security Considerations
Legg Expires 18 March 2003 [Page 5]
INTERNET-DRAFT Access Control Administration September 18, 2002
10. Security Considerations
This document defines a framework for employing an access control
scheme, i.e. the means by which access to directory information and
@ -296,62 +302,100 @@ INTERNET-DRAFT Access Control Administration September 18, 2002
general [ADMIN] also apply to access control administration.
10. Acknowledgements
11. Acknowledgements
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
11. Normative References
12. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to update
the LDAP descriptors registry as indicated by the following
templates:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): accessControlScheme
Object Identifier: 2.5.24.1
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Usage: attribute type
Specification: RFC XXXX
Author/Change Controller: IESG
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): accessControlSubentry
Object Identifier: 2.5.17.1
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Usage: object class
Specification: RFC XXXX
Author/Change Controller: IESG
Legg Expires 25 August 2003 [Page 6]
INTERNET-DRAFT Access Control Administration February 25, 2003
13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[ADMIN] Legg, S., "Directory Administrative Model in LDAP",
draft-legg-ldap-admin-xx.txt, a work in progress,
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[ADMIN] Legg, S., "Directory Administrative Model in LDAP",
draft-legg-ldap-admin-xx.txt, a work in progress, February
2003.
[SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
August 2002.
12. Informative References
14. Informative References
[BAC] Legg, S., "Basic and Simplified Access Control in LDAP",
draft-legg-ldap-acm-bac-xx.txt, a work in progress,
September 2002.
February 2003.
[COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
draft-zeilenga-ldap-collective-xx.txt, a work in progress,
August 2002.
Legg Expires 18 March 2003 [Page 6]
INTERNET-DRAFT Access Control Administration September 18, 2002
[X501] ITU-T Recommendation X.501 (02/2001), Information
technology - Open Systems Interconnection - The Directory:
Models
13. Copyright Notice
15. Copyright Notice
Copyright (C) The Internet Society (2002). 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
or assist in its implementation may be prepared, copied, published
Legg Expires 25 August 2003 [Page 7]
INTERNET-DRAFT Access Control Administration February 25, 2003
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
@ -374,78 +418,90 @@ INTERNET-DRAFT Access Control Administration September 18, 2002
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Author's Address
16. Author's Address
Steven Legg
Adacel Technologies Ltd.
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
250 Bay Street
Brighton, Victoria 3186
AUSTRALIA
Phone: +61 3 9451 2107
Fax: +61 3 9541 2121
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
15. Appendix A - Changes From Previous Drafts
Appendix A - Changes From Previous Drafts
Legg Expires 18 March 2003 [Page 7]
INTERNET-DRAFT Access Control Administration September 18, 2002
15.1 Changes in Draft 01
A.1 Changes in Draft 01
Section 4 has been extracted to become a separate Internet draft,
draft-legg-ldap-admin-00.txt. The subsections of Section 5 have
become the new Sections 4 to 8. Editorial changes have been made to
accommodate this split. No technical changes have been introduced.
A.2 Changes in Draft 02
RFC 3377 replaces RFC 2251 as the reference for LDAP.
Legg Expires 18 March 2003 [Page 8]
Legg Expires 25 August 2003 [Page 8]
INTERNET-DRAFT Access Control Administration February 25, 2003
An IANA Considerations section has been added.
Legg Expires 25 August 2003 [Page 9]

2411
doc/drafts/draft-legg-ldap-acm-bac-xx.txt Normal file
View file

File diff suppressed because it is too large Load diff

168
doc/drafts/draft-legg-ldap-admin-xx.txt
View file

@ -5,13 +5,13 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-admin-00.txt Adacel Technologies
Intended Category: Standards Track September 18, 2002
draft-legg-ldap-admin-01.txt Adacel Technologies
Intended Category: Standards Track February 25, 2003
Directory Administrative Model in LDAP
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Status of this Memo
@ -39,7 +39,7 @@ Intended Category: Standards Track September 18, 2002
to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
author.
This Internet-Draft expires on 18 March 2003.
This Internet-Draft expires on 25 August 2003.
1. Abstract
@ -55,46 +55,42 @@ Intended Category: Standards Track September 18, 2002
Legg Expires 18 March 2003 [Page 1]
Legg Expires 25 August 2003 [Page 1]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
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 RFC 2119 [RFC2119].
INTERNET-DRAFT Directory Administrative Model February 25, 2003
2. Table of Contents
1. Abstract .................................................... 1
2. Table of Contents ........................................... 2
3. Introduction ................................................ 2
4. Administrative Areas ........................................ 2
5. Autonomous Administrative Areas ............................. 3
6. Specific Administrative Areas ............................... 3
7. Inner Administrative Areas .................................. 4
8. Administrative Entries ...................................... 5
9. Security Considerations ..................................... 5
10. Acknowledgements ........................................... 5
11. Normative References ....................................... 5
12. Informative References ..................................... 6
13. Copyright Notice ........................................... 6
14. Author's Address ........................................... 6
1. Abstract ...................................................... 1
2. Table of Contents ............................................. 2
3. Introduction .................................................. 2
4. Conventions ................................................... 2
5. Administrative Areas .......................................... 3
6. Autonomous Administrative Areas ............................... 3
7. Specific Administrative Areas ................................. 3
8. Inner Administrative Areas .................................... 4
9. Administrative Entries ........................................ 5
10. Security Considerations ...................................... 5
11. Acknowledgements ............................................. 5
12. Normative References ......................................... 5
13. Informative References ....................................... 6
14. Copyright Notice ............................................. 6
15. Author's Address ............................................. 7
3. Introduction
This document adapts the X.500 directory administrative model [X501]
for use by the Lightweight Directory Access Protocol (LDAP)
[RFC2251]. The administrative model partitions the Directory
[RFC3377]. The administrative model partitions the Directory
Information Tree (DIT) for various aspects of directory data
administration, e.g. subschema, access control and collective
attributes. This document provides the definitions for the generic
parts of the administrative model that apply to every aspect of
directory data administration.
Sections 4 to 8, in conjunction with [SUBENTRY], describe the means
Sections 5 to 9, in conjunction with [SUBENTRY], describe the means
by which administrative authority is aportioned and exercised in the
DIT.
@ -106,16 +102,22 @@ INTERNET-DRAFT Directory Administrative Model September 18, 2002
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
4. Conventions
4. Administrative Areas
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 RFC 2119 [RFC2119].
Legg Expires 18 March 2003 [Page 2]
Legg Expires 25 August 2003 [Page 2]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
INTERNET-DRAFT Directory Administrative Model February 25, 2003
5. Administrative Areas
An administrative area is a subtree of the DIT considered from the
perspective of administration. The root entry of the subtree is an
administrative point. An administrative point is represented by an
@ -123,7 +125,7 @@ INTERNET-DRAFT Directory Administrative Model September 18, 2002
of this attribute identify the kind of administrative point.
5. Autonomous Administrative Areas
6. Autonomous Administrative Areas
The DIT may be partitioned into one or more non-overlapping subtrees
termed autonomous administrative areas. It is expected that the
@ -144,7 +146,7 @@ INTERNET-DRAFT Directory Administrative Model September 18, 2002
begins.
6. Specific Administrative Areas
7. Specific Administrative Areas
Entries in an administrative area may be considered in terms of a
specific administrative function. When viewed in this context, an
@ -162,16 +164,16 @@ INTERNET-DRAFT Directory Administrative Model September 18, 2002
Alternatively, for each specific aspect of administration, the
autonomous administrative area may be partitioned into
non-overlapping specific administrative areas.
Legg Expires 18 March 2003 [Page 3]
Legg Expires 25 August 2003 [Page 3]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
INTERNET-DRAFT Directory Administrative Model February 25, 2003
non-overlapping specific administrative areas.
If so partitioned for a particular aspect of administration, each
entry of the autonomous administrative area is contained in one and
only one specific administrative area for that aspect, i.e. specific
@ -201,7 +203,7 @@ INTERNET-DRAFT Directory Administrative Model September 18, 2002
purposes only.
7. Inner Administrative Areas
8. Inner Administrative Areas
For some aspects of administration, e.g. access control or collective
attributes, inner administrative areas may be defined within the
@ -218,17 +220,19 @@ INTERNET-DRAFT Directory Administrative Model September 18, 2002
specific administrative area) extends from its inner administrative
point downwards until a specific administrative point of the same
administrative aspect is encountered. An inner administrative area
Legg Expires 25 August 2003 [Page 4]
INTERNET-DRAFT Directory Administrative Model February 25, 2003
is bounded by the specific administrative area within which it is
defined.
Legg Expires 18 March 2003 [Page 4]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
8. Administrative Entries
9. Administrative Entries
An entry located at an administrative point is an administrative
entry. Administrative entries MAY have subentries [SUBENTRY] as
@ -243,7 +247,7 @@ INTERNET-DRAFT Directory Administrative Model September 18, 2002
aspect.
9. Security Considerations
10. Security Considerations
This document defines a generic framework for employing policy of
various kinds, e.g. access controls, to entries in the DIT. Such
@ -258,37 +262,38 @@ INTERNET-DRAFT Directory Administrative Model September 18, 2002
unauthorized examination or changes by appropriate access controls.
10. Acknowledgements
11. Acknowledgements
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
11. Normative References
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
Legg Expires 25 August 2003 [Page 5]
INTERNET-DRAFT Directory Administrative Model February 25, 2003
[SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
August 2002.
Legg Expires 18 March 2003 [Page 5]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
12. Informative References
13. Informative References
[ACA] Legg, S., "Access Control Administration in LDAP",
draft-legg-ldap-acm-admin-xx.txt, a work in progress,
September 2002.
February 2003.
[COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
draft-zeilenga-ldap-collective-xx.txt, a work in progress,
@ -299,9 +304,9 @@ INTERNET-DRAFT Directory Administrative Model September 18, 2002
Models
13. Copyright Notice
14. Copyright Notice
Copyright (C) The Internet Society (2002). 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
@ -328,34 +333,38 @@ INTERNET-DRAFT Directory Administrative Model September 18, 2002
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Author's Address
Legg Expires 25 August 2003 [Page 6]
INTERNET-DRAFT Directory Administrative Model February 25, 2003
15. Author's Address
Steven Legg
Adacel Technologies Ltd.
Legg Expires 18 March 2003 [Page 6]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
250 Bay Street
Brighton, Victoria 3186
AUSTRALIA
Phone: +61 3 9451 2107
Fax: +61 3 9541 2121
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
15. Appendix A - Changes From Previous Drafts
Appendix A - Changes From Previous Drafts
A.1 Changes in Draft 00
This document reproduces Section 4 from
draft-legg-ldap-acm-admin-00.txt as a standalone document. All
changes made are purely editorial. No technical changes have been
introduced.
A.2 Changes in Draft 01
RFC 3377 replaces RFC 2251 as the reference for LDAP.
@ -382,14 +391,5 @@ INTERNET-DRAFT Directory Administrative Model September 18, 2002
Legg Expires 18 March 2003 [Page 7]
Legg Expires 25 August 2003 [Page 7]

328
doc/drafts/draft-legg-ldap-gser-abnf-xx.txt
View file

@ -5,13 +5,13 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-gser-abnf-04.txt Adacel Technologies
Intended Category: Informational August 19, 2002
draft-legg-ldap-gser-abnf-06.txt Adacel Technologies
Intended Category: Informational May 7, 2003
Common Elements of GSER Encodings
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Status of this Memo
@ -39,10 +39,10 @@ Intended Category: Informational August 19, 2002
to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
or to the author.
This Internet-Draft expires on 19 February 2002.
This Internet-Draft expires on 7 November 2003.
1. Abstract
Abstract
The Generic String Encoding Rules (GSER) describe a human readable
text encoding for an ASN.1 value of any ASN.1 type. Specifications
@ -55,68 +55,67 @@ Intended Category: Informational August 19, 2002
Legg Expires 19 February 2002 [Page 1]
Legg Expires 7 November 2003 [Page 1]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
2. Table of Contents
1. Table of Contents
1. Abstract .................................................... 1
2. Table of Contents ........................................... 2
3. Introduction ................................................ 2
4. Conventions ................................................. 2
5. Separators .................................................. 2
6. ASN.1 Built-in Types ........................................ 3
7. ASN.1 Restricted String Types ............................... 7
8. Directory ASN.1 Types ....................................... 8
9. Security Considerations ..................................... 9
10. Normative References ....................................... 10
11. Informative References ..................................... 10
12. Copyright Notice ........................................... 10
13. Author's Address ........................................... 11
1. Table of Contents ............................................. 2
2. Introduction .................................................. 2
3. Conventions ................................................... 2
4. Separators .................................................... 2
5. ASN.1 Built-in Types .......................................... 3
6. ASN.1 Restricted String Types ................................. 7
7. Directory ASN.1 Types ......................................... 9
8. Security Considerations ....................................... 10
9. Normative References .......................................... 11
10. Informative References ....................................... 11
11. Copyright Notice ............................................. 11
12. Author's Address ............................................. 12
3. Introduction
2. Introduction
The Generic String Encoding Rules (GSER) defined in [9] define a
human readable text encoding, based on ASN.1 [7] value notation, for
The Generic String Encoding Rules (GSER) defined in [7] define a
human readable text encoding, based on ASN.1 [8] value notation, for
an ASN.1 value of any ASN.1 type. Specifications making use of GSER
may wish to provide a non-normative equivalent ABNF [3] description
of the GSER encoding for a particular ASN.1 type as a convenience for
implementors unfamiliar with ASN.1. This document supports such
specifications by providing equivalent ABNF for the GSER encodings
for ASN.1 types commonly occuring in LDAP [8] or X.500 [10] attribute
for ASN.1 types commonly occuring in LDAP [9] or X.500 [10] attribute
and assertion syntaxes, as well as equivalent ABNF for the GSER
encodings for the ASN.1 built-in types.
The ABNF given in this document does not replace or alter GSER in any
way. If there is a discrepancy between the ABNF specified here and
the encoding defined by GSER in [9] then [9] is to be taken as
the encoding defined by GSER in [7] then [7] is to be taken as
definitive.
4. Conventions
3. Conventions
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 RFC 2119 [1].
5. Separators
4. Separators
Certain separators are commonly used in constructing equivalent ABNF
for SET and SEQUENCE types.
Legg Expires 19 February 2002 [Page 2]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
sp = *%x20 ; zero, one or more space characters
Legg Expires 7 November 2003 [Page 2]
INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
msp = 1*%x20 ; one or more space characters
sep = [ "," ]
@ -129,7 +128,7 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
the SET or SEQUENCE value being encoded.
6. ASN.1 Built-in Types
5. ASN.1 Built-in Types
This section describes the GSER encoding of values of the ASN.1
built-in types, except for the restricted character string types.
@ -167,9 +166,10 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
Legg Expires 19 February 2002 [Page 3]
Legg Expires 7 November 2003 [Page 3]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
CHARACTER-STRING = "{" sp id-identification msp Identification ","
@ -223,9 +223,9 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
Legg Expires 19 February 2002 [Page 4]
Legg Expires 7 November 2003 [Page 4]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
INTEGER-0-MAX = "0" / positive-number
@ -237,29 +237,56 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
The <EMBEDDED-PDV> rule describes the GSER encoding of values of the
associated type for the EMBEDDED PDV type.
EMBEDDED-PDV = "{" sp id-identification msp Identification
[ "," sp id-data-value-descriptor msp
ObjectDescriptor ]
"," sp id-data-value msp OCTET-STRING
sp "}"
id-data-value-descriptor = %x64.61.74.61.2D.76.61.6C.75.65.2D.64
%x65.73.63.72.69.70.74.6F.72
; "data-value-descriptor"
EMBEDDED-PDV = "{" sp id-identification msp Identification ","
sp id-data-value msp OCTET-STRING
sp "}"
The <EXTERNAL> rule describes the GSER encoding of values of the
associated type for the EXTERNAL type.
EXTERNAL = "{" sp id-identification msp E-Identification
[ "," sp id-data-value-descriptor msp
ObjectDescriptor ]
"," sp id-data-value msp OCTET-STRING
sp "}"
EXTERNAL = "{" [ sp id-direct-reference msp
OBJECT-IDENTIFIER "," ]
[ sp id-indirect-reference msp INTEGER "," ]
[ sp id-data-value-descriptor msp
ObjectDescriptor "," ]
sp id-encoding msp Encoding
sp "}"
E-Identification = ( id-syntax ":" OBJECT-IDENTIFIER ) /
( id-presentation-context-id ":" INTEGER ) /
( id-context-negotiation ":"
ContextNegotiation )
id-direct-reference = %x64.69.72.65.63.74.2D.72.65.66.65.72
%x65.6E.63.65
; "direct-reference"
id-indirect-reference = %x69.6E.64.69.72.65.63.74.2D.72.65.66
%x65.72.65.6E.63.65
; "indirect-reference"
id-data-value-descriptor = %x64.61.74.61.2D.76.61.6C.75.65.2D.64
%x65.73.63.72.69.70.74.6F.72
; "data-value-descriptor"
id-encoding = %x65.6E.63.6F.64.69.6E.67
; "encoding"
Encoding = ( id-single-ASN1-type ":" Value ) /
( id-octet-aligned ":" OCTET-STRING ) /
( id-arbitrary ":" BIT-STRING )
id-single-ASN1-type = %x73.69.6E.67.6C.65.2D.41.53.4E.31.2D.74.79
%x70.65
; "single-ASN1-type"
id-octet-aligned = %x6F.63.74.65.74.2D.61.6C.69.67.6E.65.64
; "octet-aligned"
id-arbitrary = %x61.72.62.69.74.72.61.72.79
; "arbitrary"
Legg Expires 7 November 2003 [Page 5]
INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
The <Value> rule is defined in [7]. It represents the GSER encoding
of a single value of the ASN.1 type identified by the direct-
reference and/or indirect-reference components.
The <NULL> rule describes the GSER encoding of values of the NULL
type.
@ -276,14 +303,6 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
An OBJECT IDENTIFIER value is encoded using either the dotted decimal
representation or an object descriptor name, i.e. <descr>. The
<descr> rule is described in [4]. An object descriptor name is
Legg Expires 19 February 2002 [Page 5]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
potentially ambiguous and should be used with care.
The <OCTET-STRING> rule describes the GSER encoding of values of the
@ -313,6 +332,14 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
; "MINUS-INFINITY"
Legg Expires 7 November 2003 [Page 6]
INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
realnumber = mantissa exponent
mantissa = (positive-number [ "." *decimal-digit ])
/ ( "0." *("0") positive-number )
@ -333,20 +360,13 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
RELATIVE-OID = oid-component *( "." oid-component )
Legg Expires 19 February 2002 [Page 6]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
7. ASN.1 Restricted String Types
6. ASN.1 Restricted String Types
This section describes the GSER encoding of values of the ASN.1
restricted character string types. The characters of a value of a
restricted character string type are always encoded as a UTF8
character string between double quotes. For some of the ASN.1 string
types this requires a translation to or form the UTF8 encoding. Some
types this requires a translation to or from the UTF8 encoding. Some
of the ASN.1 string types permit only a subset of the characters
representable in UTF8. Any double quote characters in the character
string, where allowed by the character set, are escaped by being
@ -369,6 +389,13 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
%xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character
%xFC-FD 5(%x80-BF) ; 6 byte UTF8 character
Legg Expires 7 November 2003 [Page 7]
INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
The <NumericString>, <PrintableString>, <VisibleString>,
<ISO646String>, <IA5String>, <GeneralizedTime> and <UTCTime> rules
describe the GSER encoding of values of the correspondingly named
@ -388,14 +415,6 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
/ %x2B-2F ; + , - . /
/ %x3A ; :
/ %x3D ; =
Legg Expires 19 February 2002 [Page 7]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
/ %x3F ; ?
ISO646String = VisibleString
@ -408,14 +427,33 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
SafeIA5Character = %x00-21 / %x23-7F ; ASCII minus dquote
/ dquote dquote ; escaped double quote
UTCTime = dquote 10(decimal-digit) [2(decimal-digit)]
[ "Z" / u-differential ] dquote
u-differential = ( "-" / "+" ) 4(decimal-digit)
GeneralizedTime = dquote 10(decimal-digit)
*2(2(decimal-digit))
fraction [ "Z" / g-differential ] dquote
fraction = ( "." / "," ) 1*decimal-digit
g-differential = ( "-" / "+" ) 1*2(2(decimal-digit))
century = 2(%x30-39) ; "00" to "99"
year = 2(%x30-39) ; "00" to "99"
month = ( %x30 %x31-39 ) ; "01" (January) to "09"
/ ( %x31 %x30-32 ) ; "10" to "12"
day = ( %x30 %x31-39 ) ; "01" to "09"
/ ( %x31-32 %x30-39 ) ; "10" to "29"
/ ( %x32 %x30-31 ) ; "30" to "31"
hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
minute = %x30-36 %x30-39 ; "00" to "59"
second = %x30-36 %x30-39 ; "00" to "59"
UTCTime = dquote year month day hour minute [ second ]
[ %x5A / u-differential ] dquote
u-differential = ( "-" / "+" ) hour minute
GeneralizedTime = dquote century year month day hour
[ minute [ second ] ] [ fraction ]
[ %x5A / g-differential ] dquote
Legg Expires 7 November 2003 [Page 8]
INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
fraction = ( "." / "," ) 1*(%x30-39)
g-differential = ( "-" / "+" ) hour [ minute ]
The <BMPString> and <UniversalString> rules describe the GSER
encoding of values of the BMPString and UniversalString types
@ -441,17 +479,9 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
ObjectDescriptor = GraphicString
8. Directory ASN.1 Types
7. Directory ASN.1 Types
This section describes the GSER encoding of values of selected ASN.1
Legg Expires 19 February 2002 [Page 8]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
types defined for LDAP and X.500. The ABNF rule names beginning with
uppercase letters describe the GSER encoding of values of the ASN.1
type with the same name.
@ -462,7 +492,30 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
characters as required before being encoded between double quotes
with any embedded double quotes escaped by being repeated.
DirectoryString = dquote *SafeUTF8Character dquote
DirectoryString = StringValue /
( id-teletexString ":" TeletexString ) /
( id-printableString ":" PrintableString ) /
( id-bmpString ":" BMPString ) /
( id-universalString ":" UniversalString ) /
( id-uTF8String ":" UTF8String )
id-teletexString = %x74.65.6C.65.74.65.78.53.74.72.69.6E.67
Legg Expires 7 November 2003 [Page 9]
INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
; "teletexString"
id-printableString = %x70.72.69.6E.74.61.62.6C.65
%x53.74.72.69.6E.67 ; "printableString"
id-bmpString = %x62.6D.70.53.74.72.69.6E.67 ; "bmpString"
id-universalString = %x75.6E.69.76.65.72.73.61.6C
%x53.74.72.69.6E.67 ; "universalString"
id-uTF8String = %x75.54.46.38.53.74.72.69.6E.67
; "uTF8String"
The <RDNSequence> rule describes the GSER encoding of values of the
RDNSequence type, which is syntactically equivalent to the
@ -497,25 +550,21 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
ORAddress = dquote *SafeIA5Character dquote
9. Security Considerations
8. Security Considerations
GSER, and therefore the ABNF encodings described in this document, do
This document contains an alternative description of parts of the
Generic String Encoding Rules, but does not replace or alter GSER in
any way. For the full security implications of using GSER see the
Security Considerations section of [7].
Legg Expires 19 February 2002 [Page 9]
Legg Expires 7 November 2003 [Page 10]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
not necessarily enable the exact octet encoding of values of the
TeletexString, VideotexString, GraphicString or GeneralString types
to be reconstructed, so a transformation from DER to GSER and back to
DER may not reproduce the original DER encoding. This has
consequences for the verification of digital signatures.
10. Normative References
9. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
@ -537,39 +586,40 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[7] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
[7] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
draft-legg-ldap-gser-xx.txt, a work in progress, May 2003.
[8] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
Information Technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation
11. Informative References
10. Informative References
[8] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[9] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
draft-legg-ldap-gser-xx.txt, a work in progress, August 2002.
[9] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol
(v3): Technical Specification", RFC 3377, September 2002.
[10] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - The
Directory: Overview of concepts, models and services
12. Copyright Notice
11. Copyright Notice
Legg Expires 19 February 2002 [Page 10]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
Copyright (C) The Internet Society (2002). 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
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
Legg Expires 7 November 2003 [Page 11]
INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
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
@ -591,16 +641,16 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13. Author's Address
12. Author's Address
Steven Legg
Adacel Technologies Ltd.
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
250 Bay Street
Brighton, Victoria 3186
AUSTRALIA
Phone: +61 3 9451 2107
Fax: +61 3 9541 2121
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
@ -615,5 +665,11 @@ INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
Legg Expires 19 February 2002 [Page 11]
Legg Expires 7 November 2003 [Page 12]

442
doc/drafts/draft-legg-ldap-gser-xx.txt
View file

@ -5,13 +5,13 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-gser-01.txt Adacel Technologies
Intended Category: Standard Track August 19, 2002
draft-legg-ldap-gser-03.txt Adacel Technologies
Intended Category: Standard Track May 7, 2003
Generic String Encoding Rules for ASN.1 Types
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Status of this Memo
@ -39,10 +39,10 @@ Intended Category: Standard Track August 19, 2002
to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
or to the author.
This Internet-Draft expires on 19 February 2002.
This Internet-Draft expires on 7 November 2003.
1. Abstract
Abstract
This document defines a set of Abstract Syntax Notation One (ASN.1)
encoding rules, called the Generic String Encoding Rules, that
@ -55,69 +55,68 @@ Intended Category: Standard Track August 19, 2002
Legg Expires 19 February 2002 [Page 1]
Legg Expires 7 November 2003 [Page 1]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
2. Table of Contents
1. Table of Contents
1. Abstract ...................................................... 1
2. Table of Contents ............................................. 2
3. Introduction .................................................. 2
4. Conventions ................................................... 3
5. Generic String Encoding Rules ................................. 3
5.1 Type Referencing Notations ................................ 4
5.2 Restricted Character String Types ......................... 4
5.3 ChoiceOfStrings Types ..................................... 5
5.4 Identifiers ............................................... 7
5.5 BIT STRING ................................................ 7
5.6 BOOLEAN ................................................... 8
5.7 ENUMERATED ................................................ 8
5.8 INTEGER ................................................... 8
5.9 NULL ...................................................... 8
5.10 OBJECT IDENTIFIER and RELATIVE-OID ....................... 9
5.11 OCTET STRING ............................................. 9
5.12 CHOICE ................................................... 9
5.13 SEQUENCE and SET ......................................... 10
5.14 SEQUENCE OF and SET OF ................................... 11
5.15 CHARACTER STRING ......................................... 11
5.16 EMBEDDED PDV ............................................. 11
5.17 EXTERNAL ................................................. 11
5.18 INSTANCE OF .............................................. 12
5.19 REAL ..................................................... 12
5.20 Variant Encodings ........................................ 12
6. GSER Transfer Syntax .......................................... 13
7. Security Considerations ....................................... 13
8. Normative References .......................................... 13
9. Informative References ........................................ 14
10. Copyright Notice ............................................. 15
11. Author's Address ............................................. 15
1. Table of Contents ............................................. 2
2. Introduction .................................................. 2
3. Conventions ................................................... 3
4. Generic String Encoding Rules ................................. 3
4.1 Type Referencing Notations ................................ 4
4.2 Restricted Character String Types ......................... 4
4.3 ChoiceOfStrings Types ..................................... 5
4.4 Identifiers ............................................... 7
4.5 BIT STRING ................................................ 7
4.6 BOOLEAN ................................................... 8
4.7 ENUMERATED ................................................ 8
4.8 INTEGER ................................................... 8
4.9 NULL ...................................................... 8
4.10 OBJECT IDENTIFIER and RELATIVE-OID ....................... 9
4.11 OCTET STRING ............................................. 9
4.12 CHOICE ................................................... 9
4.13 SEQUENCE and SET ......................................... 10
4.14 SEQUENCE OF and SET OF ................................... 11
4.15 CHARACTER STRING ......................................... 11
4.16 EMBEDDED PDV ............................................. 11
4.17 EXTERNAL ................................................. 11
4.18 INSTANCE OF .............................................. 12
4.19 REAL ..................................................... 12
4.20 Variant Encodings ........................................ 12
5. GSER Transfer Syntax .......................................... 13
6. Security Considerations ....................................... 13
7. Normative References .......................................... 14
8. Informative References ........................................ 15
9. Copyright Notice .............................................. 15
10. Author's Address ............................................. 16
3. Introduction
2. Introduction
This document defines a set of ASN.1 [8] encoding rules, called the
Generic String Encoding Rules or GSER, that produce a human readable
UTF8 [6] character string encoding of ASN.1 values of any given
arbitrary ASN.1 type.
Note that "ASN.1 value" does not mean a BER [17] encoded value. The
Note that "ASN.1 value" does not mean a BER [13] encoded value. The
ASN.1 value is an abstract concept that is independent of any
particular encoding. BER is just one possible encoding of an ASN.1
value.
GSER is based on ASN.1 value notation [8], with changes to
Legg Expires 19 February 2002 [Page 2]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
accommodate the notation's use as a transfer syntax, and to support
well established ad-hoc string encodings for LDAP [13] directory data
Legg Expires 7 November 2003 [Page 2]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
well established ad-hoc string encodings for LDAP [14] directory data
types.
Though primarily intended for defining the LDAP-specific encoding of
@ -130,13 +129,13 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
type, however other specifications may wish to provide a customized
ABNF [3] description, independent of the ASN.1, as a convenience for
the implementor (equivalent ABNF for the GSER encodings for ASN.1
types commonly occuring in LDAP syntaxes is provided in [14]). Such
types commonly occuring in LDAP syntaxes is provided in [15]). Such
a specification SHOULD state that if there is a discrepancy between
the customized ABNF and the GSER encoding defined by this document,
that the GSER encoding takes precedence.
4. Conventions
3. Conventions
Throughout this document "type" shall be taken to mean an ASN.1 type,
and "value" shall be taken to mean an ASN.1 value.
@ -146,7 +145,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
document are to be interpreted as described in RFC 2119 [1].
5. Generic String Encoding Rules
4. Generic String Encoding Rules
The GSER encoding of a value of any ASN.1 type is described by the
following ABNF [3]:
@ -164,15 +163,15 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
NullValue /
ObjectDescriptorValue /
ObjectIdentifierValue /
Legg Expires 19 February 2002 [Page 3]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
OctetStringValue /
Legg Expires 7 November 2003 [Page 3]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
RealValue /
RelativeOIDValue /
SequenceOfValue /
@ -187,7 +186,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
sections.
5.1 Type Referencing Notations
4.1 Type Referencing Notations
A value of a type with a defined type name is encoded according to
the type definition on the right hand side of the type assignment for
@ -218,17 +217,17 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
15 of [10]) is encoded according to the governing type.
5.2 Restricted Character String Types
Legg Expires 19 February 2002 [Page 4]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
4.2 Restricted Character String Types
The contents of a string value are encoded as a UTF8 character string
Legg Expires 7 November 2003 [Page 4]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
between double quotes, regardless of the ASN.1 string type.
Depending on the ASN.1 string type, and an application's internal
representation of that string type, a translation to or from the UTF8
@ -267,7 +266,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
ObjectDescriptorValue = StringValue
5.3 ChoiceOfStrings Types
4.3 ChoiceOfStrings Types
It is not uncommon for ASN.1 specifications to define types that are
a CHOICE between two or more alternative ASN.1 string types, where
@ -276,16 +275,15 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
to avoid having to use a complicated character encoding for all
values when most values could use a simpler string type, or to deal
with evolving requirements that compel the use of a broader character
Legg Expires 19 February 2002 [Page 5]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
set while still maintaining backward compatibility.
Legg Expires 7 November 2003 [Page 5]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
GSER encodes values of all the ASN.1 string types as UTF8 character
strings so the alternative chosen in a purely syntactic CHOICE of
string types makes no material difference to the final encoding of
@ -296,7 +294,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
those constructs does not necessarily mean a CHOICE type is purely
syntactic. Therefore, it is necessary for specifications to declare
the purely syntactic CHOICE types so that they may be more compactly
encoded (see Section 5.12). These declared CHOICE types are referred
encoded (see Section 4.12). These declared CHOICE types are referred
to as ChoiceOfStrings types.
To be eligible to be declared a ChoiceOfStrings type an ASN.1 type
@ -332,16 +330,16 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
parameter defines a ASN.1 type that satisfies the above conditions.
Recognising that the alternative within a DirectoryString carries no
semantic significance, this document declares (each and every use of)
Legg Expires 19 February 2002 [Page 6]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
DirectoryString{} to be a ChoiceOfStrings type.
Legg Expires 7 November 2003 [Page 6]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
Other specifications MAY declare other types satisfying the above
conditions to be ChoiceOfStrings types. The declaration SHOULD be
made at the point where the ASN.1 type is defined, otherwise it
@ -349,7 +347,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
attribute or assertion syntax.
5.4 Identifiers
4.4 Identifiers
An <identifier> conforms to the definition of an identifier in ASN.1
notation (Clause 11.3 of [8]). It begins with a lowercase letter and
@ -366,12 +364,12 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
hyphen = "-"
5.5 BIT STRING
4.5 BIT STRING
A value of the BIT STRING type is encoded according to the
<BitStringValue> rule. If the definition of the BIT STRING type
includes a named bit list, the <bit-list> form of <BitStringValue>
rule MAY be used. If the number of bits in a BIT STRING value is a
MAY be used. If the number of bits in a BIT STRING value is a
multiple of four the <hstring> form of <BitStringValue> MAY be used.
The <bstring> form of <BitStringValue> is used otherwise.
@ -389,14 +387,15 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
bit-list = "{" [ sp identifier
*( "," sp identifier ) ] sp "}"
Legg Expires 19 February 2002 [Page 7]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
hstring = squote *hexadecimal-digit squote %x48 ; '...'H
Legg Expires 7 November 2003 [Page 7]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
hexadecimal-digit = %x30-39 / ; "0" to "9"
%x41-46 ; "A" to "F"
@ -407,7 +406,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
squote = %x27 ; ' (single quote)
5.6 BOOLEAN
4.6 BOOLEAN
A value of the BOOLEAN type is encoded according to the
<BooleanValue> rule.
@ -416,7 +415,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
%x46.41.4C.53.45 ; "FALSE"
5.7 ENUMERATED
4.7 ENUMERATED
A value of the ENUMERATED type is encoded according to the
<EnumeratedValue> rule. The <identifier> MUST be one of those in the
@ -425,7 +424,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
EnumeratedValue = identifier
5.8 INTEGER
4.8 INTEGER
A value of the INTEGER type is encoded according to the
<IntegerValue> rule. If the definition of the INTEGER type includes
@ -442,23 +441,23 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
non-zero-digit = %x31-39 ; "1" to "9"
5.9 NULL
Legg Expires 19 February 2002 [Page 8]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
4.9 NULL
A value of the NULL type is encoded according to the <NullValue>
Legg Expires 7 November 2003 [Page 8]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
rule.
NullValue = %x4E.55.4C.4C ; "NULL"
5.10 OBJECT IDENTIFIER and RELATIVE-OID
4.10 OBJECT IDENTIFIER and RELATIVE-OID
A value of the OBJECT IDENTIFIER type is encoded according to the
<ObjectIdentifierValue> rule. The <ObjectIdentifierValue> rule
@ -477,7 +476,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
RelativeOIDValue = oid-component *( "." oid-component )
5.11 OCTET STRING
4.11 OCTET STRING
A value of the OCTET STRING type is encoded according to the
<OctetStringValue> rule. The octets are encoded in order from the
@ -490,31 +489,30 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
OctetStringValue = hstring
5.12 CHOICE
4.12 CHOICE
A value of a CHOICE type is encoded according to the <ChoiceValue>
rule. The <ChoiceOfStringsValue> encoding MAY be used if the
corresponding CHOICE type has been declared a ChoiceOfStrings type.
This document declares DirectoryString to be a ChoiceOfStrings type
(see Section 5.3). The <IdentifiedChoiceValue> form of <ChoiceValue>
(see Section 4.3). The <IdentifiedChoiceValue> form of <ChoiceValue>
is used otherwise.
ChoiceValue = IdentifiedChoiceValue /
Legg Expires 19 February 2002 [Page 9]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
ChoiceOfStringsValue
Legg Expires 7 November 2003 [Page 9]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
IdentifiedChoiceValue = identifier ":" Value
ChoiceOfStringsValue = StringValue
For implementations that recognise the internal structure of the
DirectoryString CHOICE type (e.g. X.500 directories [15]), if the
DirectoryString CHOICE type (e.g. X.500 directories [16]), if the
character string between the quotes in a <StringValue> contains only
characters that are permitted in a PrintableString the
DirectoryString is assumed to use the printableString alternative,
@ -532,7 +530,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
<IdentifiedChoiceValue> form for a DirectoryString value, though the
particular identifier found will be of no interest.
5.13 SEQUENCE and SET
4.13 SEQUENCE and SET
A value of a SEQUENCE type is encoded according to the
<SequenceValue> rule. The <ComponentList> rule encodes a comma
@ -556,22 +554,22 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
SetValue = ComponentList
Legg Expires 19 February 2002 [Page 10]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
SEQUENCE and SET type definitions are sometimes extended by the
inclusion of additional component types, so an implementation SHOULD
Legg Expires 7 November 2003 [Page 10]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
be capable of skipping over any <NamedValue> encoding with an
identifier that is not recognised, on the assumption that the sender
is using a more recent definition of the SEQUENCE or SET type.
5.14 SEQUENCE OF and SET OF
4.14 SEQUENCE OF and SET OF
A value of a SEQUENCE OF type is encoded according to the
<SequenceOfValue> rule, as a comma separated list of the instances in
@ -587,40 +585,42 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
5.15 CHARACTER STRING
4.15 CHARACTER STRING
A value of the unrestricted CHARACTER STRING type is encoded
according to the corresponding SEQUENCE type defined in Clause 39.5
of [8] (see [14] for equivalent ABNF).
of [8] (see [15] for equivalent ABNF).
CharacterStringValue = SequenceValue
5.16 EMBEDDED PDV
4.16 EMBEDDED PDV
A value of the EMBEDDED PDV type is encoded according to the
corresponding SEQUENCE type defined in Clause 32.5 of [8] (see [14]
corresponding SEQUENCE type defined in Clause 32.5 of [8] (see [15]
for equivalent ABNF).
EmbeddedPDVValue = SequenceValue
5.17 EXTERNAL
4.17 EXTERNAL
A value of the EXTERNAL type is encoded according to the
corresponding SEQUENCE type defined in Clause 33.5 of [8] (see [14]
for equivalent ABNF).
corresponding SEQUENCE type defined in Clause 8.18.1 of [13] (see
[15] for equivalent ABNF).
ExternalValue = SequenceValue
Legg Expires 19 February 2002 [Page 11]
Legg Expires 7 November 2003 [Page 11]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
5.18 INSTANCE OF
4.18 INSTANCE OF
A value of the INSTANCE OF type is encoded according to the
corresponding SEQUENCE type defined in Annex C of [10].
@ -628,14 +628,14 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
InstanceOfValue = SequenceValue
5.19 REAL
4.19 REAL
A value of the REAL type MUST be encoded as "0" if it is zero,
otherwise it is encoded as either the special value <PLUS-INFINITY>,
the special value <MINUS-INFINITY>, an optionally signed <realnumber>
(based on the extended value notation for REAL from [16]) or as a
(based on the extended value notation for REAL from [17]) or as a
value of the corresponding SEQUENCE type for REAL defined in Clause
20.5 of [8] (see [14] for equivalent ABNF).
20.5 of [8] (see [15] for equivalent ABNF).
RealValue = "0" ; zero REAL value
/ PLUS-INFINITY ; positive infinity
@ -654,7 +654,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
; "MINUS-INFINITY"
5.20 Variant Encodings
4.20 Variant Encodings
The values of some named complex ASN.1 types have special string
encodings. These special encodings are always used instead of the
@ -671,9 +671,9 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
Legg Expires 19 February 2002 [Page 12]
Legg Expires 7 November 2003 [Page 12]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
the <distinguishedName> rule in Section 3 of [5], and then it is
@ -699,7 +699,7 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
ORAddressValue = StringValue
6. GSER Transfer Syntax
5. GSER Transfer Syntax
The following OBJECT IDENTIFIER has been assigned to identify the
Generic String Encoding Rules:
@ -707,31 +707,44 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
{ 1 2 36 79672281 0 0 }
This OBJECT IDENTIFIER would be used, for example, to describe the
transfer syntax for a GSER encoded data-value in an EXTERNAL or
EMBEDDED PDV value.
transfer syntax for a GSER encoded data-value in an EMBEDDED PDV
value.
7. Security Considerations
6. Security Considerations
The Generic String Encoding Rules do not necessarily enable the exact
octet encoding of values of the TeletexString, VideotexString,
The Generic String Encoding Rules do not define a canonical encoding.
That is, a transformation from a GSER encoding into some other
encoding (e.g. BER) and back into GSER will not necessarily reproduce
exactly the original GSER octet encoding. Therefore GSER SHOULD NOT
be used where a canonical encoding is needed.
Furthermore, GSER does not necessarily enable the exact octet
encoding of values of the TeletexString, VideotexString,
GraphicString or GeneralString types to be reconstructed, so a
transformation from DER to GSER and back to DER may not reproduce the
original DER encoding. This has consequences for the verification of
digital signatures.
original DER encoding. Therefore GSER SHOULD NOT be used where
8. Normative References
Legg Expires 7 November 2003 [Page 13]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
reversibility to DER is needed, e.g. for the verification of digital
signatures. Instead, DER or a DER-reversible encoding should be
used.
When interpreting security-sensitive fields, and in particular fields
used to grant or deny access, implementations MUST ensure that any
comparisons are done on the underlying abstract value, regardless of
the particular encoding used.
7. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Legg Expires 19 February 2002 [Page 13]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
Levels", BCP 14, RFC 2119, March 1997.
[2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
@ -767,6 +780,14 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
Information object specification
[11] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998
Legg Expires 7 November 2003 [Page 14]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
Information Technology - Abstract Syntax Notation One (ASN.1):
Constraint specification
@ -774,39 +795,31 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
Information Technology - Abstract Syntax Notation One (ASN.1):
Parameterization of ASN.1 specifications
9. Informative References
[13] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
Legg Expires 19 February 2002 [Page 14]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
[14] Legg, S., "Common Elements of GSER Encodings",
draft-legg-ldap-gser-abnf-xx.txt, a work in progress, August
2002.
[15] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - The
Directory: Overview of concepts, models and services
[16] ITU-T Recommendation X.680 - Corrigendum 3 (02/2001)
[17] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
[13] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
Information Technology - ASN.1 encoding rules: Specification of
Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)
10. Copyright Notice
8. Informative References
Copyright (C) The Internet Society (2002). All Rights Reserved.
[14] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377, September
2002.
[15] Legg, S., "Common Elements of GSER Encodings",
draft-legg-ldap-gser-abnf-xx.txt, a work in progress, May 2003.
[16] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - The
Directory: Overview of concepts, models and services
[17] ITU-T Recommendation X.680 - Corrigendum 3 (02/2001)
9. Copyright Notice
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
@ -823,6 +836,14 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
English.
The limited permissions granted above are perpetual and will not be
Legg Expires 7 November 2003 [Page 15]
INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
@ -833,24 +854,16 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. Author's Address
10. Author's Address
Steven Legg
Legg Expires 19 February 2002 [Page 15]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
Adacel Technologies Ltd.
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
250 Bay Street
Brighton, Victoria 3186
AUSTRALIA
Phone: +61 3 9451 2107
Fax: +61 3 9541 2121
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
@ -882,18 +895,5 @@ INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
Legg Expires 19 February 2002 [Page 16]
Legg Expires 7 November 2003 [Page 16]

912
doc/drafts/draft-legg-ldapext-component-matching-xx.txt
View file

File diff suppressed because it is too large Load diff

914
doc/drafts/draft-rharrison-ldap-intermediate-resp-xx.txt
View file

@ -1,413 +1,531 @@
Individual Submission to ldapext Working Group Roger G. Harrison
Internet Draft Novell, Inc.
Intended Category: Standards Track
Kurt D. Zeilenga
OpenLDAP Foundation
March 30, 2001
LDAP Intermediate Response
<draft-rharrison-ldap-intermediate-resp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 (ldapext) mailing list <ietf-ldapext@netscape.com>. Please
send editorial comments directly to the document editor
<roger_harrison@novell.com>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
INTERNET-DRAFT R. Harrison
draft-rharrison-ldap-intermediate-resp-01.txt Novell, Inc.
Updates: 2251 K. Zeilenga
Intended Category: Standards Track OpenLDAP Foundation
March 28, 2003
The Lightweight Directory Access Protocol (LDAP)
Intermediate Response Message
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 (ldapext) mailing list <ietf-ldapext@netscape.com>. Please
send editorial comments directly to the document editor
<roger_harrison@novell.com>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Lightweight Directory Access Protocol (LDAP) version 3 is a
client-request/server-response based protocol. With the exception
of the search operation, the entire response to an operation request
is returned in a single LDAP message. While this single-
request/single-response paradigm is sufficient for many operations
(including all but one of those currently defined by LDAP), both
intuition and practical experience validate the notion that it is
insufficient for some operations. When multiple messages are sent
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document extends LDAPv3 to provide a general mechanism for
defining single-request/multiple-response operations by defining and
describing the IntermediateResponse message.
2. Background and Intended Usage
The Lightweight Directory Access Protocol, version 3 [LDAPv3] is an
extensible protocol. Extended operations ([LDAPv3] Section 4.12) are
defined to allow operations to be added to LDAP without requiring a
new revision of the protocol. Similarly, controls ([LDAPv3] section
Harrison & Zeilenga Expires September 30, 2001 [Page 1]
Harrison & Zeilenga Expires September 28, 2003 [Page 1]
LDAPv3 Intermediate Response March 30, 2001
4.1.12) are defined to extend or modify the behavior of existing
LDAP operations.
LDAPv3 is a client-request/server-response based protocol. With the
exception of the search operation, the entire response to an
operation request is returned in a single protocol data unit (LDAP
message). While this single-request/single-response paradigm is
sufficient for many operations (including almost all but one of
those currently defined by [LDAPv3]), both intuition and practical
experience validate the notion that it is insufficient for some
operations.
For example, the LDAPv3 delete operation could be extended via a
subtree control to mean that an entire subtree is to be deleted. A
subtree delete operation needs to return continuation references
based upon subordinate knowledge information contained in the server
so that the client can complete the operation. Returning references
as they are found instead of with the final result allows the client
to progress the operation more efficiently because it does not have
to wait for the final result to get this continuation reference
information.
Similarly, an engineer might choose to design the subtree delete
operation as an extended operation of its own rather than using a
subtree control in conjunction with the delete operation. Once
again, the same continuation reference information is needed by the
client to complete the operation, and sending the continuation
references as they are found would allow the client progress the
operation more efficiently.
Operations that complete in stages or that progress through various
states as they complete might want to send intermediate responses to
the client apprising it of the status of the operation. For example,
an LDAP implementation might define an extended operation to create
a new replica of an administrative area on a server, and the
operation completes in three stages: (1) begin creation of replica,
(2) send replica data to server, (3) replica creation complete.
Intermediate messages might be sent from the server to the client at
the beginning of stages (1) and (2) with the final response for the
extended operation being sent for stage (3).
As LDAPv3 is currently defined, there is no general LDAP message
type that can be used to return intermediate results. A single,
reusable LDAP message for carrying intermediate response information
is desired to avoid repeated modification of the protocol. Although
the ExtendedResponse message is defined in LDAPv3, it is defined to
be the one and only response message to an ExtendedRequest message
([LDAPv3] Section 4.12, also see Section 6 below), for unsolicited
responses (LDAPv3 Section 4.4), and to return intermediate responses
for the search operation ([LDAPv3] Section 4.5.2). The adaptation of
ExpendedResponse as a general intermediate response mechanism would
be problematic. In particular, existing APIs would likely have to
be redesigned. It is believed (based upon operational experience)
Harrison & Zeilenga Expires September 30, 2001 [Page 2]
Internet-Draft LDAP Intermediate Response 28 March 2003
in response to a single request, all but the last of these response
messages are referred to as "intermediate responses".
This document defines and describes the IntermediateResponse
message, a general mechanism for defining single-request/multiple-
response operations in LDAP. The IntermediateResponse message is
defined in a way that maintains the protocol behavior of existing
LDAP operations. This message is intended to be used in conjunction
with the LDAP ExtendedRequest and ExtendedResponse to define new
single-request/multiple-response operations or in conjunction with a
control when extending existing LDAP operations in a way that
requires them to return intermediate response information.
1. Introduction
The Lightweight Directory Access Protocol (LDAP), version 3
[RFC3377] is an extensible protocol. Extended operations ([RFC2251]
Section 4.12) are defined to allow operations to be added to LDAP
without requiring a new revision of the protocol. Similarly,
controls ([RFC2251] section 4.1.12) are defined to extend or modify
the behavior of existing LDAP operations.
LDAP is a client-request/server-response based protocol. With the
exception of the search operation, the entire response to an
operation request is returned in a single protocol data unit (i.e.
LDAP message). While this single-request/single-response paradigm
is sufficient for many operations (including all but one of those
currently defined by [RFC3377]), both intuition and practical
experience validate the notion that it is insufficient for some
operations.
For example, the LDAP delete operation could be extended via a
subtree control to mean that an entire subtree is to be deleted. A
subtree delete operation needs to return continuation references
based upon subordinate knowledge information contained in the server
so that the client can complete the operation. Returning references
as they are found instead of with the final result allows the client
to progress the operation more efficiently because it does not have
to wait for the final result to get this continuation reference
information.
Similarly, an engineer might choose to design the subtree delete
operation as an extended operation of its own rather than using a
subtree control in conjunction with the delete operation. Once
again, the same continuation reference information is needed by the
client to complete the operation, and sending the continuation
references as they are found would allow the client progress the
operation more efficiently.
Operations that complete in stages or that progress through various
states as they complete might want to send intermediate responses to
the client, thereby informing it of the status of the operation.
For example, an LDAP implementation might define an extended
Harrison & Zeilenga Expires September 28, 2003 [Page 2]
LDAPv3 Intermediate Response March 30, 2001
the addition of a new message to carry intermediate result
information is easier to implement.
This document defines the LDAPv3 IntermediateResponse message. This
message is intended to be used (1) in conjunction with
Internet-Draft LDAP Intermediate Response 28 March 2003
operation to create a new replica of an administrative area on a
server, and the operation completes in three stages: (1) begin
creation of replica, (2) send replica data to server, (3) replica
creation complete. Intermediate messages might be sent from the
server to the client at the beginning of each stage with the final
response for the extended operation being sent after stage (3) is
complete.
As LDAP [RFC3377] is currently defined, there is no general LDAP
message type that can be used to return intermediate results. A
single, reusable LDAP message for carrying intermediate response
information is desired to avoid repeated modification of the
protocol. Although the ExtendedResponse message is defined in LDAP,
it is defined to be the one and only response message to an
ExtendedRequest message ([RFC2251] Section 4.12), for unsolicited
responses (LDAP Section 4.4), and to return intermediate responses
for the search operation ([RFC3377] Section 4.5.2, also see Section
5 below). The adaptation of ExtendedResponse as a general
intermediate response mechanism would be problematic. In
particular, existing APIs would likely have to be redesigned. It is
believed (based upon operational experience) that the addition of a
new message to carry intermediate result information is easier to
implement and is less likely to cause interoperability problems with
existing deployed implementations.
This document defines and describes the LDAP IntermediateResponse
message. This message is intended to be used in conjunction with
ExtendedRequest and ExtendedResponse to define new single-
request/multiple-response operations and (2) in conjunction with a
control when extending existing operations in a way that requires
them to return intermediate response information.
It is intended that the definitions and descriptions of extended
operations and controls that make use of the IntermediateResponse
message will define the circumstances when a IntermediateResponse
message can be sent by a server and the associated meaning of a
IntermediateResponse message sent in a particular circumstance.
Similarly, it is intended that clients will explicitly solicit
IntermediateResponse messages by issuing operations that
specifically call for their return.
request/multiple-response operations or in conjunction with a
control when extending existing LDAP operations in a way that
requires them to return intermediate response information.
It is intended that the definitions and descriptions of extended
operations and controls that make use of the IntermediateResponse
message will define the circumstances when an IntermediateResponse
message can be sent by a server and the associated meaning of an
IntermediateResponse message sent in a particular circumstance.
Similarly, it is intended that clients will explicitly solicit
IntermediateResponse messages by issuing operations that
specifically call for their return.
The LDAP Content Sync Operation [draft-zeilenga-ldup-sync] (a work
in progress) demonstrates one use of LDAP Intermediate Response
messages.
2. Conventions used in this document
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 [RFC2119].
3. Conventions used in this document
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 [ReqsKeywords].
The term "request control" is used to describe a control that is
included in an LDAPv3 request message sent from an LDAPv3 client to
an LDAPv3 server.
4. The IntermediateResponse PDU
This document extends the protocolOp CHOICE of LDAPMessage ([LDAPv3]
Section 4.1.1) to include the field:
intermediateResponse IntermediateResponse
where IntermediateResponse is defined as:
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse messages SHALL NOT be returned to the client
unless the client issues a request that specifically solicits their
return. This document defines two forms of solicitation: extended
operation and request control.
Although the responseName and responseValue are optional in some
circumstances, generally speaking IntermediateResponse messages have
a predefined responseName and a responseValue. The value of the
responseName (if present), the syntax of the responseValue (if
Harrison & Zeilenga Expires September 30, 2001 [Page 3]
Harrison & Zeilenga Expires September 28, 2003 [Page 3]
LDAPv3 Intermediate Response March 30, 2001
present) and the semantics associated with a particular
IntermediateResponse message MUST be specified in documents
describing the extended operation or request control that uses them.
Sections 4.1 and 4.2 describe additional requirements on the
inclusion of responseName and responseValue in IntermediateResponse
messages.
4.1. Usage with LDAPv3 ExtendedRequest and ExtendedResponse
A single-request/multiple-response operation may be defined using a
single ExtendedRequest message to solicit zero or more
IntermediateResponse messages of one or more kinds followed by an
ExtendedResponse message.
An extended operation that defines the return of multiple kinds of
IntermediateResponse messages MUST provide and document a mechanism
for the client to distinguish the kind of IntermediateResponse
message being sent. This SHALL be accomplished by using different
responseName values for each type of IntermediateResponse message
associated with the extended operation or by including identifying
information in the responseValue of each type of
IntermediateResponse message associated with the extended operation.
4.2. Usage with LDAPv3 Request Controls
Any LDAPv3 operation may be extended by the addition of one or more
controls. A control's semantics may include the return of zero or
more IntermediateResponse messages prior to returning the final
result code for the operation. One or more kinds of
IntermediateResponse messages may be sent in response to a request
control.
All IntermediateResponse messages associated with request controls
SHALL include a responseName. This requirement ensures that the
client can correctly identify the source of IntermediateResponse
messages when
(a) two or more controls using IntermediateResponse messages
are included in a request for any LDAPv3 operation or
(b) one or more controls using IntermediateResponse messages
are included in a request with an LDAPv3 extended
operation that uses IntermediateResponse messages.
A request control that defines the return of multiple kinds of
IntermediateResponse messages MUST provide and document a mechanism
for the client to distinguish the kind of IntermediateResponse
message being sent. This SHALL be accomplished by using different
responseName values for each type of IntermediateResponse message
associated with the request control or by including identifying
information in the responseValue of each type of
IntermediateResponse message associated with the request control.
Harrison & Zeilenga Expires September 30, 2001 [Page 4]
Internet-Draft LDAP Intermediate Response 28 March 2003
The term "request control" is used to describe a control that is
included in an LDAP request message sent from an LDAP client to an
LDAP server.
3. The IntermediateResponse Message
This document extends the protocolOp CHOICE of LDAPMessage
([RFC2251] Section 4.1.1) to include the field:
intermediateResponse IntermediateResponse
where IntermediateResponse is defined as:
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse messages SHALL NOT be returned to the client
unless the client issues a request that specifically solicits their
return. This document defines two forms of solicitation: extended
operation and request control.
Although the responseName and responseValue are optional in some
circumstances, generally speaking IntermediateResponse messages have
a predefined responseName and a responseValue. The value of the
responseName (if present), the syntax of the responseValue (if
present) and the semantics associated with a particular
IntermediateResponse message MUST be specified in documents
describing the extended operation or request control that uses them.
Sections 3.1 and 3.2 describe additional requirements on the
inclusion of responseName and responseValue in IntermediateResponse
messages.
3.1. Usage with LDAP ExtendedRequest and ExtendedResponse
A single-request/multiple-response operation may be defined using a
single ExtendedRequest message to solicit zero or more
IntermediateResponse messages of one or more kinds followed by an
ExtendedResponse message.
An extended operation that defines the return of multiple kinds of
IntermediateResponse messages MUST provide and document a mechanism
for the client to distinguish the kind of IntermediateResponse
message being sent. This SHALL be accomplished by using different
responseName values for each type of IntermediateResponse message
associated with the extended operation or by including identifying
information in the responseValue of each type of
IntermediateResponse message associated with the extended operation.
3.2. Usage with LDAP Request Controls
Any LDAP operation may be extended by the addition of one or more
controls ([RFC2251] Section 4.1.12). A control's semantics may
Harrison & Zeilenga Expires September 28, 2003 [Page 4]
LDAPv3 Intermediate Response March 30, 2001
5. Advertising Support for IntermediateResponse Messages
Because IntermediateResponse messages are associated with extended
operations or controls and LDAP provides a means for advertising the
extended operations and controls supported by a server (using the
supportedExtensions and supportedControls attributes of the root DSE
attributes), no separate means for advertising support for
IntermediateResponse messages is needed (or provided).
6. Use of IntermediateResponse and ExtendedResponse with Search
It is noted that ExtendedResponse messages may be sent in response
to LDAPv3 search operations with controls ([LDAPv3] Section 4.5.1).
This use of ExtendedResponse messages SHOULD be viewed as deprecated
in favor of use of the IntermediateResponse messages.
7. Security Considerations
This document describes an enhancement to LDAPv3. All security
considerations of [LDAPv3] apply to this document, however it does
not introduce any new security considerations to the LDAPv3.
8. References
[LDAPv3]
Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[ReqsKeywords]
Scott Bradner. "Key Words for use in RFCs to Indicate
Requirement Levels". RFC 2119.
9. Acknowledgments
The authors would like to acknowledge the members of the IETF LDAP
Extensions (ldapext) working group mail list who responded to the
suggestion that a multiple-response paradigm might be useful for
LDAP extended requests. Special thanks go to two individuals: David
Wilbur who first introduced the idea on the working group list, and
Thomas Salter, who succinctly summarized the group's discussion.
10. Authors' Addresses
Roger Harrison
Novell, Inc.
1800 S. Novell Place
Provo, UT 84606
+1 801 861 2642
roger_harrison@novell.com
Harrison & Zeilenga Expires September 30, 2001 [Page 5]
Internet-Draft LDAP Intermediate Response 28 March 2003
include the return of zero or more IntermediateResponse messages
prior to returning the final result code for the operation. One or
more kinds of IntermediateResponse messages may be sent in response
to a request control.
All IntermediateResponse messages associated with request controls
SHALL include a responseName. This requirement ensures that the
client can correctly identify the source of IntermediateResponse
messages when
(a) two or more controls using IntermediateResponse messages
are included in a request for any LDAP operation or
(b) one or more controls using IntermediateResponse messages
are included in a request with an LDAP extended
operation that uses IntermediateResponse messages.
A request control that defines the return of multiple kinds of
IntermediateResponse messages MUST provide and document a mechanism
for the client to distinguish the kind of IntermediateResponse
message being sent. This SHALL be accomplished by using different
responseName values for each type of IntermediateResponse message
associated with the request control or by including identifying
information in the responseValue of each type of
IntermediateResponse message associated with the request control.
4. Advertising Support for IntermediateResponse Messages
Because IntermediateResponse messages are associated with extended
operations or controls and LDAP provides a means for advertising the
extended operations and controls supported by a server (using the
supportedExtensions and supportedControls attributes of the root DSE
attributes), no separate means for advertising support for
IntermediateResponse messages is needed (or provided).
5. Use of IntermediateResponse and ExtendedResponse with Search
It is noted that ExtendedResponse messages may be sent in response
to LDAP search operations with controls ([RFC2251] Section 4.5.1).
This use of ExtendedResponse messages SHOULD be viewed as deprecated
in favor of use of the IntermediateResponse messages.
6. Security Considerations
This document describes an enhancement to LDAP. All security
considerations of [RFC3377] apply to this document, however it does
not introduce any new security considerations to LDAP.
Security considerations specific to each extension using this
protocol mechanism shall be discussed in the technical specification
detailing the extension.
7. IANA Considerations
Harrison & Zeilenga Expires September 28, 2003 [Page 5]
LDAPv3 Intermediate Response March 30, 2001
Internet-Draft LDAP Intermediate Response 28 March 2003
Registration of the following value is requested [RFC3383].
7.1. LDAP Message Type
It is requested that IANA register upon Standards Action an LDAP
Message Type to identify the LDAP IntermediateResponse message as
defined in section 3 of this document.
The following registration template is suggested:
Subject: Request for LDAP Message Type Registration
Person & email address to contact for further information:
Roger Harrison <roger_harrison@novell.com>
Specification: RFCXXXX
Author/Change Controller: IESG
Comments: Identifies the LDAP IntermediateResponse Message
Acknowledgments
The authors would like to acknowledge the members of the IETF LDAP
Extensions (ldapext) working group mail list who responded to the
suggestion that a multiple-response paradigm might be useful for
LDAP extended requests. Special thanks go to two individuals: David
Wilbur who first introduced the idea on the working group list, and
Thomas Salter, who succinctly summarized the group's discussion.
Normative References
[RFC2119]
Bradner, S., "Key Words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[RFC2251]
Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC3377]
Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377, September
2002.
[RFC3383]
Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access Protocol
(LDAP)", RFC 3383, September 2002.
Informative References
[draft-zeilenga-ldup-sync]
Kurt D. Zeilenga
OpenLDAP Foundation
Kurt@OpenLDAP.org
Appendix A - Document Revision History
Editors' Note: this non-normative appendix should be removed prior
to publication as an RFC. It is provided as an aid to reviewers of
this "work in progress."
A.1. draft-rharrison-ldap-extPartResp-00.txt
Initial revision of draft.
A.2. draft-rharrison-ldap-extPartResp-01.txt
Changed responseName to be optional to align with [LDAPv3]
definition of ExtendedResponse.
A.3. draft-rharrison-ldap-extPartResp-02.txt
Minor terminology corrections. Clarified use of
ExtendedPartialResponse with LDAPv3 extended operations and other
LDAPv3 operations with controls.
A.4. draft-rharrison-ldap-intermediateResp-00.txt
- Changed name of ExtendedPartialResponse to IntermediateResponse.
- Retitled "Motivation" section to "Background and Intended Usage"
and expanded its contents.
- Added detail surrounding the use of the IntermediateResponse with
extended operations and request controls.
- Generalized the way that Intermediate response fits into the ASN.1
definition of LDAPv3.
- Added information on advertising IntermediateResponse.
- Added information on the use of IntermediateResponse with the
search operation.
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 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
Harrison & Zeilenga Expires September 30, 2001 [Page 6]
Harrison & Zeilenga Expires September 28, 2003 [Page 6]
LDAPv3 Intermediate Response March 30, 2001
Internet organizations, except as needed for the purpose of
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 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.
Harrison & Zeilenga Expires September 30, 2001 [Page 7]
Internet-Draft LDAP Intermediate Response 28 March 2003
Zeilenga, K., "LDAP Content Synchronization Operation", Work in
Progress.
Authors' Addresses
Roger Harrison
Novell, Inc.
1800 S. Novell Place
Provo, UT 84606
+1 801 861 2642
roger_harrison@novell.com
Kurt D. Zeilenga
OpenLDAP Foundation
Kurt@OpenLDAP.org
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 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
Internet organizations, except as needed for the purpose of
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 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.
Appendix A - Document Revision History
Editors' Note: this appendix should be removed prior to publication
as an RFC. It is provided as an aid to reviewers of this "work in
progress."
A.1. draft-rharrison-ldap-extPartResp-00.txt
Initial revision of draft.
Harrison & Zeilenga Expires September 28, 2003 [Page 7]
Internet-Draft LDAP Intermediate Response 28 March 2003
A.2. draft-rharrison-ldap-extPartResp-01.txt
Changed responseName to be optional to align with [RFC3377]
definition of ExtendedResponse.
A.3. draft-rharrison-ldap-extPartResp-02.txt
Minor terminology corrections. Clarified use of
ExtendedPartialResponse with LDAP extended operations and other LDAP
operations with controls.
A.4. draft-rharrison-ldap-intermediateResp-00.txt
- Changed name of ExtendedPartialResponse to IntermediateResponse.
- Retitled "Motivation" section to "Background and Intended Usage"
and expanded its contents.
- Added detail surrounding the use of the IntermediateResponse with
extended operations and request controls.
- Generalized the way that Intermediate response fits into the ASN.1
definition of LDAP.
- Added information on advertising IntermediateResponse.
- Added information on the use of IntermediateResponse with the
search operation.
A.5. draft-rharrison-ldap-intermediateResp-01.txt
This draft was oriented primarily to preparing the draft for
publication in accordance with established RFC formatting
guidelines. No substantial change in overall content was made.
Changes included the following:
- Retitled document
- Rewrote abstract
- Retitled "Background and Intended Usage" section to "Introduction"
and expanded its contents.
- Retitled Section 3 from "The Intermediate Response PDU" to "The
Intermediate Response Message".
- Renamed references to [RFCnnnn] format
- Added IANA Considerations section
- Retitled "References" section to "Normative References"
- Other small edits to bring draft in line with RFC formatting
Harrison & Zeilenga Expires September 28, 2003 [Page 8]
Internet-Draft LDAP Intermediate Response 28 March 2003
guidelines.
Harrison & Zeilenga Expires September 28, 2003 [Page 9]

468
doc/drafts/draft-smith-ldap-c-api-ext-vlv-xx.txt
View file

@ -1,468 +0,0 @@
Network Working Group M. Smith
INTERNET-DRAFT Netscape Communications Corp.
Intended Category: Standards Track
Expires: 18 April 2000
18 October 1999
LDAP C API Virtual List View Extension
<draft-smith-ldap-c-api-ext-vlv-00.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This draft document will be submitted to the RFC Editor as a Standards
Track document. Distribution of this memo is unlimited. Technical dis-
cussion 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 <mcs@netscape.com>.
Copyright (C) The Internet Society (1998-1999). All Rights Reserved.
Please see the Copyright section near the end of this document for more
information.
Expires: 18 April 2000 [Page 1]
INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
2. Introduction
This document defines a virtual list view extension for the LDAP C API
to support the LDAP protocol extensions for scrolling view browsing of
search results. More specifically, this document defines functions to
create virtual list view request controls and to parse virtual list view
response controls.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in RFC 2119 [KEYWORDS].
3. Table of Contents
1. Status of this Memo............................................1
2. Introduction...................................................2
3. Table of Contents..............................................2
4. Background and Intended Usage..................................2
5. Advertising the Virtual List View C LDAP API Extension.........3
6. Creating a Virtual List View Request Control...................3
7. Parsing a Virtual List View Response Control...................6
8. Example Code...................................................8
9. Security Considerations........................................8
10. Copyright......................................................8
11. Bibliography...................................................9
12. Author's Address...............................................9
13. Appendix A - Summary of Additions to the C LDAP API............9
4. Background and Intended Usage
The LDAP C API [CAPI] defines a C language application programming
interface (API) to the Lightweight Directory Access Protocol [LDAP].
This document defines an extension to that API to support an optional
LDAP protocol extension for scrolling view browsing of search results,
also known as Virtual List View [VLV].
The scrolling view browsing LDAP extension itself is designed to allow a
"virtual list box" feature to be supported efficiently by LDAP servers
and clients. The protocol extension consists of two LDAP controls: a
Virtual List View (VLV) Request control which is sent by a client to a
server along with an LDAP search request and a Virtual List View
Response control which is returned by the server to send back status
information about the VLV request.
LDAP clients that wish to use the "virtual list box" feature SHOULD
first check the supportedControls attribute in a server's rootDSE to
Expires: 18 April 2000 [Page 2]
INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
determine if a value identical to the Virtual List View Request
control's OID is present. If the OID is present and the client chooses
to use the VLV feature, it MUST construct a Virtual List View Request
control and a Server Side Sorting Control [SSS] and send both controls
to the server within an LDAP searchRequest message. Both controls
SHOULD be marked critical. Client applications MAY use the
ldap_create_vlv_control() function described in this document to create
a Virtual List View Request control.
At the end of the search request processing, the server SHOULD return a
Virtual List View Response control in the LDAP searchResultDone message.
A Virtual List View Response control MAY be parsed to extract its con-
tents by using the ldap_parse_vlv_control() function described in this
document.
5. Advertising the Virtual List View C LDAP API Extension
To conform with the requirements defined in the C LDAP API specification
[CAPI], implementations that support this extension SHOULD advertise the
existence of this extension as follows:
Define the macro LDAP_API_FEATURE_VIRTUAL_LIST_VIEW as a value that
corresponds to the "level" or revision of this specification. When
this document is published as an RFC, the value to use for
LDAP_API_FEATURE_VIRTUAL_LIST_VIEW is the RFC number itself. While
this document is an Internet Draft, the value to use is 1000 plus the
revision number of this draft, i.e., 1000 for the -00 revision of
this draft, 1001 for the -01 version, and so on.
Return the text string VIRTUAL_LIST_VIEW in the ldapai_extensions
array of the LDAPAPIInfo structure following a successful call to
ldap_get_option() with an option parameter value of
LDAP_OPT_API_INFO.
Return information about the extension when the ldapaif_name field in
the LDAPAPIFeatureInfo structure is set to the text string
VIRTUAL_LIST_VIEW and a call to ldap_get_option() with an option
parameter value of LDAP_OPT_API_FEATURE_INFO is made.
6. Creating a Virtual List View Request Control
The LDAPVLVInfo structure describes a Virtual List View Request control
and is passed to the ldap_create_vlv_control() function to create a Vir-
tualListViewRequest control. The resulting control SHOULD be passed to
Expires: 18 April 2000 [Page 3]
INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
the ldap_search_ext() or ldap_search_ext_s() functions described in
[CAPI] to send them to the server. The ldap_create_sort_control() func-
tion described in [SSSAPI] MAY be used to create a Sort control that is
be passed to the server along with the VirtualListViewRequest control.
The LDAPVLVInfo structure MAY also be used by applications to manage the
state information associated with a series of virtual list view
client/server interactions.
/* LDAPVLVInfo structure: */
typedef struct ldapvlvinfo {
int ldvlv_version; /* version of this struct (1) */
unsigned long ldvlv_before_count;
unsigned long ldvlv_after_count;
unsigned long ldvlv_offset; /* used if ldvlv_attrvalue is NULL
*/
unsigned long ldvlv_count; /* used if ldvlv_attrvalue is NULL
*
struct berval *ldvlv_attrvalue;
struct berval *ldvlv_context;
void *ldvlv_extradata; /* for use by application */
} LDAPVLVInfo;
/* value for the ldvlv_version field of the LDAPVLVInfo structure: */
#define LDAP_VLVINFO_VERSION 1
/* function used to create a VirtualListViewRequest control: */
int ldap_create_vlv_control(
LDAP *ld,
LDAPVLVInfo *vlvinfop,
LDAPControl **ctrlp
);
/* OID of the VirtualListViewRequest control: */
#define LDAP_CONTROL_VLVREQUEST "2.16.840.1.113730.3.4.9"
The parameters to the ldap_create_vlv_control() function are:
ld An LDAP session handle, as obtained from a call to
ldap_init().
vlvinfop The address of an LDAPVLVInfo structure whose con-
tents are used to construct the value of the control
that is created.
ctrlp A result parameter that will be assigned the address
of an LDAPControl structure that contains the Virtu-
alListViewRequest control created by this function.
The memory occupied by the LDAPControl structure
SHOULD be freed when it is no longer in use by
Expires: 18 April 2000 [Page 4]
INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
calling ldap_control_free().
The ldap_create_vlv_control() function returns a C LDAP API error code
to indicate success or failure (LDAP_SUCCESS if all goes well).
The members of the LDAPVLVInfo structure are:
ldvlv_version A number that identifies the version of the
LDAPVLVInfo structure. This SHOULD always be set to
the value LDAP_VLVINFO_VERSION (1).
ldvlv_before_count A count of the number of entries before the target
entry the client wants the server to send back.
This field corresponds to the beforeCount element of
the BER-encoded VirtualListViewRequest control value
itself.
ldvlv_after_count A count of the number of entries after the target
entry the client wants the server to send back.
This field corresponds to the afterCount element of
the BER-encoded VirtualListViewRequest control value
itself.
ldvlv_offset This field is only used if ldvlv_attrvalue is NULL,
i.e, if the byoffset choice within the VirtualList-
ViewRequest control is to be used. ldvlv_offset is
used along with the ldvlv_count value by the server
to determine the target entry. This field
corresponds to the offset element within the BER-
encoded VirtualListViewRequest control value itself.
ldvlv_count This field is only used if ldvlv_attrvalue is NULL,
i.e., if the byIndex choice within the VirtualList-
ViewRequest control is to be used. ldvlv_count is
used along with the ldvlv_offset value by the server
to determine the target entry. This field
corresponds to the contentCount element within the
BER-encoded VirtualListViewRequest control value
itself.
ldvlv_attrvalue If this is not NULL, it indicates that the
greaterThanOrEqual choice within the VirtualList-
ViewRequest is to be used. ldvlv_attrvalue
corresponds to the assertionValue element of the
BER-encoded VirtualListViewRequest control value
itself. This value is compared by the server with
the values of the attribute specified by the primary
sort key to determine the target entry.
Expires: 18 April 2000 [Page 5]
INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
ldvlv_context If this is not NULL, it is included as the context
identifier in the VirtualListViewRequest control;
ldvlv_context corresponds to the contextID element
within the BER-encoded VirtualListViewRequest con-
trol value itself. If ldvlv_context is NULL, no
context identifier is included in the VirtualList-
ViewRequest control.
ldvlv_extradata This field is reserved for application-specific use
and is not used by the ldap_create_vlv_control()
function; it has no effect on the control that is
created.
7. Parsing a Virtual List View Response Control
When an application receives the result from a VLV search, it SHOULD use
the ldap_parse_vlv_control() function to look for and parse the Virtual
List View Response control returned by the server.
/* function used to look for and parse a VirtualListViewResponse
control: */
int ldap_parse_vlv_control(
LDAP *ld,
LDAPControl **ctrls,
unsigned long *target_posp,
unsigned long *list_countp,
struct berval **contextp,
int *errcodep
);
/* OID of the VirtualListViewResponse control: */
#define LDAP_CONTROL_VLVRESPONSE "2.16.840.1.113730.3.4.10"
/* new error codes: */
#define LDAP_SORT_CONTROL_MISSING 0x3C /* 60 */
#define LDAP_INDEX_RANGE_ERROR 0x3D /* 61 */
The parameters to the ldap_parse_vlv_control() function are:
ld An LDAP session handle.
ctrls The address of a NULL-terminated array of LDAPCon-
trol structures, typically obtained by a call to
ldap_parse_result().
target_posp This result parameter is filled in with the list
index of the target entry. If this parameter is
NULL, the target position is not returned. The
Expires: 18 April 2000 [Page 6]
INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
value for this result parameter is pulled from the
targetPosition element of the BER-encoded Virtual-
ListViewResponse control value itself.
list_countp This result parameter is filled in with the server's
estimate of the size of the list. If this parameter
is NULL, the size is not returned. The value for
this result parameter is pulled from the con-
tentCount element of the BER-encoded VirtualList-
ViewResponse control value itself.
contextp This result parameter is filled in with the address
of a struct berval that contains the server-
generated context identifier if one was returned by
the server. If the server did not return a context
identifier, this parameter will be set to NULL. The
struct berval returned SHOULD be disposed of by cal-
ling ber_bvfree() when it is no longer needed. If
NULL is passed for contextp, the context identifier
is not returned.
errcodep This result parameter is filled in with the VLV
result code. If this parameter is NULL, the result
code is not returned. The value for this result
parameter is pulled from the virtualListViewResult
element of the BER-encoded VirtualListViewResponse
control value itself. As specified in the VLV pro-
tocol extension [VLV], it will have one of the fol-
lowing values:
LDAP_SUCCESS (0); defined in [CAPI]
LDAP_OPERATIONS_ERROR (1); defined in [CAPI]
LDAP_UNWILLING_TO_PERFORM (53); defined in [CAPI]
LDAP_INSUFFICIENT_ACCESS (50); defined in [CAPI]
LDAP_BUSY (51); defined in [CAPI]
LDAP_TIMELIMIT_EXCEEDED (3); defined in [CAPI]
LDAP_ADMINLIMIT_EXCEEDED (11); defined in [CAPI]
LDAP_SORT_CONTROL_MISSING (60); defined above
LDAP_INDEX_RANGE_ERROR (61); defined above
LDAP_OTHER (80); defined in [CAPI]
The ldap_parse_vlv_control() function returns an LDAP error code that
indicates whether a VLV Result control was found and whether the parsing
was successful. LDAP_SUCCESS is returned if all goes well,
LDAP_CONTROL_NOT_FOUND is returned if the ctrls array does not include a
VirtualListViewResponse control, and another LDAP error code that is
defined in [CAPI] is returned if a parsing error or other problem
occurs.
Expires: 18 April 2000 [Page 7]
INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
8. Example Code
To be provided.
9. Security Considerations
Most servers will be configured to restrict access to the Virtual List
View feature since poorly-behaved or malicious clients may cause many
resources to be consumed on the server, or allow users to retrieve too
many entries, or allow users to get an accurate count of the number of
entries present in a portion of the DIT. Clients should take care to
not abuse the VLV feature and should be prepared for servers to refuse
to service a particular VLV request due to access control or other
site-defined policies.
Please see the protocol extension document [VLV] for a discussion of
related security considerations.
10. Copyright
Copyright (C) The Internet Society (1998-1999). All Rights Reserved.
This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, 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 Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Stan-
dards 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 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 FIT-
NESS FOR A PARTICULAR PURPOSE.
Expires: 18 April 2000 [Page 8]
INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
11. Bibliography
[CAPI] M. Smith, T. Howes, A. Herron, M. Wahl, A. Anantha, "The C
LDAP Application Program Interface", INTERNET-DRAFT,
<draft-ietf-ldapext-ldap-c-api-04.txt>, 8 October 1999.
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Require-
ment Levels", RFC 2119, March 1997.
[LDAP] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[SSS] A. Herron, T. Howes, M. Wahl, A. Anantha, "LDAP Control
Extension for Server Side Sorting of Search Results",
INTERNET-DRAFT, April 1999.
[SSSAPI] C. Weider, A. Herron, T. Howes, M. Smith, M. Wahl, "LDAP API
Extensions for Sort and Simple Paged Results", INTERNET-
DRAFT, <draft-ietf-asid-ldapv3-api-ext-00.txt>, July 1997.
[VLV] D. Boreham, J. Sermersheim, A. Anantha, M. Armijo, "LDAP
Extensions for Scrolling View Browsing of Search Results",
INTERNET-DRAFT <draft-ietf-ldapext-ldapv3-vlv-03.txt>, 11
June 1999.
12. Author's Address
Mark Smith
Netscape Communications Corp.
501 E. Middlefield Rd., Mailstop MV068
Mountain View, CA 94043
USA
+1 650 937-3477
mcs@netscape.com
13. Appendix A - Summary of Additions to the C LDAP API
This extension introduces the following macros:
LDAP_API_FEATURE_VIRTUAL_LIST_VIEW
LDAP_VLVINFO_VERSION
LDAP_CONTROL_VLVREQUEST
LDAP_CONTROL_VLVRESPONSE
LDAP_SORT_CONTROL_MISSING
LDAP_INDEX_RANGE_ERROR
Expires: 18 April 2000 [Page 9]
INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
This extension introduces the following structures and typedefs:
ldapvlvinfo
LDAPVLVInfo
This extension introduces the following functions:
ldap_create_vlv_control()
ldap_parse_vlv_control()
Expires: 18 April 2000 [Page 10]

316
doc/drafts/draft-weltman-ldapv3-proxy-xx.txt
View file

@ -2,10 +2,10 @@
INTERNET-DRAFT Rob Weltman
Intended Category: Standards Track Netscape Communications Corp.
May 2002
April 2003
LDAP Proxied Authorization Control
draft-weltman-ldapv3-proxy-11.txt
draft-weltman-ldapv3-proxy-12.txt
Status of this Memo
@ -32,93 +32,96 @@ Status of this Memo
Abstract
This document defines the Lightweight Directory Access Protocol
(LDAP) Proxied Authorization Control. The Proxied Authorization
Control allows a client to request that an operation be processed
under a provided authorization identity [AUTH] instead of as the
current authorization identity associated with the connection.
(LDAP) Proxy Authorization Control. The Proxy Authorization Control
allows a client to request that an operation be processed under a
provided authorization identity instead of as the current
authorization identity associated with the connection.
1. Introduction
This document defines support for proxied authorization using the
Control mechanism. LDAP [LDAPV3] supports the use of SASL [SASL] for
authentication and for supplying an authorization identity distinct
from the authentication identity, where the authorization identity
applies to the whole LDAP session. The proposed Proxied Authorization
Control provides a mechanism for specifying an authorization identity
on a per operation basis, benefiting clients that need to efficiently
perform operations on behalf of multiple users.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and
"MAY NOT" used in this document are to be interpreted as described
in [KEYWORDS].
Proxy authorization allows a client to request that an operation be
processed under a provided authorization identity instead of as the
current authorization identity associated with the connection. This
document defines support for proxy authorization using the Control
mechanism [RFC 2251]. The Lightweight Directory Access Protocol
[LDAPV3] supports the use of the Simple Authentication and Security
Layer [SASL] for authentication and for supplying an authorization
identity distinct from the authentication identity, where the
authorization identity applies to the whole LDAP session. The Proxy
Authorization Control provides a mechanism for specifying an
authorization identity on a per operation basis, benefiting clients
that need to efficiently perform operations on behalf of multiple
users.
Expires November 2002 [Page 1]
Expires October 2003 [Page 1]
PROXIED AUTHORIZATION CONTROL May 2002
PROXIED AUTHORIZATION CONTROL April 2003
2. Publishing support for the Proxied Authorization Control
Support for the Proxied Authorization Control is indicated by the
presence of the OID "2.16.840.1.113730.3.4.18" in the
supportedControl attribute of a server's root DSE.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
used in this document are to be interpreted as described in
[KEYWORDS].
3. Proxied Authorization Control
2. Publishing support for the Proxy Authorization Control
A single Proxied Authorization Control may be included in any search,
compare, modify, add, delete, modDN or extended operation request
message (with the exception of any extension that causes a change in
authentication, authorization, or data confidentiality [RFC 2828],
such as startTLS) as part of the controls field of the LDAPMessage,
as defined in [LDAPV3].
Support for the Proxy Authorization Control is indicated by the
presence of the Object Identifier (OID) "2.16.840.1.113730.3.4.18" in
the supportedControl attribute [RFC 2252] of a server's root DSE.
The controlType of the proxied authorization control is
3. Proxy Authorization Control
A single Proxy Authorization Control may be included in any search,
compare, modify, add, delete, modify DN or extended operation request
message with the exception of any extension that causes a change in
authentication, authorization, or data confidentiality [RFC 2829],
such as Start TLS [LDAPTLS] as part of the controls field of the
LDAPMessage, as defined in [RFC 2251].
The controlType of the proxy authorization control is
"2.16.840.1.113730.3.4.18".
The criticality MUST be present and MUST be TRUE. This requirement
protects clients from submitting a request that is executed with an
unintended authorization identity.
The controlValue is either an LDAPString [LDAPv3] containing an
authzId as defined in section 9 of [AUTH] to use as the authorization
identity for the request, or an empty value if the anonymous identity
is to be used.
The controlValue SHALL be present and contain either an authzId
[AUTH] representing the authorization identity for the request or
empty if an anonymous association is to be used.
The mechanism for determining proxy access rights is specific to the
server's access control policy.
server's proxy authorization policy.
If the requested authorization identity is recognized by the server,
and the client is authorized to adopt the requested authorization
identity, the request will be executed as if submitted by the proxied
identity, the request will be executed as if submitted by the proxy
authorization identity, otherwise the result code TBD is returned.
[Note to the IESG/IANA/RFC Editor: the value TBD is to be replaced
with an IANA assigned LDAP Result Code (see draft-ietf-ldapbis-iana-
xx.txt, Section 3.5)]
with an IANA assigned LDAP Result Code (see RFC 3383 section 3.6]
4. Implementation Considerations
The interaction of proxied authorization access control and normal
access control is illustrated here for the case of search requests.
During evaluation of a search request, an entry which would have been
returned for the search if submitted by the proxied authorization
One possible interaction of proxy authorization and normal access
control is illustrated here for the case of search requests. During
evaluation of a search request, an entry which would have been
returned for the search if submitted by the proxy authorization
identity directly may not be returned if the server finds that the
requester does not have the right to assume the requested identity
for searching the entry, even if the entry is within the scope of a
search request under a base DN which does imply such rights. This
means that fewer results, or no results, may be returned compared to
the case where the proxied authorization identity issued the request
directly. An example of such a case may be a system with fine-grained
Expires November 2002 [Page 2]
Expires October 2003 [Page 2]
PROXIED AUTHORIZATION CONTROL May 2002
PROXIED AUTHORIZATION CONTROL April 2003
means that fewer results, or no results, may be returned compared to
the case where the proxy authorization identity issued the request
directly. An example of such a case may be a system with fine-grained
access control, where the proxy right requester has proxy rights at
the top of a search tree, but not at or below a point or points
within the tree.
@ -126,20 +129,31 @@ PROXIED AUTHORIZATION CONTROL May 2002
5. Security Considerations
The Proxied Authorization Control method is subject to general LDAP
security considerations [LDAPV3] [AUTH] [LDAPTLS]. The control may be
passed over a secure as well as over an insecure channel.
The Proxy Authorization Control method is subject to general LDAP
security considerations [RFC 2251] [AUTH] [LDAPTLS]. The control may
be passed over a secure as well as over an insecure channel.
The control allows for an additional authorization identity to be
passed. In some deployments, these identities may contain
confidential information which require privacy protection.
Note that the server is responsible for determining if a proxied
Note that the server is responsible for determining if a proxy
authorization request is to be honored. "Anonymous" users SHOULD NOT
be allowed to assume the identity of others.
6. Copyright
6. IANA Considerations
The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy
Authorization Control. It is to be registered as an LDAP Protocol
Mechanism [RFC 3383].
A result code for the case where the server does not execute a
request using the proxy authorization identity is to be assigned by
the IANA.
7. Copyright
Copyright (C) The Internet Society (date). All Rights Reserved.
@ -158,6 +172,12 @@ PROXIED AUTHORIZATION CONTROL May 2002
English.
The limited permissions granted above are perpetual and will not be
Expires October 2003 [Page 3]
PROXIED AUTHORIZATION CONTROL April 2003
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
@ -168,22 +188,18 @@ PROXIED AUTHORIZATION CONTROL May 2002
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
7. References
8. Normative References
[LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
Expires November 2002 [Page 3]
PROXIED AUTHORIZATION CONTROL May 2002
[KEYWORDS] Bradner, Scott, "Key Words for use in RFCs to Indicate
Requirement Levels", draft-bradner-key-words-03.txt, January,
1997.
[SASL] J. Myers, "Simple Authentication and Security Layer (SASL)",
[LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377, September
2002.
[SASL] J. Myers, "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997
[AUTH] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
@ -193,86 +209,72 @@ PROXIED AUTHORIZATION CONTROL May 2002
Access Protocol (v3): Extension for Transport Layer Security",
RFC 2830, May 2000
[RFC 2828] R. Shirey, "Internet Security Glossary", RFC 2828, May
2000
[RFC 2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
8. Author's Address
[RFC 2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997
[RFC 2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000
[RFC 3383] K. Zeilenga, "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access Protocol
(LDAP)", RFC 3383, September 2002
9. Author's Address
Rob Weltman
Netscape Communications Corp.
466 Ellis Street
Mountain View, CA 94043
360 W. Caribbean Drive
Sunnyvale, CA 94089
USA
Expires October 2003 [Page 4]
PROXIED AUTHORIZATION CONTROL April 2003
+1 650 937-3194
rweltman@netscape.com
9. Acknowledgements
10. Acknowledgements
Mark Smith of Netscape Communications Corp., Mark Wahl of Sun
Microsystems, Inc, Kurt Zeilenga of OpenLDAP Foundation, Jim
Sermersheim of Novell, and Steven Legg of Adacel have contributed
with reviews of this draft.
10. Revision History
10.1 Changes from draft-weltman-ldapv3-proxy-10.txt
Clarified the interaction of proxy access rights and normal access
control evaluation.
with reviews of this document.
10.2 Changes from draft-weltman-ldapv3-proxy-09.txt
Removed description of Control mechanism from Abstract.
Added description of how this is different from SASL authz to the
Introduction.
Expires November 2002 [Page 4]
PROXIED AUTHORIZATION CONTROL May 2002
Reworded description of the value of the control (no semantic
changes).
Added new result code TBD for failure to acquire proxy rights.
Added references to RFCs 2829 and 2830 in Security section.
10.3 Changes from draft-weltman-ldapv3-proxy-08.txt
Proxied Authorization Control
Clarifications: the control may not be submitted with a startTLS
request; an empty controlValue implies the anonymous identity; only
one control may be included with a request.
Permission to execute as proxy
Replaced "proxy identity" with "proxied authorization identity".
Security Considerations
Added statement that anonymous users should not be allowed to assume
the identity of others.
10.4 Changes from draft-weltman-ldapv3-proxy-07.txt
Proxied Authorization Control
Clarification: the content of the control is an LDAPString.
10.5 Changes from draft-weltman-ldapv3-proxy-06.txt
None
@ -289,63 +291,5 @@ PROXIED AUTHORIZATION CONTROL May 2002
Expires November 2002 [Page 5]
PROXIED AUTHORIZATION CONTROL May 2002
10.6 Changes from draft-weltman-ldapv3-proxy-05.txt
The control also applies to add and extended operations.
The control value is an authorization ID, not necessarily a DN.
Confidentiality concerns are mentioned.
10.7 Changes from draft-weltman-ldapv3-proxy-04.txt
The control does not apply to bind, unbind, or abandon operations.
The proxy DN is represented as a string in the control, rather than
embedded in a sequence.
Support for the control is published in the supportedControl
attribute of the root DSE, not in supportedExtensions.
The security section mentions confidentiality issues with exposing an
additional identity.
10.8 Changes from draft-weltman-ldapv3-proxy-03.txt
None
10.9 Changes from draft-weltman-ldapv3-proxy-02.txt
The Control is now called Proxied Authorization Control, rather than
Proxied Authentication Control, to reflect that no authentication
occurs as a consequence of processing the Control.
Rather than containing an LDAPDN as the Control value, the Control
contains a Sequence (which contains an LDAPDN). This is to provide
for future extensions.
Expires November 2002 [Page 6]
Expires October 2003 [Page 5]

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 17 May 2002
Expires in six months 20 December 2002
LDAPv3: Requesting Attributes by Object Class
<draft-zeilenga-ldap-adlist-01.txt>
LDAP: Requesting Attributes by Object Class
<draft-zeilenga-ldap-adlist-04.txt>
Status of this Memo
@ -22,8 +22,8 @@ Status of this Memo
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 <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,19 +57,32 @@ Abstract
Zeilenga Requesting Attributes by Object Class [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
1. Overview
LDAP [RFC2251] search operations support mechanisms for requesting
sets of attributes. This set is determined by a list of attribute
descriptions. Two special descriptors are defined to request all user
attributes ("*") and all operational attributes ("+"). However, there
is no convenient mechanism for requesting pre-defined sets of
attributes. This document extends LDAP to allow an object class
identifier to be specified in search request attributes list to
request the return all attributes allowed by object class.
In the Lightweight Directory Access Protocol (LDAP) [RFC3377], the
search operation [RFC2251] support requesting a sets of attributes.
This set is determined by a list of attribute descriptions. Two
special descriptors are defined to request all user attributes ("*")
[RFC2251] and all operational attributes ("+") [OPATTRS]. However,
there is no convenient mechanism for requesting pre-defined sets of
attributes.
This document extends LDAP to allow an object class identifier to be
specified in search request attributes list to request the return all
attributes allowed by object class. A plus sign ("+", U+002B) is used
to distinguish an object class identifier from an attribute
descriptions.
For example, the attribute list of "+country" is equivalent to the
attribute list of 'c', 'searchGuide', 'description', and
'objectClass'. This object class and its attributes are described in
[RFC2256].
This extension is intended to be used where the user is in direct
control of the parameters of the LDAP search operation.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
@ -82,68 +95,81 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
the attributes field of the LDAP SearchRequest [RFC2251]. For each
object class identified in the attributes field, the request is to be
treated as if each attribute allowed by that class (by "MUST" or
"MAY", directly or by SUPerior) was itself listed. For example, a
request for "country" [RFC2256] is treated as if "c", "searchGuide",
"description", and "objectClass" were requested.
As a special case, requesting extensibleObject [RFC2252] is treated as
if "objectClass,*,+" was requested [RFC2251][OPATTRS].
"MAY", directly or by SUPerior) was itself listed.
If the object class identifier is unrecognized, it is be treated an an
unrecognized attribute description.
This extension redefines the attributes field of the SearchRequest to
be a DescriptionList described by the following [ASN.1]:
be a DescriptionList described by the following ASN.1 [X.680] data
type:
DescriptionList ::= SEQUENCE OF Description
Description ::= LDAPString
The Description is string conforming to the [ABNF]:
Description ::= AttributeDescription | ObjectClassDescription.
ObjectDescription ::= ObjectClass *( ";" options )
where AttributeDescription and options productions are as defined in
Section 4.1.5 of [RFC2251] and an ObjectClass is an objectIdentifier,
in either numericoid or descr form [RFC 2252], of an object class.
ObjectDescription options are provided for extensibility. This
The Description is string conforming to the ABNF [RFC2234]:
Zeilenga Requesting Attributes by Object Class [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
document only defines semantics of ObjectDescriptions with zero
options in the attributes field of a SearchRequest. Other uses may be
defined in future specifications.
Description = AttributeDescription | ObjectClassDescription.
ObjectClassDescription = "+" ObjectClass *( ";" options )
where <AttributeDescription> and <options> productions are as defined
in Section 4.1.5 of [RFC2251] and an <ObjectClass> is an object
identifier, in either <numericoid> or <descr> form [RFC2252], of an
object class.
<ObjectClassDescription> <options> are provided for extensibility.
This document only defines semantics of <ObjectClassDescription>s with
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.5.2 as a value of the supportedFeatures [FEATURES]
attribute in the root DSE.
1.3.6.1.4.1.4203.1.11.2 as a value of the 'supportedFeatures'
[FEATURES] attribute in the root DSE.
3. Security Considerations
This extension provides a shorthand for requesting all attributes of
an object class. As these attributes which could have been listed
individually, this short hand is not believed to raises additional
individually, this short hand is not believed to raise additional
security considerations.
Implementors of this (or any) LDAP extension should be familiar with
general LDAP general security considerations [LDAPTS].
general LDAP security considerations [RFC3377].
4. IANA Considerations
No IANA assignments are requested.
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.
This document uses the OID 1.3.6.1.4.1.4203.1.5.2 to identify the LDAP
feature it details. 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
[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
5. Author's Address
@ -158,6 +184,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
[RFC2119] S. Bradner, "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.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
@ -165,34 +194,24 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
Zeilenga Requesting Attributes by Object Class [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
[LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-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).
[OPATTRS] K. Zeilenga, "LDAPv3: All Operational Attributes",
draft-zeilenga-ldap-opattrs-xx.txt (a work in progress).
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 1994.
7. Informative References
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
[RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.
[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.
@ -202,6 +221,13 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
Zeilenga Requesting Attributes by Object Class [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
@ -220,14 +246,6 @@ Copyright 2002, The Internet Society. All Rights Reserved.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Zeilenga Requesting Attributes by Object Class [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
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,
@ -254,24 +272,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002

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

@ -0,0 +1,339 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 11 May 2003
The LDAP Assertion Control
<draft-zeilenga-ldap-assert-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
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
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.
Zeilenga LDAP Assertion Control [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 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.
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.
The control may also be used with the search operation. Here the
assertion is applied to the base object of the search before searching
for objects matching the search scope and filter.
The control may also be used with the compare operation. Here it
extends the compare operation to allow a more complex assertion.
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].
DN stands for Distinguished Name.
DSA stands for Directory System Agent (i.e., a directory 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].
3. The Assertion Control
The assertion control is an LDAP Control [RFC2251] whose controlType
is IANA-ASSIGNED-OID and controlValue is a BER-encoded Filter
[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.
Zeilenga LDAP Assertion Control [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 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.
For Add, Compare, and ModifyDN the target is indicated by the entry
field in the request. For Modify, the target is indicated by the
object field. For Delete, the target is indicated by the DelRequest
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.
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.
Other documents may specify how this control applies to other LDAP
operations. In doing so, they must how the target entry is
determined.
3. Security Considerations
The filter may, like other values 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
to appropriate access controls.
Some assertions may be very complex, requiring significant time and
resources to evaluate. Hence, the mechanism SHOULD be subject to
appropriate administrative controls.
All security considerations for the base operations [RFC2251] to which
this control is attached to apply, as do general LDAP security
considerations [RFC3377].
Zeilenga LDAP Assertion Control [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
4. IANA Considerations
4.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.
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the LDAP Assertion Control
4.2 LDAP Protocol Mechanism
Registration of this protocol mechanism [RFC3383] is requested.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID
Description: Assertion Control
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
4.3 LDAP Result Code
Assignment of an LDAP Result Code [RFC3383] called 'assertionFailed'
is requested.
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: assertionFailed
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
5. Acknowledgments
The assertion control concept is attributed to Morteza Ansari.
Zeilenga LDAP Assertion Control [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
6. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, 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] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
8. Informative References
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
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
Zeilenga LDAP Assertion Control [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
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
Internet organizations, except as needed for the purpose of
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.
Zeilenga LDAP Assertion Control [Page 6]

238
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 17 May 2002
Expires in six months 3 May 2003
LDAP Cancel Extended Operation
<draft-zeilenga-ldap-cancel-05.txt>
<draft-zeilenga-ldap-cancel-08.txt>
1. Status of this Memo
@ -22,8 +22,8 @@ Expires in six months 17 May 2002
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
@ -38,7 +38,7 @@ Expires in six months 17 May 2002
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2002, The Internet Society. All Rights Reserved.
Copyright 2003, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
@ -46,18 +46,18 @@ Expires in six months 17 May 2002
Abstract
This specification describes an LDAP (Lightweight Directory Access
Protocol) extended operation to cancel (or abandon) an outstanding
operation. Unlike the LDAP Abandon operation but like the X.511 DAP
Abandon operation, this operation has a response which provides an
indication of its outcome.
This specification describes a Lightweight Directory Access Protocol
(LDAP) extended operation to cancel (or abandon) an outstanding
operation. Unlike the LDAP Abandon operation but like the X.511
Directory Access Protocol (DAP) Abandon operation, this operation has
a response which provides an indication of its outcome.
Zeilenga LDAP Cancel [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
Conventions
@ -74,16 +74,17 @@ Conventions
1. Background and Intent of Use
LDAP [RFC2251] provides an Abandon operation which clients may use to
cancel other operations. The Abandon operation does not have a
response and also calls for there to be no response of the abandoned
operation. These semantics provide the client with no clear
indication of the outcome of the Abandon operation.
The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides an
Abandon operation [RFC2251] which clients may use to cancel other
operations. The Abandon operation does not have a response and calls
for there to be no response of the abandoned operation. These
semantics provide the client with no clear indication of the outcome
of the Abandon operation.
X.511 DAP [X.511] provides an Abandon operation which does have a
response and also requires the abandoned operation to return a
response with indicating it was canceled. The Cancel operation is
modeled after the DAP Abandon operation.
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.
The Cancel operation SHOULD be used instead of the LDAP Abandon
operation when the client needs an indication of the outcome. This
@ -91,44 +92,41 @@ Conventions
operations.
4. Cancel Operation
2. Cancel Operation
The Cancel operation is defined as a LDAPv3 Extended Operation
[RFC2251, Section 4.12] identified by the OBJECT IDENTIFIER cancelOID.
This section details the syntax of the Cancel request and response
messages and defines additional LDAP resultCodes.
cancelOID OBJECT IDENTIFIER ::= IANA-ASSIGNED
The Cancel operation is defined as a LDAP Extended Operation [RFC2251,
Section 4.12] identified by the IANA-ASSIGNED-OID. This section
details the syntax of the Cancel request and response messages and
defines additional LDAP resultCodes.
cancelRequestValue ::= SEQUENCE {
cancelID MessageID
}
4.1. Cancel Request
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-05 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
containing cancelOID OID and a requestValue field which contains a
cancelRequestValue value encoded per [RFC2251, Section 5.1]. The
cancelID field contains the message id associated with the operation
to be canceled.
a BER-encoded cancelRequestValue value. The cancelID field contains
the message id associated with the operation to be canceled.
4.2. Cancel Response
2.2. Cancel Response
A Cancel response is an ExtendedResponse where the responseName and
response fields are absent.
4.3. Additional Result Codes
2.3. Additional Result Codes
Implementations of this specification SHALL recognize the following
additional resultCode values:
@ -139,7 +137,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
cannotCancel (IANA-ASSIGNED-4)
5. Operational Semantics
3. Operational Semantics
The function of the Cancel Operation is to request that the server
cancel an outstanding operation issued within the same session.
@ -150,9 +148,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
a distinct message id. Clients SHOULD NOT request cancelation of an
operation multiple times.
If the server is unable to parse the requestValue or the requestValue
is absent, the server shall return protocolError.
If the server is willing and able to cancel the outstanding operation
identified by the cancelId, the server SHALL return a Cancel Response
with a success resultCode and the canceled operation SHALL fail with
@ -160,21 +155,23 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
non-success resultCode and SHALL NOT have impact upon the outstanding
operation (if it exists).
The server SHALL return noSuchOperation if it has no knowledge of the
operation requested to be canceled.
The protocolError resultCode is returned if the server is unable to
parse the requestValue or the requestValue is absent,
The server SHALL return cannotCancel if the identified operation does
The noSuchOperation resultCode is returned if the server has no
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-05 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
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
@ -184,75 +181,85 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
- operations which abandon or cancel other operations.
Specifically, Abandon, Bind, Start TLS [RFC2830], Unbind and Cancel
operations are not cancelable.
Specifically, the Abandon, Bind, Start TLS [RFC2830], Unbind and
Cancel operations are not cancelable.
If the result of the outstanding operation has been determined by the
server, the outstanding operation SHALL NOT be canceled and the cancel
operation SHALL result in tooLate.
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.
Servers SHOULD indicate their support for this extended operation by
providing cancelOID 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 and/or has established
the necessary security protections to use this operation. Clients
SHOULD verify the server implements this extended operation prior to
attempting the operation by asserting the supportedExtension attribute
contains a value of cancelOID.
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.
6. Security Considerations
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 (within the same session or not). However, as
this operation may only be used to cancel within the same session and
LDAP requires operations to be abandoned upon bind requests, this is a
non-issue.
issued by another user.
Some operations should not be cancelable for security reasons. This
specification disallows cancelation of Bind operation and Start TLS
extended operation so as to avoid adding complexity to authentication,
authorization, and security layer semantics. Designers of future
extended operations and/or controls SHOULD disallow abandonment and
extended operations and/or controls should disallow abandonment and
cancelation when appropriate.
7. IANA Considerations
5. IANA Considerations
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-05 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
7.1. Object Identifiers
The following registration template is suggested:
It is requested that IANA register a Directory Number OID for use in
this document upon Standards Action by the IESG. This OID will be
used to identify the LDAP Cancel extended operation as indicated
above. The following registration template is suggested:
Subject: Request for LDAP OID Registration
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFCXXX
Specification: RFCXXXX
Author/Change Controller: IESG
Comments:
Identifies the LDAP Cancel Extended Operation
7.2. LDAP Result Codes
5.2. LDAP Protocol Mechanism
It is requested that IANA register the LDAP result codes:
It is requested that IANA register upon Standards Action the LDAP
Protocol Mechanism described in this document.
canceled (IANA-ASSIGNED-1)
noSuchOperation (IANA-ASSIGNED-2)
tooLate (IANA-ASSIGNED-3)
cannotCancel (IANA-ASSIGNED-4)
Subject: Request for LDAP Protocol Mechansism Registration
Object Identifier: IANA-ASSIGNED-OID
Description: LDAP Cancel Extended Operation
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFCXXXX
Author/Change Controller: IESG
Comments: none
in 2
upon Standards Action by the IESG. The following registration
template is suggested:
5.3. LDAP Result Codes
It is requested that IANA register upon Standards Action the LDAP
Result Codes described in this document.
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
@ -266,24 +273,25 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
Comments: request four consecutive result codes be assigned
8. Acknowledgment
This document is based upon input from the IETF LDAPext working group.
9. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
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-05 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
operation.
7. Normative References
[RFC2119] S. Bradner, "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.
@ -291,6 +299,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 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.
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification
of Basic Notation", X.680, 1994.
@ -298,26 +309,37 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
Canonical, and Distinguished Encoding Rules", X.690, 1994.
9. Informative References
8. Informative References
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
September 2002.
[X.511] ITU-T, "The Directory: Abstract Service Definition", X.511,
1993.
11. Author's Address
9. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
Copyright 2002, The Internet Society. All Rights Reserved.
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
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
@ -332,14 +354,6 @@ Copyright 2002, The Internet Society. All Rights Reserved.
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,
Zeilenga LDAP Cancel [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
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.
@ -363,20 +377,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002

104
doc/drafts/draft-zeilenga-ldap-collective-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 May 2002
Expires in six months 18 August 2002
Collective Attributes in LDAP
<draft-zeilenga-ldap-collective-07.txt>
<draft-zeilenga-ldap-collective-08.txt>
Status of this Memo
@ -22,8 +22,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
@ -55,9 +55,9 @@ Abstract
Zeilenga draft-zeilenga-ldap-collective-07 [Page 1]
Zeilenga draft-zeilenga-ldap-collective-08 [Page 1]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
Conventions
@ -111,9 +111,9 @@ Conventions
Zeilenga draft-zeilenga-ldap-collective-07 [Page 2]
Zeilenga draft-zeilenga-ldap-collective-08 [Page 2]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
2. System Schema for Collective Attributes
@ -167,9 +167,9 @@ INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
Zeilenga draft-zeilenga-ldap-collective-07 [Page 3]
Zeilenga draft-zeilenga-ldap-collective-08 [Page 3]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
The descriptor excludeAllCollectiveAttributes is associated with the
@ -223,9 +223,9 @@ INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
Zeilenga draft-zeilenga-ldap-collective-07 [Page 4]
Zeilenga draft-zeilenga-ldap-collective-08 [Page 4]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
3.2. Collective State or Province Name
@ -279,9 +279,9 @@ INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
Zeilenga draft-zeilenga-ldap-collective-07 [Page 5]
Zeilenga draft-zeilenga-ldap-collective-08 [Page 5]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
collection of entries.
@ -335,9 +335,9 @@ INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
Zeilenga draft-zeilenga-ldap-collective-07 [Page 6]
Zeilenga draft-zeilenga-ldap-collective-08 [Page 6]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
SUP facsimileTelephoneNumber COLLECTIVE )
@ -354,17 +354,26 @@ INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
4. Security Considerations
Collective attributes are not believed to introduce any additional
security considerations to LDAP [LDAPTS].
Collective attributes, like other attributes, are subject to access
control restrictions and other administrative policy. Generally
speaking, collective attributes accessed via an entry in a collection
are governed by rules restricting access to attributes of that entry.
And collective attributes access via a subentry are governed by rules
restricting access to attributes of that subentry. However, as LDAP
does not have a standard access model, the particulars of each
server's access control system may differ.
General LDAP security considerations [LDAPTS] also apply.
5. IANA Considerations
It is requested that IANA register the LDAP descriptors used in this
document per the following registration template:
It is requested that IANA register upon Standards Action the LDAP
descriptors [LDAPIANA] defined in this technical specification. The
following registration template is suggested:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): see comment
Descriptor see comments
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
@ -379,6 +388,14 @@ INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
c-InternationalISDNNumber A 2.5.4.25.1
c-PhysicalDeliveryOffice A 2.5.4.19.1
c-PostOfficeBox A 2.5.4.18.1
Zeilenga draft-zeilenga-ldap-collective-08 [Page 7]
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
c-PostalAddress A 2.5.4.16.1
c-PostalCode A 2.5.4.17.1
c-TelephoneNumber A 2.5.4.20.1
@ -388,14 +405,6 @@ INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
c-ou A 2.5.4.11.1
c-st A 2.5.4.8.1
c-street A 2.5.4.9.1
Zeilenga draft-zeilenga-ldap-collective-07 [Page 7]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
collectiveAttributeSubentries A 2.5.18.12
collectiveAttributeSubentry O 2.5.20.2
collectiveExclusions A 2.5.18.7
@ -403,10 +412,11 @@ INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
where Type A is Attribute and Type O is ObjectClass.
This document uses in this document were assigned by the ISO/IEC Joint
Technical Committee 1 - Subcommitte 6 to identify elements of X.500
schema. This document make no OID assignments, it only associates
LDAP schema descriptions with existing elements of X.500 schema.
The Object Identifiers used in this document were assigned by the
ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify
elements of X.500 schema [X.520]. This document make no OID
assignments, it only provides LDAP schema descriptions with existing
elements of X.500 schema.
6. Acknowledgments
@ -434,6 +444,14 @@ INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
Zeilenga draft-zeilenga-ldap-collective-08 [Page 8]
INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
[RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
@ -444,14 +462,6 @@ INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
[SUBENTRY] K. Zeilenga, S. Legg, "Subentries in LDAP",
draft-zeilenga-ldap-subentry-xx.txt, a work in progress.
Zeilenga draft-zeilenga-ldap-collective-07 [Page 8]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
[X.501] "The Directory: Models", ITU-T Recommendation X.501, 1993.
@ -493,15 +503,5 @@ Copyright 2002, The Internet Society. All Rights Reserved.
Zeilenga draft-zeilenga-ldap-collective-07 [Page 9]
Zeilenga draft-zeilenga-ldap-collective-08 [Page 9]

204
doc/drafts/draft-zeilenga-ldap-features-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 May 2002
Expires in six months 26 May 2003
Feature Discovery in LDAP
<draft-zeilenga-ldap-features-03.txt>
<draft-zeilenga-ldap-features-05.txt>
Status of this Memo
@ -22,8 +22,8 @@ Status of this Memo
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 <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
@ -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
@ -55,23 +55,34 @@ Abstract
Zeilenga draft-zeilenga-ldap-features-03 [Page 1]
Zeilenga draft-zeilenga-ldap-features-05 [Page 1]
INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
1. Background and Intended Use
LDAP [RFC2251] is an extensible protocol with numerous elective
features. LDAP provides mechanisms for a client to discover supported
protocol versions, controls, extended operations, SASL mechanisms, and
subschema information. However, these mechanisms are not designed to
support general feature discovery.
The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
extensible protocol with numerous elective features. LDAP provides
mechanisms for a client to discover supported protocol versions,
controls, extended operations, Simple Authentication and Security
Layer (SASL) mechanisms, and subschema information. However, these
mechanisms are not designed to support general feature discovery.
This document describes a simple, general-purpose mechanism which
clients may use to discover the set of features supported by a server.
clients may use to discover the set of elective features supported by
a server. For example, this mechanism could be used by a client to
discover whether or not the server supports requests for all
operational attributes, e.g. "+" [OPATTRS]. As another example, this
mechanism could be used to discover absolute true, e.g. "(&)" and
false, e.g. "(|)", search filters [T-F] support.
Schema definitions are provided using LDAPv3 description formats
This document extends the LDAP Protocol Mechanism registry [RFC3383]
to support registration of values of the supportedFeatures attribute.
This registry is managed by the Internet Assigned Numbers Authority
(IANA).
Schema definitions are provided using LDAP description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
@ -82,14 +93,30 @@ INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
2. Discovery of supported features
Each feature whose support may be discovered SHALL be identified by an
Object Identifier (OID). A server advertises its support for a given
feature by providing the OID associated with the feature as a value of
the supportedFeatures attribute held in the root DSE. A client may
examine the values of this attribute to determine if a particular
feature is supported by the server.
Each elective feature whose support may be discovered SHALL be
identified by an Object Identifier (OID). A server advertises its
support for a given feature by providing the OID associated with the
feature as a value of the 'supportedFeatures' attribute held in the
root DSE. A client may examine the values of this attribute to
determine if a particular feature is supported by the server. A
client MUST ignore values it doesn't recognize as they refer to
elective features it doesn't implement.
The supportedFeatures attribute type is described as follows:
Features associated with Standard Track protocol mechanisms MUST be
registered. Features associated with other protocol mechanisms SHOULD
be registered. Procedures for registering protocol mechanisms are are
described in [RFC3383]. "Feature" should be placed in the usage field
of the submitted LDAP Protocol Mechanism template.
Zeilenga draft-zeilenga-ldap-features-05 [Page 2]
INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
The 'supportedFeatures' attribute type is described as follows:
( 1.3.6.1.4.1.4203.1.3.5
NAME 'supportedFeatures'
@ -103,24 +130,29 @@ INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
other names.
3. Security Considerations
4. Security Considerations
As rogue clients can discover features of a server by other means
(such as by trial and error), this feature discovery mechanism is not
believed to introduce any new security risk to LDAP.
5. IANA Considerations
Zeilenga draft-zeilenga-ldap-features-03 [Page 2]
INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
5.1. Registration of Features as Protocol Mechanisms
Future specifications detailing LDAP features are to register each
feature as a LDAP Protocol Mechanism per guidance given in BCP 64
[RFC3383]. A usage of "Feature" in a Protocol Mechanism registration
template indicates that the value to be registered is associated with
an LDAP feature.
4. IANA Considerations
5.2. Registration of the supportedFeatures descriptor
It is requested that IANA register the LDAP 'supportedFeatures'
descriptor used in this document per the following registration
template:
It is requested that IANA register upon Standards Action the LDAP
'supportedFeatures' descriptor. The following registration template
is suggested:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): supportedFeatures
@ -128,57 +160,105 @@ INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Attribute Type
Specification: RFCXXXX
Specification: RFC XXXX
Author/Change Controller: IESG
This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
Zeilenga draft-zeilenga-ldap-features-05 [Page 3]
INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
assigned private enterprise allocation [PRIVATE] for use in this
specification.
5. Acknowledgment
6. Acknowledgment
This document is based upon input from the IETF LDAPext working group.
This document is based upon input from the IETF LDAPEXT working group.
6. Author's Address
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
7. Normative References
8. 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.
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
8. Informative References
9. Informative References
[OPATTRS] Zeilenga, K., "LDAPv3: All Operational Attributes",
draft-zeilenga-ldap-opattrs-xx.txt, a work in progress.
[T-F] Zeilenga, K., "LDAP True/False Filters",
draft-zeilenga-ldap-t-f-xx.txt, a work in progress.
[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 draft-zeilenga-ldap-features-03 [Page 3]
Zeilenga draft-zeilenga-ldap-features-05 [Page 4]
INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
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 2002, The Internet Society. 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
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
@ -189,15 +269,6 @@ Full Copyright
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.
@ -208,20 +279,5 @@ Full Copyright
Zeilenga draft-zeilenga-ldap-features-03 [Page 4]
Zeilenga draft-zeilenga-ldap-features-05 [Page 5]

843
doc/drafts/draft-zeilenga-ldap-grouping-xx.txt Normal file
View file

@ -0,0 +1,843 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 3 May 2003
LDAP: Grouping of Related Operations
<draft-zeilenga-ldap-grouping-06.txt>
Status of Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
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.
Abstract
This document provides a general mechanism for grouping related
Lightweight Directory Access Protocol (LDAP) operations. Grouping of
operations can be used to support replication, proxies, and
transactions.
Zeilenga LDAP Grouping [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
Conventions
Schema definitions are provided using LDAP description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
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].
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].
1. Introduction
This document provides a general mechanism for grouping related
Lightweight Directory Access Protocol (LDAP) [RFC3377] operations.
Grouping of operations can be used to support replication, proxies,
and high level operations such as transactions [TXNGRP].
This document describes a set of LDAP extended operations [RFC2251]
and other protocol and schema elements to support grouping of related
operations. Uses of this grouping mechanism will be detailed in
separate documents.
A group of operations is defined as a set of operations within a
common session identified by a unique cookie. All requests which are
initiated with the same cookie belong to the same grouping. The
cookie is obtained using the create group operation and is normally
valid until the end group operation is completed. A group can end
prematurely as described below.
Operations can be intermixed regardless of their grouping (or lack of
grouping). Groups can be nested.
Each group is of a particular type specified when the group is
created. This type defines the semantics of the group.
2. Protocol Elements
This document describes three extended operations, two unsolicited
notification, and one control. Extended operations and controls are
described by LDAP [RFC2251] and provide here for convenience:
Zeilenga LDAP Grouping [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL
}
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS of LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL
}
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL
}
2.1 Common Protocol Elements
groupCookie ::= OCTET STRING
A groupCookie is an octet string used to uniquely identify a grouping
of related operations within the session. A groupCookie is a
notational convenience.
2.2 Create Grouping Operation
The Create Grouping extended operation is used to create or start a
grouping of related operations. The operation consists of the
createGroupingRequest and the createGroupingResponse. The object
identifier createGroupingOID identifies this operation and SHOULD be
listed as a value of supportedExtension in the root DSE of servers
which support this operation.
createGroupingOID ::= "IANA-ASSIGNED-OID.1"
2.2.1 createGroupingRequest
The client initiates this operation by sending a
createGroupingRequest. This request is an ExtendedRequest where the
requestName is the object identifier createGroupOID and requestValue
is BER-encoded createGroupingRequestValue:
createGroupingRequestValue ::= SEQUENCE {
createGroupType [0] LDAPOID,
Zeilenga LDAP Grouping [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
createGroupValue [1] OCTET STRING OPTIONAL
}
where createGroupType is an object identifier that describes the
specific type of grouping and createGroupValue contains a type
specific payload.
2.2.2 createGroupingResponse
The createGroupingResponse is sent in response to a
createGroupingRequest. This response is an ExtendedResponse where the
responseName MUST be the value of the requestName provided in the
request and the response is a BER-encoded createGroupingResponseValue:
createGroupingResponseValue ::= SEQUENCE {
createGroupCookie [0] groupCookie OPTIONAL,
createGroupValue [1] OCTET STRING OPTIONAL
}
where createGroupCookie, if present, is a cookie uniquely identifying
the new grouping and createGroupValue is a type specific payload. The
createGroupCookie only when the operation results in the creation of a
group. Otherwise, it is absent.
2.3 End Grouping Operation
The End Grouping extended operation is used to end or stop a grouping
of related operations. The operation consists of the
endGroupingRequest and the endGroupingResponse. The object identifier
endGroupingOID identifies this operation and SHOULD be listed as a
value of supportedExtension in the root DSE of servers which support
this operation.
endGroupingOID ::= "IANA-ASSIGNED-OID.2"
2.3.1 endGroupingRequest
The client initiates this operation by sending an endGroupingRequest.
This request is an ExtendedRequest where the requestName is the object
identifier endGroupOID and requestValue is BER-encoded
endGroupingRequestValue:
endGroupingRequestValue ::= SEQUENCE {
endGroupCookie [0] groupCookie,
endGroupValue [1] OCTET STRING OPTIONAL
Zeilenga LDAP Grouping [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
}
where endGroupCookie is a cookie identifying the grouping and
endGroupValue contains a type specific payload.
2.3.2 endGroupingResponse
The endGroupingResponse is sent in response to a endGroupingRequest.
This response is an ExtendedResponse where the responseName MUST be
the value of the requestName provided in request and the response is a
BER-encoded endGroupingResponseValue:
endGroupingResponseValue ::= SEQUENCE {
endGroupValue [1] OCTET STRING OPTIONAL
}
where endGroupValue is a type specific payload.
2.4 endGroupingNotice
The endGroupingNotice is an LDAP unsolicited notification. The
notification may be sent to the client to end a grouping which the
server is unable or unwilling to continue to process. The notice is
an extendedResponse where the responseName is the object identifier
endGroupingNoticeOID and the response is a BER-encoded
endGroupingNoticeValue:
endGroupingNoticeOID ::= "IANA-ASSIGNED-OID.3"
endGroupingNoticeValue ::= SEQUENCE {
endGroupingCookie [0] groupCookie,
endGroupValue [1] OCTET STRING OPTIONAL
}
where endGroupingCookie is a cookie uniquely identifying the grouping
and endGroupValue contains a type specific payload.
2.5 Action Grouping Operation
The Action Grouping extended operation is used to take an action
affecting a grouping of related operations. The operation consists of
the actionGroupingRequest and the actionGroupingResponse. The object
identifier actionGroupingOID identifies this operation and SHOULD be
listed as a value of supportedExtension in the root DSE of servers
which support this operation.
Zeilenga LDAP Grouping [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
actionGroupingOID ::= "IANA-ASSIGNED-OID.4"
2.5.1 actionGroupingRequest
The client initiates this operation by sending an
actionGroupingRequest. This request is an ExtendedRequest where the
requestName is the object identifier actionGroupOID and requestValue
is BER-encoded actionGroupingRequestValue:
actionGroupingRequestValue ::= SEQUENCE {
actionGroupCookie [0] groupCookie,
actionGroupValue [1] OCTET STRING OPTIONAL
}
where actionGroupCookie is a cookie identifying the grouping and
actionGroupValue contains a type specific payload.
2.5.2 actionGroupingResponse
The actionGroupingResponse is sent in response to a
actionGroupingRequest. This response is an ExtendedResponse where the
responseName MUST be the value of the requestName provided in request
and the response is a BER-encoded actionGroupingResponseValue:
actionGroupingResponseValue ::= SEQUENCE {
actionGroupValue [1] OCTET STRING OPTIONAL
}
where actionGroupValue is a type specific payload.
2.6 infoGroupingNotice
The infoGroupingNotice is an LDAP unsolicited notification. The
notice may be sent to the client to provide additional grouping type
specific information. The notice is an extendedResponse where the
responseName is the object identifier infoGroupingNoticeOID and the
response is a BER-encoded infoGroupingNoticeValue:
infoGroupingNoticeOID ::= "IANA-ASSIGNED-OID.5"
infoGroupingNoticeValue ::= SEQUENCE {
infoGroupingCookie [0] groupCookie,
infoGroupValue [1] OCTET STRING OPTIONAL
}
Zeilenga LDAP Grouping [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
where infoGroupingCookie is a cookie uniquely identifying the grouping
and infoGroupValue contains a type specific payload.
2.7 groupingControl
The groupingControl is used to identify requests and responses as
belonging to a grouping of operations. The groupingControl is a
Control where the controlType is the object identifier
groupingControlOID, the criticality is TRUE, and the controlValue is a
BER-encoded groupingControlValue:
groupingControlOID ::= "IANA-ASSIGNED-OID.6"
groupingControlValue ::= SEQUENCE {
groupingCookie [0] groupCookie,
groupValue [1] OCTET STRING OPTIONAL
}
where groupingCookie is a cookie uniquely identifying the grouping and
groupingValue contains a type specific payload.
The value groupingControlOID SHOULD be listed as a value of
supportedControl in the root DSE by servers which support this
control.
The control SHALL NOT appear multiple times in the same LDAP PDU. If
multiple occurrences of the control are detected, the PDU SHALL be
treated as a protocol error.
3. Schema Elements
The document describes one attribute type.
3.1. supportedGroupingTypes
Servers SHOULD publish grouping types they support listing group type
object identifiers as values of the supportedGroupingTypes attribute
type in the root DSE. The supportedGroupingTypes attribute type is
defined as:
( IANA-ASSIGNED-OID.7 NAME 'supportedGroupingTypes'
DESC 'supported types of groupings of operations'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
Zeilenga LDAP Grouping [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
The objectIdentifierMatch and OBJECT IDENTIFIER
(1.3.6.1.4.1.1466.115.121.1.38) are defined in [RFC2252].
Servers MUST be capable of recognizing this attribute type by the name
'supportedGroupingTypes'. Servers MAY recognize the attribute type by
other names.
4. Operational Semantics
This section details the common semantics of groups of related
operations. Additional semantics may be associated with each
grouping type as described by other documents.
4.1 Grouping Semantics
This subsection details semantics of the protocol elements introduced
in Section 2.
4.1.1 Create Grouping
To group related operations, the client MUST request a groupCookie
from the server by sending a createGroupingRequest as described in
Section 2.2.1. The client SHALL provide type specific payload in
createGroupValue if so required by the grouping type.
The server SHALL respond with a createGroupingResponse as described in
Section 2.2.2. If the server is willing and able to create the
grouping as requested (and per type requirements), it SHALL respond
with success, provide a session-unique groupCookie and, if
appropriate, a type specific payload. Otherwise the server SHALL
respond with a non-successful response containing no groupCookie, but
MAY, if appropriate, provide a type specific payload.
4.1.2 End Grouping
When the client wishes to end the grouping, the client SHALL send a
endGroupingRequest as described in Section 2.3.1. The client SHALL
provide the groupCookie of the grouping to end and MAY provided a type
specific payload. If the grouping to end contains active nested
groupings, these are implicitly ended as well without notice. The
server SHALL respond with an endGroupingResponse as described in
Section 2.3.2.
Zeilenga LDAP Grouping [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
4.1.3 End Group Notice
The server MAY end a group without solicitation for any reason. The
server SHALL notify the client of this action by sending a endGrouping
Notice, as described in Section 2.4. The server SHALL provide the
groupCookie of the group it terminated and MAY provide a type specific
payload. The notice SHALL have a non-success resultCode.
If the group contains nested groups, the nested groups are implicitly
ended as well without additional notice.
4.1.4 Action Grouping
To perform an action within a group of related operations, the client
sends to the server actionGroupingRequest as described in Section
2.5.1. The client SHALL provide the groupCookie of the group the
operation is requested upon and, if required by the grouping type, a
type specific payload.
The server SHALL respond with a actionGroupingResponse as described in
Section 2.5.2. The server SHALL, if required by the grouping type,
provide type specific payload.
4.1.5 Info Grouping Notice
As allowed by the grouping type, the server MAY provide to the client
a notice regarding the grouping of related operations in an
infoGroupingNotice as described in Section 2.6. The server SHALL, if
required by the grouping type, provide type specific payload.
4.2 Nested groupings
Groups of the same or different types MAY be nested. A nested group
is instantiated by providing a groupingControl containing the parent
group's cookie with the createGroupingRequest.
Group type specifications MAY restrict the types of groupings which
may be nested. Servers MAY also place additional restrictions upon
nesting. Clients SHOULD NOT assume support for arbitrary nesting.
4.3 Intermixing of unrelated operations
LDAP is designed to allow clients to perform unrelated tasks
concurrently. In keeping with this design, operations which unrelated
Zeilenga LDAP Grouping [Page 9]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
to the grouping are generally allowed be intermixed with grouped
operations. (See Section 4.5 for specific exceptions to this general
rule.) It is noted that undue restrictions often unrelated operation
cause unnecessary serialization of independent tasks, place
unnecessary burden upon implementors, and can limit extensibility.
Group type specifications SHOULD NOT disallow unrelated operations
from being intermixed with grouped operations.
Note: a grouping which disallows unrelated operatoins from being
intermixed with grouped operations can be viewed as providing
"framing" semantics.
4.4 Grouped operations
Interrogation (compare, search) and update (add, delete, modify,
rename) MAY be grouped. Certain extended operations MAY also be
grouped, but those which affect the session as a whole, such as Start
TLS, MUST NOT be grouped.
Requests and Responses associated with grouped operations contain a
groupingControl control as described in Section 2.7.
Group type specifications MAY restrict the kind and/or number of
operations which may be related. Servers MAY place additional
restrictions upon groupings. Clients SHOULD NOT assume support for
arbitrary grouping.
4.5 Other Operations
Upon issuing any grouping operation, the semantics of following
operations listed is modified as described below.
4.5.1 abandon
The abandon operation SHOULD NOT be used to cancel grouped operations.
The Cancel operation is to be used instead (as discussed in 4.5.3).
4.5.2 bind
The client SHOULD end all outstanding groupings before issuing a bind
request. The server SHALL, in addition to the behavior described in
[RFC2251] and [RFC2829], abandon all outstanding groups. No
endGroupingNotice notification is sent upon such abandonment.
Zeilenga LDAP Grouping [Page 10]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
A Bind operation cannot be related to other operations using this
grouping mechanism. The bind messages SHOULD NOT contain
groupingControl controls and, if present, SHALL be treated as a a
protocol error.
4.5.3 cancel
The cancel operation [CANCEL] MAY be used to cancel grouped operations
but SHOULD NOT contain a groupingControl control unless the group type
calls for a type specific payload to be provided. The groupingCookie
in the provided groupingControl control MUST be the same associated
with the operation to be canceled, otherwise the cancel request SHALL
be treated as an error.
4.5.4 Start TLS
The client SHOULD end all outstanding groupings before issuing a Start
TLS [RFC2930] request. If there are any outstanding groupings, the
server MUST return operationsError in response to a StartTLS request.
Start TLS operation cannot be related to other operations using this
grouping mechanism and the Start TLS request and response PDUs SHALL
NOT contain a groupingControl control.
4.5.5 unbind
The server SHALL, in addition to the behavior described in [RFC2251],
abandon all outstanding groups. No endGroupingNotice is sent upon
such abandonment. An unbind operation cannot be related to other
operations using this grouping mechanism. The unbind request SHOULD
NOT contain a groupingControl control and, if present, SHALL be
ignored.
5. Profiling Requirements
Documents detailing extensions using the grouping mechanism MUST
provide a profile of its use of the mechanism.
The profile SHALL specify the object identifier to be used to uniquely
identify each grouping type it defines. Object identifiers used to
identity group types, like other protocol elements, SHALL be delegated
in accordance with BCP 64 [RFC3383] and registered as LDAP Protocol
Mechanisms [RFC3383] as detailed in Section 7.1 of this document.
The profile SHALL state which protocol elements of the mechanism it
Zeilenga LDAP Grouping [Page 11]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
uses.
Each of the grouping protocol elements defined in this document allow
transfer of type specific payloads. For each protocol element used,
the profile SHALL state whether the element is to carry a type
specific payload or not and SHALL fully describe the syntax and
semantics associated with each type specific payload.
The profile MAY define grouping type specific semantics which place
further restrictions upon the grouping related operations.
6. Security Considerations
This mechanism can be used to support complex groupings of related
operations. With such complexity comes inherit risk. Specifications
of uses of this mechanism should take special care to address security
issues. In particular, denial of service and authentication,
authorization, and access-control issues should be addressed in
documents detailing uses of this grouping mechanism.
7. IANA Considerations
7.1. Future Registration of Grouping Types
Future specifications which detail LDAP grouping types are to register
each grouping type as a LDAP Protocol Mechanism per guidance given in
BCP 64 [RFC3383]. A usage of "Grouping Type" in a Protocol Mechanism
registration template indicates that the value to be registered is
associated with an LDAP Grouping Type.
7.2. Object Identifier Registration
It is requested that IANA register upon Standards Action an LDAP
Object Identifier to identify protocol elements defined in this
technical specification. The following registration template is
suggested:
Subject: Request for LDAP OID Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFCXXXX
Author/Change Controller: IESG
Comments:
Identifies elements of the LDAP Grouping Operation
Zeilenga LDAP Grouping [Page 12]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
7.3. LDAP Protocol Mechanism
It is requested that IANA register upon Standards Action the LDAP
protocol mechanism described in this document. The following
registration template is suggested:
Subject: Request for LDAP Protocol Mechansism Registration
Object Identifier: IANA-ASSIGNED-OID
Description: See comments
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFCXXXX
Author/Change Controller: IESG
Comments: none
Object Identifier Type Description
------------------- ---- -------------------------
IANA-ASSIGNED-OID.1 E Create Grouping Operation
IANA-ASSIGNED-OID.2 E End Grouping Operation
IANA-ASSIGNED-OID.4 E Action Grouping Operation
in 2
7.4. supportedGroupingTypes Registration
It is requested that IANA register upon Standards Action the LDAP
'supportedGroupingTypes' descriptor. The following registration
template is suggested:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): supportedGroupingTypes
Object Identifier: IANA-ASSIGNED-OID.7
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Attribute Type
Specification: RFCXXXX
Author/Change Controller: IESG
8. Acknowledgments
The author gratefully acknowledges the contributions of the IETF
LDAPext and LDUP working groups. In particular, Roger Harrison
provided many useful suggestions. Also, the author notes that this
document builds upon the early works "Extended Operations for Framing
LDAP Operations" by Ellen Stokes, Roger Harrison, and Gordon Good and
Zeilenga LDAP Grouping [Page 13]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
"Profile for Framing LDAPv3 Operations" by Roger Harrison.
9. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
10. References
10.1 Normative References
[RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, S. Kille, T. Howes, "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.
[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000.
[RFC2830] J. Hodges, R. Morgan, 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.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 1994.
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", X.690, 1994.
10.2. Informative References
[TXNGRP] K. Zeilenga, "LDAP Transactions" (a work in progress),
Zeilenga LDAP Grouping [Page 14]
INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
draft-zeilenga-ldap-txn-xx.txt.
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
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
Internet organizations, except as needed for the purpose of
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.
Zeilenga LDAP Grouping [Page 15]

132
doc/drafts/draft-zeilenga-ldap-opattrs-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
LDAPv3: All Operational Attributes
<draft-zeilenga-ldap-opattrs-03.txt>
<draft-zeilenga-ldap-opattrs-05.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 Extensions 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
@ -48,7 +48,7 @@ Status of this Memo
Abstract
The Lightweight Directory Access Protocol (LDAP) supports a mechanism
for requesting the return of all user attributes but does not all
for requesting the return of all user attributes but not all
operational attributes. This document describes an LDAP extension
which clients may use to request the return of all operational
attributes.
@ -57,7 +57,7 @@ Abstract
Zeilenga LDAP All Op Attrs [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
1. Overview
@ -67,11 +67,11 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
to a search operation. This mechanism is often used by clients to
discover which operational attributes are present in an entry.
This documents extends LDAP [RFC2251] to provide a simple mechanism
which clients may use to request the return of all operation
attributes. The mechanism is designed for use with existing general
purpose LDAP clients (including web browsers which support LDAP URLs)
and existing LDAP API.
This documents extends the Lightweight Directory Access Protocol
(LDAP) [RFC3377] to provide a simple mechanism which clients may use
to request the return of all operational attributes. The mechanism is
designed for use with existing general purpose LDAP clients (including
web browsers which support LDAP URLs) and existing LDAP APIs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
@ -81,19 +81,19 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
2. All Operational Attributes
The presence of the attribute description "+" (ASCII 43) in the list
of attributes in a Search Request SHALL signify a request for the
return of all operational attributes.
of attributes in a Search Request [RFC2251] SHALL signify a request
for the return of all operational attributes.
As with all search requests, client implementors should note that
results may not include all requested attributes due to access
controls or other restrictions. Clients implementors should also note
controls or other restrictions. Client implementors should also note
that certain operational attributes may be returned only if requested
by name even when "+" is present. This is because some operational
attributes are very expensive to return.
Servers supporting this feature SHOULD publish the Object Identifier
1.3.6.1.4.1.4203.1.5.1 as a value of the supportedFeatures [FEATURES]
attribute in the root DSE.
1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures'
[FEATURES] attribute in the root DSE.
3. Interoperability Considerations
@ -101,22 +101,21 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
This mechanism is specifically designed to allow users to request all
operational attributes using existing LDAP clients. In particular,
the mechanism is designed to be compatible with existing general
purpose LDAP clients includes web browsers which support LDAP URLs
[RFC2255].
purpose LDAP clients including those supporting LDAP URLs [RFC2255].
The addition of this mechanism to LDAPv3 is believed not to cause any
The addition of this mechanism to LDAP is not believed to cause any
significant interoperability issues (this has been confirmed through
testing). Servers which have yet to implement this specification
testing). Servers which have yet to implement this specification
should ignore the "+" as an unrecognized attribute description per
[RFC2251, Section 4.5.1]. From the client's perspective, a server
Zeilenga LDAP All Op Attrs [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
[RFC2251, Section 4.5.1]. From the client's perspective, a server
which does not return all operational attributes when "+" is requested
should be viewed as having other restrictions.
@ -126,24 +125,53 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
4. Security Considerations
This document provides a mechanism which clients may use to discover
operational attributes. Those relying on security by obscurity SHOULD
implement appropriate access controls to restricts access to
operational attributes per local policy.
This document provides a general mechanism which clients may use to
discover operational attributes. Prior to the introduction of this
mechanism, operational attributes where only returned when requested
by name. Some might have viewed this as obscurity" feature. However,
this sense of security as the attributes were still transferable.
Implementations SHOULD implement appropriate access controls
mechanisms to restricts access to operational attributes.
5. IANA Considerations
No IANA assignments are requested.
This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the
feature described above. This OID was assigned [ASSIGN] by OpenLDAP
Foundation under its IANA assigned private enterprise allocation
[PRIVATE] for use in this specification.
Foundation, under its IANA-assigned private enterprise allocation
[PRIVATE], for use in this specification.
Registration of this feature is requested [FEATURES][RFC3383].
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.5.1
Description: All Op Attrs
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
Specification: RFCxxxx
Author/Change Controller: IESG
Comments: none
6. Acknowledgment
Zeilenga LDAP All Op Attrs [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
The "+" mechanism is believed to have been first suggested by Bruce
Greenblatt in a November 1998 post to the IETF LDAPext Working Group
mailing list.
@ -164,13 +192,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
Zeilenga LDAP All Op Attrs [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
[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).
@ -181,6 +204,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
[RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
[RFC3383] K. Zeilenga, "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.
@ -194,6 +220,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
Zeilenga LDAP All Op Attrs [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
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,
@ -223,5 +257,27 @@ Copyright 2002, The Internet Society. All Rights Reserved.
Zeilenga LDAP All Op Attrs [Page 4]
Zeilenga LDAP All Op Attrs [Page 5]

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

@ -6,12 +6,12 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Date: 17 May 2002 Steven Legg
Date: 18 August 2002 Steven Legg
Expires in six months Adacel Technologies
Subentries in LDAP
<draft-zeilenga-ldap-subentry-05.txt>
<draft-zeilenga-ldap-subentry-07.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
@ -55,9 +55,9 @@ Abstract
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 1]
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 1]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
INTERNET-DRAFT Subentries in LDAP 18 August 2002
Conventions
@ -111,9 +111,9 @@ Conventions
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 2]
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 2]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
INTERNET-DRAFT Subentries in LDAP 18 August 2002
lower boundary, possibly extending to the leaf entries. A subtree
@ -167,9 +167,9 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 3]
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 3]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
INTERNET-DRAFT Subentries in LDAP 18 August 2002
constraints on the components of SubtreeSpecification.
@ -223,9 +223,9 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 4]
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 4]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
INTERNET-DRAFT Subentries in LDAP 18 August 2002
Entries that are more than the maximum number of RDN arcs below the
@ -279,9 +279,9 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 5]
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 5]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
INTERNET-DRAFT Subentries in LDAP 18 August 2002
The administrativeRole operational attribute is also used to regulate
@ -335,9 +335,9 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 6]
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 6]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
INTERNET-DRAFT Subentries in LDAP 18 August 2002
The controlValue SHALL NOT be absent.
@ -364,8 +364,9 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
5.1 Descriptors
It is requested that IANA register the LDAP descriptors used in this
document per the following registration template:
It is requested that IANA register upon Standards Action the LDAP
descriptors detailed in this technical specification. The following
registration template is suggested:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): see comment
@ -387,27 +388,26 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
collectiveAttributeSpecificArea R 2.5.23.5
subentry O 2.5.20.0
subschemaAdminSpecificArea R 2.5.23.4
subtreeSpecification A 2.5.18.6
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 7]
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 7]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
INTERNET-DRAFT Subentries in LDAP 18 August 2002
subtreeSpecification A 2.5.18.6
where Type A is Attribute, Type O is ObjectClass, and Type R is
Administrative Role.
5.2 Object Identifiers
No IANA assignment of object identifiers is requested.
This document uses the OID 1.3.6.1.4.1.4203.1.10.1 to identify an LDAP
protocol element defined herein. This OID was assigned [ASSIGN] by
OpenLDAP Foundation under its IANA assigned private enterprise
allocation [PRIVATE] for use in this specification.
OpenLDAP Foundation, under its IANA-assigned private enterprise
allocation [PRIVATE], for use in this specification.
Other OIDs which appear in this document were either assigned by the
ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify
@ -415,6 +415,29 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
here.
5.3 Protocol Mechanisms
Registration of the protocol mechanisms defined in this document is
requested [LDAPIANA].
Subject: Request for LDAP Protocol Mechansism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.10.1
Description: Subentries
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
Specification: RFCxxxx
Author/Change Controller: IESG
Comments: none
6. Acknowledgment
This document is based on engineering done by IETF LDUP and LDAPext
@ -422,6 +445,13 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
document also borrows from a number of ITU documents including X.501.
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 8]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
7. Authors' Addresses
Kurt D. Zeilenga
@ -444,14 +474,6 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
[X.501] ITU-T, "The Directory -- Models," X.501, 1993.
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 8]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 1994.
@ -479,6 +501,13 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-xx.txt, a work in progress.
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 9]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
[GSER] S. Legg, "Generic String Encoding Rules for ASN.1 Types",
draft-legg-ldapext-gser--xx.txt, a work in progress.
@ -501,13 +530,6 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
http://www.iana.org/assignments/enterprise-numbers.
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 9]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
A. Subtree Specification ABNF
This appendix is non-normative.
@ -525,18 +547,26 @@ A. Subtree Specification ABNF
In the event that there is a discrepancy between this ABNF and the
encoding determined by [GSER], [GSER] is to be taken as definitive.
SubtreeSpecification = "{" [ sp base ]
[ sep sp specificExclusions ]
[ sep sp minimum ]
[ sep sp maximum ]
[ sep sp specificationFilter ]
SubtreeSpecification = "{" [ sp ss-base ]
[ sep sp ss-specificExclusions ]
[ sep sp ss-minimum ]
[ sep sp ss-maximum ]
[ sep sp ss-specificationFilter ]
sp "}"
base = id-base msp LocalName
specificExclusions = id-specificExclusions msp SpecificExclusions
minimum = id-minimum msp BaseDistance
maximum = id-maximum msp BaseDistance
specificationFilter = id-specificationFilter msp Refinement
ss-base = id-base msp LocalName
ss-specificExclusions = id-specificExclusions msp SpecificExclusions
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 10]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
ss-minimum = id-minimum msp BaseDistance
ss-maximum = id-maximum msp BaseDistance
ss-specificationFilter = id-specificationFilter msp Refinement
id-base = %x62.61.73.65 ; "base"
id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
@ -556,14 +586,6 @@ A. Subtree Specification ABNF
Refinement = item / and / or / not
item = id-item ":" OBJECT-IDENTIFIER
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 10]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
and = id-and ":" Refinements
or = id-or ":" Refinements
not = id-not ":" Refinement
@ -574,7 +596,7 @@ INTERNET-DRAFT Subentries in LDAP 17 May 2002
id-or = %x6F.72 ; "or"
id-not = %x6E.6F.74 ; "not"
BaseDistance = INTEGER
BaseDistance = INTEGER-0-MAX
The <sp>, <msp>, <sep>, <INTEGER>, <OBJECT-IDENTIFIER> and <LocalName>
rules are defined in [GCE].
@ -590,6 +612,14 @@ Copyright 2002, The Internet Society. All Rights Reserved.
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
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 11]
INTERNET-DRAFT Subentries in LDAP 18 August 2002
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
@ -615,5 +645,31 @@ Copyright 2002, The Internet Society. All Rights Reserved.
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 11]
Zeilenga draft-zeilenga-ldap-subentry-07 [Page 12]

106
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 17 May 2002
Expires in six months 3 May 2003
LDAP True/False Filters
<draft-zeilenga-ldap-t-f-02.txt>
LDAP Absolute True and False Filters
<draft-zeilenga-ldap-t-f-05.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 Extensions 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
@ -39,7 +39,7 @@ 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 2003, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
@ -55,9 +55,9 @@ Abstract
Zeilenga LDAP True/False Filters [Page 1]
Zeilenga LDAP True & False Filters [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
1. Background and Intended Use
@ -66,19 +66,19 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
True and False assertions. An 'and' filter with zero elements always
evaluates to True. An 'or' filter with zero elements always evaluates
to False. These filters are commonly used when requesting DSA-
specific Entries (DSEs) which do not necessarily have objectClass
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, LDAPv3 [RFC2251] required 'and' and 'or' filter sets to have
at least one element. Hence, LDAPv3 does not provide absolute True or
False filters.
to this, absolute True or False filters were (unfortunately)
eliminated from LDAPv3 [RFC3377].
This documents extends LDAPv3 [RFC2251] to support absolute True and
False matches by allowing empty 'and' and 'or' and extends the filter
string representation [RFC2254] to allow empty filter lists.
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
@ -90,11 +90,11 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
Implementations of this extension SHALL allow 'and' and 'or' choices
with zero filter elements.
An 'and' Filter consisting of an empty set of filters SHALL evaluate
to True. This filter is to represented by the string "(&)".
An 'and' filter consisting of an empty set of filters SHALL evaluate
to True. This filter is represented by the string "(&)".
An 'or' Filter consisting of an empty set of filters SHALL evaluate to
False. This filter is to represented by the string "(|)".
An 'or' filter consisting of an empty set of filters SHALL evaluate to
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]
@ -106,28 +106,38 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
3. Security Considerations
The (re)introduction of absolute True and False filters does not raise
any new 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]
Zeilenga LDAP True & False Filters [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
Implementors of this (or any) LDAP extension should be familiar with
general LDAP general security considerations [LDAPTS].
Implementors of this (or any) LDAPv3 extension should be familiar with
general LDAPv3 security considerations [RFC3377].
4. IANA Considerations
No IANA assignments are requested.
The OID 1.3.6.1.4.1.4203.1.5.3 identifies the feature described above.
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.5.3 to identify the
feature described above. This OID was assigned [ASSIGN] by OpenLDAP
Foundation under its IANA assigned private enterprise allocation
[PRIVATE] for use in this specification.
Registration of this feature is requested [FEATURES][RFC3383].
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.5.3
Description: T/F Filters
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
Specification: RFCxxxx
Author/Change Controller: IESG
Comments: none
5. Author's Address
@ -148,14 +158,20 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
[RFC2254] T. Howes, "A String Representation of LDAP Search Filters",
RFC 2254, December 1997.
[LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-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).
Zeilenga LDAP True & False Filters [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
7. Informative References
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
@ -164,13 +180,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
[RFC1960] T. Howes, "A String Representation of LDAP Search Filters",
RFC 1960, June 1996.
Zeilenga LDAP True/False Filters [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
[RFC3383] K. Zeilenga, "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.
@ -185,8 +196,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
http://www.iana.org/assignments/enterprise-numbers.
Copyright 2002, The Internet Society. All Rights Reserved.
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
@ -213,15 +223,5 @@ Copyright 2002, The Internet Society. All Rights Reserved.
Zeilenga LDAP True/False Filters [Page 4]
Zeilenga LDAP True & False Filters [Page 4]

395
doc/drafts/draft-zeilenga-ldap-txn-xx.txt Normal file
View file

@ -0,0 +1,395 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Experimental OpenLDAP Foundation
Expires in six months 3 May 2003
LDAP Transactions
<draft-zeilenga-ldap-txn-06.txt>
Status of Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Experimental 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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
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.
Abstract
Lightweight Directory Access Protocol (LDAP) update operations acting
upon entries have atomic, consistency, isolation, durability (ACID)
properties. However, it is often desirable to update two or more
entries as one unit of interaction, a transaction. Transactions are
necessary to support a number of applications including resource
provisioning and information replication. This document defines an
Zeilenga LDAP Transactions [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
LDAP extension to support transactions.
Conventions
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. Overview
This document extends the Lightweight Directory Access Protocol (LDAP)
[RFC3377] to allow clients to group a number of related update
operations [RFC2251] and have them preformed as one unit of
interaction, a transaction. As with distinct update operations, each
transaction has atomic, consistency, isolation, and durability
([ACID]) properties.
This extension uses the grouping mechanism provided by [GROUP] to
relate operations of the transaction. The createGrouping operation is
used to obtain a group cookie which is used to identify operations
which are apart of the transaction. The group cookie can be viewed as
a transaction identifier. The endGrouping operation is used to settle
(commit or abort) the transaction.
2. Specification of a Transaction
Servers implementing this specification SHOULD publish the
transactionGroupingType as a value of the 'supportedGroupingTypes'
attribute contained within the Root DSE.
transactionGroupingType ::= IANA-ASSIGNED-OID
A client wishing to preform a transaction issues a
createGroupingRequest with a createGroupType of
transactionGroupingType and no createGroupValue. A server which is
willing and able to support transactions returns a
createGroupingResponse with a success result code, a
createGroupCookie, and no createGroupValue. Otherwise the server
returns a non-success result code, no createGroupCookie, and no
createGroupValue.
Zeilenga LDAP Transactions [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
The client then issues may issue one or more update (add, delete,
modify, rename) requests, each with a GroupingControl indicating they
are to processed as part of the transaction grouping. If the server
is willing and able to attempt to process operation as part of the
transaction, the server returns success. As further processing of the
operation is be deferred until settlement, the operation is considered
still outstanding and its messageID cannot to be reused until after
settlement. If the server is unwilling or unable to attempt to
process the operation as part of the transaction, the server returns a
non-successful result code.
If the server becomes unwilling or unable to continue the
specification of a transaction, the server return the canceled
resultCode for each deferred operation and then issue a endGroupNotice
with a non-success resultCode. Any future use of cookie by the client
will result in a response containing a non-success result code. Upon
receipt of a endGroupingNotice, the client is to discontinue all use
of the grouping cookie as the transaction is null and void.
A client requests settling of transaction by issuing an
endGroupingRequest where the groupingCookie is the group cookie
identify the transaction. The absence of any endGroupingValue
indicates a commit request. The presence of an empty endGroupValue
indicates an abort request. The endGroupValue MUST be empty if
provided.
If the commit response indicates failure, the server may return an
endGroupingValue with the endGroupingResponse. If so, it contains the
BER-encoding of a MessageID [RFC2251] of the update operation
associated with the failure.
3. Settling of the Transaction
Upon receipt of a request to abort the transaction, the server is to
abort the transaction and then return an endGroupingResponse
indicating success.
Upon receipt of a request to commit the transaction, the server
processes the group of update operations as one atomic, isolated
action with each update request being processed in turn. Either all
of the requested updates SHALL be successfully applied or none of the
requested SHALL be applied. If all are applied, the server returns an
endGroupingResponse indicating success. Otherwise, the server returns
an endGroupingResponse indicating the nature of the failure. If the
failure is associated with a particular update operation, the message
ID is returned an attached endGroupingValue. If the failure was not
associated with any particular update operation, no endGroupingValue
Zeilenga LDAP Transactions [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
is to be provided.
There is no requirement that a server serialize transactions. That
is, a server MAY process multiple transactions commit requests (from
one or more clients) acting upon different sets of entries
concurrently. A server MUST avoid deadlock.
4. Distributed Directory Considerations
The LDAP/X.500 models provide for distributed directory operations
including server-side chaining and client-side chasing of operations.
This document does not disallow servers from chaining operations which
are part of a transaction. However, if a server does allow such
chaining, it MUST ensure that transaction semantics detailed above are
provided.
This mechanism defined by this document does not support client-side
chasing. Grouping cookies used to identify the transaction are
specific to a particular client/server session.
The LDAP/X.500 models provide for a single-master/multiple-slave
replication architecture. This document states no requirement that
changes made to the directory based upon processing a transaction be
replicated as one atomic action. That is, the client SHOULD NOT
assume tight data consistency nor fast data convergence at slave
servers unless they have prior knowledge that such is provided.
Though this mechanism could be used to support replication, such use
is not described in this document.
The LDAP/X.500 models do not currently support a multi-master
replication architecture and, hence, not considered by this
specification.
5. Security Considerations
Transactions mechanisms and related grouping operations may be the
target of denial of service attacks. Implementors should provide
safeguards to ensure these mechanisms are not abused.
6. IANA Considerations
In accordance with [RFC3383], it is requested that Internet Assigned
Numbers Authority (IANA) make the following assignments.
Zeilenga LDAP Transactions [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
6.1. Object Identifier
An LDAP Object Identifier to identify the grouping type defined in
this document is requested.
The following registration template is suggested:
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFCXXXX
Author/Change Controller: IESG
Comments:
Identifies the LDAP Transactions Grouping Type
6.2. LDAP Protocol Mechanism
Registration of the protocol mechanisms defined in this document is
requested.
Subject: Request for LDAP Protocol Mechansism Registration
Object Identifier: IANA-ASSIGNED-OID
Description: LDAP Transaction Grouping Type
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Grouping
Specification: RFCxxxx
Author/Change Controller: IESG
Comments: none
7. Acknowledgments
The author gratefully acknowledges the contributions made by members
of the Internet Engineering Task Force.
8. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
9. Normative References
Zeilenga LDAP Transactions [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
[RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377, September 2002.
[GROUP] K. Zeilenga, "LDAP: Grouping of Related Operations",
draft-zeilenga-ldap-grouping-xx.txt, a work in progress.
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification
of Basic Notation", X.680, 1994.
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", X.690, 1994.
10. Informative References
[ACID] Section 4 of ISO/IEC 10026-1:1992.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[X.500] ITU-T, "The Directory: Overview of Concepts, Models, and
Services", X.500, 1993.
[X.501] ITU-T, "The Directory: Models", X.501, 1993.
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 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 Internet organizations, except as needed for the purpose
of 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
Zeilenga LDAP Transactions [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
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 Transactions [Page 7]

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

@ -0,0 +1,395 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 11 May 2003
The LDAP entryUUID operational attribute
<draft-zeilenga-ldap-uuid-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
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
This document describes the LDAP/X.500 'entryUUID' operational
attribute and associated matching rules and syntax. The attribute
holds a server-assigned Universally Unique Identifier (UUID) for the
object. Directory clients may use this attribute to distinguish
objects identified by a distinguished name or to locate an object
after renaming.
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 1]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
1. Background and Intended Use
In X.500 Directory Services [X.501], such as those accessible using
the the Lightweight Directory Access Protocol (LDAP) [RFC3377], an
object is identified by its distinguished name (DN). However, DNs are
not stable identifiers. That is, a new object may be identified by a
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 defines the UUID syntax, the 'uuidMatch' and
'uuidOrderingMatch' matching rules, the 'entryUUID' attribute type.
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].
Schema definitions are provided using LDAP description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
2. UUID Schema Elements
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.
UUID ::= OCTET STRING{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.
( IANA-ASSIGNED-OID.1 DESC 'UUID' )
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
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 2]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
[X.520][RFC2252].
( IANA-ASSIGNED-OID.2 NAME 'uuidMatch'
SYNTAX IANA-ASSIGNED-OID.1 )
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].
( IANA-ASSIGNED-OID.3 NAME 'uuidMatch'
SYNTAX IANA-ASSIGNED-OID.1 )
2.4. 'entryUUID' attribute
The 'entryUUID' operational attribute provides the Universally Unique
Identifier (UUID) [ISO11578] assigned to the entry.
( IANA-ASSIGNED-OID.4 NAME 'entryUUID'
DESC 'UUID of the entry'
EQUALITY uuidMatch
ORDERING uuidOrderingMatch
SYNTAX IANA-ASSIGNED-OID.1
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )
Servers SHALL assign a UUID to each entry upon its addition to the
directory and provide the entry's UUID as the value of the
'entryUUID' operational attribute. An entry's UUID is immutable.
3. Security Considerations
Servers should ensure that components of UUID values are publicly
disclosable.
General LDAP security considerations [RFC3377] apply.
4. IANA Considerations
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
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the UUID schema elements
4.2. Registration of the uuidMatch descriptor
It is requested that IANA register upon Standards Action the LDAP
'uuidMatch' descriptor.
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): uuidMatch
Object Identifier: IANA-ASSIGNED-OID.2
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Matching Rule
Specification: RFC XXXX
Author/Change Controller: IESG
4.3. Registration of the uuidOrderingMatch descriptor
It is requested that IANA register upon Standards Action the LDAP
'uuidOrderingMatch' descriptor.
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): uuidOrderingMatch
Object Identifier: IANA-ASSIGNED-OID.3
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Matching Rule
Specification: RFC XXXX
Author/Change Controller: IESG
4.4. Registration of the entryUUID descriptor
It is requested that IANA register upon Standards Action the LDAP
'entryUUID' descriptor.
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>
Usage: Attribute Type
Specification: RFC XXXX
Author/Change Controller: IESG
5. Acknowledgments
This document is based upon discussions in the LDAP Update and
Duplication Protocols (LDUP) WG.
6. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[ISO11578] International Organization for Standardization,
"Information technology - Open Systems Interconnection -
Remote Procedure Call", ISO/IEC 11578:1996.
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.520] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Selected Attribute Types", X.520(1993) (also
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).
8. Informative References
[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.
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
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
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
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.
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 7]

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

File diff suppressed because it is too large Load diff

1403
doc/drafts/draft-zeilenga-ldup-sync-xx.txt Normal file
View file

File diff suppressed because it is too large Load diff