upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-12-25 00:59:45 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Latest revisions

Browse source
This commit is contained in:
Kurt Zeilenga 2005-06-25 23:06:51 +00:00
parent 297c7933b1
commit 7f8a49cbf7
10 changed files with 6176 additions and 4083 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

File diff suppressed because it is too large Load diff

1177
doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt Normal file
View file

File diff suppressed because it is too large Load diff

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

@ -1,20 +1,22 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 24 October 2004
Obsoletes: 2253
Expires in six months 10 February 2005
Obsoletes: RFC 2253
LDAP: String Representation of Distinguished Names
<draft-ietf-ldapbis-dn-15.txt>
<draft-ietf-ldapbis-dn-16.txt>
Status of Memo
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.
@ -23,50 +25,42 @@ Status of Memo
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the document editor <Kurt@OpenLDAP.org>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
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>.
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP: Distinguished Names [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
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
@ -75,23 +69,19 @@ Abstract
names, while being able to represent any distinguished name.
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 directory
entries [X.501][Models].
The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
directory protocols), DNs are encoded using the Basic Encoding Rules
(BER) [X.690]. In LDAP, DNs are represented in the string form
described in this document.
It is important to have a common format to be able to unambiguously
represent a distinguished name. The primary goal of this
specification is ease of encoding and decoding. A secondary goal is
@ -101,84 +91,68 @@ Abstract
translations (such as expressing attribute type names in the local
national language).
This document defines the string representation of Distinguished Names
used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
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]. This document obsoletes RFC 2253. Changes since RFC 2253
This document is a integral part of the LDAP technical specification
[Roadmap] which obsoletes the previously defined LDAP technical
Zeilenga LDAP: Distinguished Names [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
are summarized in Appendix B.
specification, RFC 3377, in its entirety. 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].
1.1. 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>.
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].
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
[RFC3629] encoded Unicode [Unicode] character string representation.
@ -188,63 +162,51 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
implementations.
2.1. Converting the RDNSequence
Zeilenga LDAP: Distinguished Names [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
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
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 sign ('=' 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][BCP64bis] as identifying the
AttributeType, that short name, a <descr>, is used. Otherwise the
AttributeType is encoded as the dotted-decimal encoding, a
<numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid>
is defined in [Models].
If the AttributeType is defined to have a short name (descriptor)
[Models] and that short name is known to be registered
[REGISTRY][BCP64bis] as identifying the AttributeType, that short
name, a <descr>, is used. Otherwise the AttributeType is encoded as
the dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
The <descr> and <numericoid> is defined in [Models].
Implementations are not expected to dynamically update their knowledge
of registered short names. However, implementations SHOULD provide a
@ -252,20 +214,17 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
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
Zeilenga LDAP: Distinguished Names [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
the X.500 AttributeValue. This form is also used when the syntax of
@ -275,7 +234,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
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
LDAP-specific string encoding, the value is converted first to a UTF-8
encoded Unicode string according to its syntax specification (see
@ -284,62 +242,49 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
escaping, then that string can be used as the string representation of
the value.
- a space (' ' U+0020) or number sign ('#' U+0023) occurring at
the beginning of the string;
- 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).
it can be prefixed by a backslash ('\' U+005C).
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 [RFC3629] encoded Unicode [Unicode] characters. The structure
of this string representation is specified using the following
Zeilenga LDAP: Distinguished Names [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
Augmented BNF [RFC2234] grammar:
distinguishedName = [ relativeDistinguishedName
*( COMMA relativeDistinguishedName ) ]
relativeDistinguishedName = attributeTypeAndValue
@ -348,47 +293,39 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
attributeType = descr / numericoid
attributeValue = string / hexstring
; The following characters are to be escaped when they appear
; in the value to be encoded: ESC, one of <escaped>, leading
; SHARP or SPACE, trailing SPACE, and NULL.
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:
@ -397,33 +334,27 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
Zeilenga LDAP: Distinguished Names [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
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
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)
@ -436,7 +367,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
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,
@ -444,59 +374,46 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
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
Zeilenga LDAP: Distinguished Names [Page 7]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
This example shows the method of escaping of a special characters
appearing in a common name:
CN=James \"Jim\" Smith\, III,DC=example,DC=net
The following shows the method for encoding a value which contains a
carriage return character:
CN=Before\0dAfter,DC=example,DC=net
In this RDN example, the type in the RDN is unrecognized, and 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
Finally, this example shows an RDN whose commonName value consisting
of 5 letters:
Unicode Character Code UTF-8 Escaped
------------------------------- ------ ------ --------
LATIN CAPITAL LETTER L U+004C 0x4C L
@ -505,28 +422,22 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
LATIN SMALL LETTER I U+0069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
could be encoded in printable ASCII (useful for debugging purposes)
as:
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
@ -535,10 +446,9 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
Zeilenga LDAP: Distinguished Names [Page 8]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
- the common name of the object (i.e. a person's full name)
@ -546,22 +456,27 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
- 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.
In some cases, such information can be considered sensitive. In many
countries, privacy laws exist which prohibit disclosure of certain
kinds of descriptive information (e.g., email addresses). Hence,
servers implementors are encouraged to support DIT structural rules
and name forms [Models] as these provide a mechanism for
administrators to select appropriate naming attributes for entries.
Administrators are encouraged to use these mechanisms, access
controls, and other administrative controls which may be available to
restrict use of attributes containing sensitive information in naming
of entries. Additionally, use of authentication and data security
services in LDAP [AuthMeth][Protocol] should be considered.
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
@ -569,7 +484,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
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,
@ -577,69 +491,57 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
U+0023) as described in the first paragraph of Section 2.4.
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. References
Zeilenga LDAP: Distinguished Names [Page 9]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
7. Document Editor's Address
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
8. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn.]]
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
8.1. Normative References
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629 (also STD 63), November 2003.
[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),
@ -648,56 +550,45 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
Zeilenga LDAP: Distinguished Names [Page 10]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[REGISTRY] IANA, Object Identifier Descriptors Registry,
<http://www.iana.org/...>.
8.2. Informative References
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[X.500] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Overview of concepts, models and services,"
X.500(1993) (also ISO/IEC 9594-1:1994).
[X.690] International Telecommunication Union -
Telecommunication Standardization Sector, "Specification
of ASN.1 encoding rules: Basic Encoding Rules (BER),
@ -705,61 +596,49 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
Encoding Rules (DER)", X.690(1997) (also ISO/IEC
8825-1:1998).
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
#17, Character Encoding Model", UTR17,
<http://www.unicode.org/unicode/reports/tr17/>, August
2000.
[Glossary] The Unicode Consortium, "Unicode Glossary",
<http://www.unicode.org/glossary/>.
Appendix A. Presentation Issues
Zeilenga LDAP: Distinguished Names [Page 11]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
Appendix A. Presentation Issues
This appendix is provided for informational purposes only, it is not a
normative part of this specification.
The string representation described in this document is not intended
to be presented to humans without translation. However, at times it
may be desirable to present non-translated DN strings to users. This
section discusses presentation issues associated with non-translated
DN strings. Presentation of translated DN strings issues are not
Zeilenga LDAP: Distinguished Names [Page 11]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
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
Unicode characters. Some Unicode 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
@ -767,7 +646,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
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
@ -781,7 +659,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
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
@ -789,32 +666,27 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
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:
Zeilenga LDAP: Distinguished Names [Page 12]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
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.
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)
Zeilenga LDAP: Distinguished Names [Page 12]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
[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
@ -823,14 +695,11 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
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.
- Replaced all references to ISO 10646-1 with [Unicode].
@ -854,6 +723,14 @@ Appendix B. Changes made since RFC 2253
- Updated Section 2.4 to allow hex pair escaping of all characters
and clarified escaping for when multiple octet UTF-8 encodings are
present. Indicated that null (U+0000) character is to be escaped.
Zeilenga LDAP: Distinguished Names [Page 13]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
Indicated that equals sign ('=' U+003D) character may be escaped
as '\='.
- Rewrote Section 3 to use ABNF as defined in RFC 2234.
@ -864,15 +741,6 @@ Appendix B. Changes made since RFC 2253
+ do not require escaping of non-leading number sign ('#' U+0023)
characters,
+ allow space (' ' U+0020) to escaped as '\ ',
Zeilenga LDAP: Distinguished Names [Page 13]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
+ require hex escaping of null (U+0000) characters, and
+ removed LDAPv2-only constructs.
- Updated Section 3 to describe how to parse elements of the
@ -883,14 +751,11 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
- Added discussion of presentation issues (Appendix A).
- Added this appendix.
In addition, numerous editorial changes were made.
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
@ -900,7 +765,6 @@ Intellectual Property Rights
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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
@ -908,7 +772,6 @@ Intellectual Property Rights
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
@ -918,26 +781,21 @@ Intellectual Property Rights
Zeilenga LDAP: Distinguished Names [Page 14]
INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
Full Copyright
Copyright (C) The Internet Society (2004). This document is subject
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
Zeilenga LDAP: Distinguished Names [Page 14]
INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
ENGINEERING TASK FORCE DISCLAIM 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
@ -980,13 +838,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
Zeilenga LDAP: Distinguished Names [Page 15]
Zeilenga LDAP: Distinguished Names [Page 15]

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

@ -1,14 +1,12 @@
Network Working Group M. Smith, Editor
Request for Comments: DRAFT Pearl Crescent, LLC
Obsoletes: RFC 2254 T. Howes
Expires: 24 April 2005 Opsware, Inc.
24 October 2004
Expires: 16 May 2005 Opsware, Inc.
16 November 2004
LDAP: String Representation of Search Filters
<draft-ietf-ldapbis-filter-08.txt>
<draft-ietf-ldapbis-filter-09.txt>
@ -52,8 +50,8 @@ Status of this Memo
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
Abstract
@ -61,8 +59,8 @@ 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.
search filters that is appropriate for use in LDAP URLs [LDAPURL] and
in other applications.
Table of Contents
@ -78,18 +76,19 @@ Table of Contents
7. Normative References...........................................7
8. Informative References.........................................8
9. Acknowledgments................................................8
10. Authors' Addresses.............................................8
10. Authors' Addresses.............................................9
11. Appendix A: Changes Since RFC 2254.............................9
11.1. Technical Changes...........................................9
11.2. Editorial Changes...........................................10
12. Appendix B: Changes Since Previous Document Revision...........11
12.1. Editorial Changes...........................................11
13. Intellectual Property Rights...................................11
14. Full Copyright.................................................12
12.1. Technical Changes...........................................11
12.2. Editorial Changes...........................................12
Intellectual Property Rights...................................12
Full Copyright.................................................13
1. Introduction
The Lightweight Directory Access Protocol (LDAP) [Protocol] defines a
The Lightweight Directory Access Protocol (LDAP) [Roadmap] 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
@ -98,19 +97,21 @@ Table of Contents
possible LDAP version 3 search filters, including extended match
filters.
This document is an integral part of the LDAP Technical Specification
[Roadmap].
This document is a integral part of the LDAP technical specification
[Roadmap] which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety.
This document replaces RFC 2254. Changes to RFC 2254 are summarized
in Appendix A.
Smith & Howes Intended Category: Standards Track [Page 2]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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
@ -118,7 +119,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
2. LDAP Search Filter Definition
An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as
An LDAP search filter is defined in Section 4.5.1 of [Protocol] as
follows:
Filter ::= CHOICE {
@ -157,26 +158,27 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
AttributeValue ::= OCTET STRING
MatchingRuleId ::= LDAPString
AssertionValue ::= OCTET STRING
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
MatchingRuleId ::= LDAPString
AssertionValue ::= OCTET STRING
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [Unicode] characters
The AttributeDescription is a string representation of the attribute
description and is defined in [Protocol]. The AttributeValue and
AssertionValue OCTET STRING have the form defined in [Syntaxes]. The
Filter is encoded for transmission over a network using the Basic
Encoding Rules (BER) defined in [X.690], with simplifications
described in [Protocol].
The AttributeDescription, as defined in [Protocol], is a string
representation of the attribute description that is discussed in
[Models]. The AttributeValue and AssertionValue OCTET STRING have
the form defined in [Syntaxes]. The Filter is encoded for
transmission over a network using the Basic Encoding Rules (BER)
defined in [X.690], with simplifications described in [Protocol].
3. String Search Filter Definition
@ -200,11 +202,10 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
approx = TILDE EQUALS
greaterorequal = RANGLE EQUALS
lessorequal = LANGLE EQUALS
extensible = attr [dnattrs]
[matchingrule] COLON EQUALS assertionvalue
/ [dnattrs]
matchingrule COLON EQUALS assertionvalue
/ COLON EQUALS assertionvalue
extensible = ( attr [dnattrs]
[matchingrule] COLON EQUALS assertionvalue )
/ ( [dnattrs]
matchingrule COLON EQUALS assertionvalue )
present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
@ -213,17 +214,17 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
attr = attributedescription
; The attributedescription rule is defined in
; Section 2.5 of [Models].
dnattrs = COLON "dn"
matchingrule = COLON oid
assertionvalue = valueencoding
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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)
@ -259,27 +260,26 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
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
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
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. Implementations SHOULD accept as input strings that
are not valid UTF-8 strings. This is necessary because RFC 2254 did
not clearly define the term "string representation" (and in
particular did not mention that the string representation of an LDAP
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
not clearly define the term "string representation" (and in
particular did not mention that the string representation of an LDAP
search filter is a string of UTF-8 encoded Unicode characters).
4. Examples
@ -295,47 +295,48 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
The following examples illustrate the use of extensible matching.
(cn:1.2.3.4.5:=Fred Flintstone)
(cn:caseExactMatch:=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)
(:DN:2.4.6.8.10:=Dino)
The first example shows use of the matching rule "1.2.3.4.5".
The first example shows use of the matching rule "caseExactMatch."
The second example demonstrates use of a MatchingRuleAssertion form
without a matchingRule.
The third example illustrates the use of the ":oid" 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
(indicated by the use of ":dn").
indicate that matching rule identified by the OID "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 (indicated by the use of ":dn").
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).
supporting the matching rule given (since the <attr> has been
omitted).
The sixth and final example is also a filter that should be applied
to any attribute supporting the matching rule given. Attributes
supporting the matching rule contained in the DN should also be
considered.
The following examples illustrate the use of the escaping mechanism.
(o=Parens R Us \28for all your parenthetical needs\29)
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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)
@ -348,12 +349,16 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
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
The fourth example shows a filter searching for the four octet value
00 00 00 04 (hex), 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.
represent various non-ASCII UTF-8 characters. Specifically, there are
5 characters in the <assertionvalue> portion of this example: LATIN
CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN SMALL
LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069), and
LATIN SMALL LETTER C WITH ACUTE (U+0107).
The sixth and final example demonstrates assertion of a BER encoded
value.
@ -377,6 +382,14 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
@ -384,14 +397,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
[Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
@ -414,22 +419,31 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
(http://www.unicode.org/reports/tr27/) and by the "Unicode
Standard Annex #28: Unicode 3.2."
8. Informative References
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and
Distinguished Encoding Rules, ITU-T Recommendation X.690,
1994.
8. Informative References
None.
9. 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.
This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product
of the IETF ASID Working Group.
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.
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
10. Authors' Addresses
@ -440,14 +454,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
Saline, MI 48176
USA
+1 734 944-2856
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
mcs@pearlcrescent.com
@ -477,6 +483,9 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
"simple", "extensible", and "substring" ("initial", "any", and
"final") rules. This matches a change made in [Syntaxes].
Added "(" and ")" around the components of the <extensible>
subproductions for clarity.
Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
precisely reference productions from the [Models] and [Protocol]
documents.
@ -484,24 +493,22 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
"String Search Filter Definition" section: replaced "greater" and
"less" with "greaterorequal" and "lessorequal" to avoid confusion.
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."
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
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 statement about expected behavior in light of RFC 2254's lack
of a clear definition of "string representation."
11.2. Editorial Changes
@ -526,8 +533,8 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
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].
"LDAP Search Filter Definition" section: made corrections to the LDAP
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
@ -540,7 +547,22 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
(cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
(1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
value" with "an assertion value". Corrected the description of this
example: (sn:dn:2.4.6.8.10:=Barney Rubble).
example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID
in the first extensible match example with "caseExactMatch" to
demonstrate use of the descriptive form. Used "DN" (uppercase) in
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
the last extensible match example to remind the reader to treat the
<dnattrs> production as case insensitive. Reworded the description
of the fourth escaping mechanism example to avoid making assumptions
about byte order. Added text to the fifth escaping mechanism example
to spell out what the non-ASCII characters are in Unicode terms.
"Security Considerations" section: added references to [Protocol] and
[AuthMeth].
@ -551,16 +573,8 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
[Models], and [Roadmap] and updated the UTF-8 reference. Replaced
RFC 822 reference with a reference to RFC 2234.
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
"Informative References" section: added for clarity.
"Informative References" section: (new section) moved [X.690] to this
section. Added a reference to [LDAPURL].
"Acknowledgments" section: added.
@ -569,29 +583,72 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
"Appendix B: Changes Since Previous Document Revision" section:
added.
Surrounded the names of all ABNF productions with "<" and ">" where
they are used in descriptive text.
Replaced all occurrences of "LDAPv3" with "LDAP."
12. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-filter-07.txt. Note that when
revision, draft-ietf-ldapbis-filter-08.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-07.txt. This section will be
reviewed draft-ietf-ldapbis-filter-08.txt. This section will be
removed before this document is published as an RFC.
12.1. Editorial Changes
12.1. Technical Changes
"Status of this Memo" section: replaced RFC 3668 (IPR) boilerplate
paragraph with the version that says "each author" instead of "I."
"Status of this Memo" section: added 2 paragraphs that were
accidently removed from the -07 revision (one begins with "The list
of current Internet-Drafts..." and the other begins with "The list of
Internet-Draft Shadow Directories...."
Removed the third option from the "extensible" production that
allowed creation of a MatchingRuleAssertion that only had a
matchValue (disallowed By [Protocol]). Added "(" and ")" around the
components of the <extensible> subproductions for clarity.
13. Intellectual Property Rights
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
12.2. Editorial Changes
"Introduction" section: referenced [Roadmap] upon first use of LDAP
and expanded the paragraph that begins "This document is an integral
part of the LDAP technical specification..." to match the text used
in [Protocol].
"LDAP Search Filter Definition" section: reworded the last paragraph
for clarity.
"Examples" section: Replaced the numeric OID in the first extensible
match example with "caseExactMatch" to demonstrate use of the
descriptive form. Used "DN" (uppercase) in the last extensible match
example to remind the reader to treat the <dnattrs> production as
case insensitive. Reworded the description of the fourth escaping
mechanism example to avoid making assumptions about byte order.
Added text to the fifth escaping mechanism example to spell out what
the non-ASCII characters are in Unicode terms.
References: added [LDAPURL] and moved [X.690] to "Informative
References."
"Acknowledgements" section: added the sentence "RFC 2254 was a
product of the IETF ASID Working Group."
Changed these two sections to unnumbered ones: "Intellectual Property
Rights" and "Full Copyright."
Surrounded the names of all ABNF productions with "<" and ">" where
they are used in descriptive text.
Replaced all occurrences of "LDAPv3" with "LDAP."
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
@ -605,24 +662,25 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
Copies of IPR disclosures made to the IETF Secretariat 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
Smith & Howes Intended Category: Standards Track [Page 12]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
14. Full Copyright
Full Copyright
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
@ -637,7 +695,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet Draft expires on 24 April 2005.
This Internet Draft expires on 16 May 2005.
@ -663,10 +721,4 @@ This Internet Draft expires on 24 April 2005.
Smith & Howes Intended Category: Standards Track [Page 12]
Smith & Howes Intended Category: Standards Track [Page 13]

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

File diff suppressed because it is too large Load diff

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

File diff suppressed because it is too large Load diff

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

@ -1,54 +1,52 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 24 October 2004
Expires in six months 10 February 2005
Obsoletes: RFC 2251-2256, 2829-2830, 3377, 3771
Lightweight Directory Access Protocol (LDAP):
Technical Specification Road Map
<draft-ietf-ldapbis-roadmap-06.txt>
<draft-ietf-ldapbis-roadmap-07.txt>
Status of this Memo
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>.
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
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>.
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
@ -56,41 +54,32 @@ Status of this Memo
Zeilenga LDAP: TS Road Map [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
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.
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: The Protocol [Protocol],
LDAP: Directory Information Models [Models],
LDAP: Authentication Methods and Connection Level Security
@ -102,20 +91,17 @@ Conventions
LDAP: Internationalized String Preparation [LDAPprep], 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.
LDAP is an extensible protocol. 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). Extensions are expected to be
truly optional.
IANA (Internet Assigned Numbers Authority) considerations for LDAP
described in BCP 64 [BCP64bis] apply fully to this revision of the
LDAP technical specification.
@ -124,15 +110,13 @@ Conventions
Zeilenga LDAP: TS Road Map [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
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 Telecommunication Union - Telecom
@ -142,30 +126,25 @@ INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
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.
This technical specification explicitly incorporates portions of
X.500(93). Later revisions of X.500 do not automatically apply.
X.500(93). Later revisions of X.500 do not automatically apply to
this technical specification.
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, RFC 3771, and RFC
3377 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, portions of RFC 2252, and
@ -175,187 +154,153 @@ INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
[LDAPDN] replaces RFC 2253. [Filters] replaces RFC 2254. [LDAPURL]
replaces RFC 2255.
[LDAPprep] is new to this revision of the LDAP technical
specification.
Each document of this specification contains appendices summarizing
changes to all sections of the specifications they replace. Appendix
A.1 of this document details changes made to RFC 3377. Appendix A.2
of this document details changes made to Section 3.3 of RFC 2251.
Additionally, portions of this technical specification update and/or
replace a number of other documents not listed above. These
Zeilenga LDAP: TS Road Map [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
replace a number of other documents not listed above. These
relationships are discussed in the documents detailings these portions
of this technical specification.
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 D. Zeilenga
OpenLDAP Foundation
Kurt Zeilenga
E-mail: <kurt@openldap.org>
Email: Kurt@OpenLDAP.org
7. References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn.]]
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
Zeilenga LDAP: TS Road Map [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.
Zeilenga LDAP: TS Road Map [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
[Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
Representation of Search Filters",
draft-ietf-ldapbis-filter-xx.txt, a work in progress.
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[LDAPprep] Zeilenga, K., "LDAP: Internationalized String
Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work
in progress.
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[X.500] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Overview of concepts, models and services,"
X.500(1993) (also ISO/IEC 9594-1:1994).
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.511] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Abstract Service Definition", X.511(1993)
(also ISO/IEC 9594-3:1993).
7.2. Informative References
None.
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. The changes include
Zeilenga LDAP: TS Road Map [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
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. The changes include
redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
the technical specification.
Appendix A.2. Changes to Section 3.3 of RFC 2251
The section was modified slightly (the word "document" was replaced
with "technical specification") to clarify that it applies to the
entire LDAP technical specification.
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
@ -365,7 +310,6 @@ Intellectual Property Rights
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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
@ -373,7 +317,6 @@ Intellectual Property Rights
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
@ -382,28 +325,24 @@ Intellectual Property Rights
Full Copyright
Copyright (C) The Internet Society (2004). This document is subject
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Zeilenga LDAP: TS Road Map [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
Zeilenga LDAP: TS Road Map [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
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.
@ -451,8 +390,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
Zeilenga LDAP: TS Road Map [Page 7]
Zeilenga LDAP: TS Road Map [Page 7]

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

File diff suppressed because it is too large Load diff

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

@ -1,14 +1,16 @@
Network Working Group Mark Smith, Editor
Request for Comments: DRAFT Pearl Crescent, LLC
Obsoletes: RFC 2255 Tim Howes
Expires: 24 April 2005 Opsware, Inc.
Expires: 4 July 2005 Opsware, Inc.
24 October 2004
4 January 2005
LDAP: Uniform Resource Locator
<draft-ietf-ldapbis-url-07.txt>
<draft-ietf-ldapbis-url-09.txt>
@ -52,16 +54,17 @@ Status of this Memo
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
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.
This document describes a format for a Lightweight Directory Access
Protocol (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 LDAP
referral or reference, an LDAP URL describes a service where an LDAP
operation may be progressed.
Table of Contents
@ -70,47 +73,50 @@ Table of Contents
Table of Contents..............................................2
1. Introduction...................................................2
2. URL Definition.................................................3
2.1. Escaping Using the % Method.................................5
2.1. Percent-Encoding............................................5
3. Defaults for Fields of the LDAP URL............................5
4. Examples.......................................................6
5. Security Considerations........................................8
6. IANA Considerations............................................9
7. Normative References...........................................9
8. Informative References.........................................10
9. Intellectual Property Rights...................................10
10. Acknowledgements...............................................10
11. Authors' Addresses.............................................11
12. Appendix A: Changes Since RFC 2255.............................11
12.1. Technical Changes...........................................11
12.2. Editorial Changes...........................................12
13. Appendix B: Changes Since Previous Document Revision...........13
13.1. Editorial Changes...........................................14
14. Intellectual Property Rights...................................14
15. Full Copyright.................................................14
9. Acknowledgements...............................................10
10. Authors' Addresses.............................................11
11. Appendix A: Changes Since RFC 2255.............................11
11.1. Technical Changes...........................................11
11.2. Editorial Changes...........................................12
12. Appendix B: Changes Since Previous Document Revision...........14
12.1. Technical Changes...........................................14
12.2. Editorial Changes...........................................14
Intellectual Property Rights...................................14
Full Copyright.................................................15
1. 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.
LDAP is the Lightweight Directory Access Protocol [Roadmap]. 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. This mechanism may be used to
provide access to new LDAP extensions.
Note that not all of the parameters of the LDAP search operation
described in [Protocol] can be expressed using the format defined in
this document. Note also that URLs may be used to represent reference
knowledge, including for non-search operations.
This document is an integral part of the LDAP Technical Specification
[Roadmap].
Smith & Howes Intended Category: Standards Track [Page 2]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
This document is a integral part of the LDAP technical specification
[Roadmap] which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety.
This document replaces RFC 2255. See Appendix A for a list of changes
relative to RFC 2255.
@ -124,169 +130,187 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
the following grammar, following the ABNF notation defined in
[RFC2234].
ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn
[QUESTION [attributes] [QUESTION [scope]
[QUESTION [filter] [QUESTION extensions]]]]]
ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
[SLASH dn [QUESTION [attributes]
[QUESTION [scope] [QUESTION [filter]
[QUESTION extensions]]]]]
; <host> and <port> are defined
; in Sections 3.2.2 and 3.2.3
; of [RFC2396bis].
; <filter> is from Section 3 of
; [Filters], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
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]>
; See the "Escaping Using the % Method"
; section below.
dn = distinguishedName ; From Section 3 of [LDAPDN],
; subject to the provisions of
; the "Percent-Encoding"
; section below.
attributes = attrdesc *(COMMA attrdesc)
attrdesc = <AttributeDescription
from Section 4.1.4 of [Protocol]>
/ ASTERISK
; See the "Escaping Using the % Method"
; section below.
attrdesc = selector *(COMMA selector)
selector = attributeSelector ; From Section 4.5.1 of
; [Protocol], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
scope = "base" / "one" / "sub"
filter = <filter from Section 4 of [Filters]>
; See the "Escaping Using the % Method"
; section below.
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid / oiddescr
exvalue = <LDAPString from section 4.1.2 of [Protocol]>
; See the "Escaping Using the % Method"
; section below.
oid = <LDAPOID from section 4.1.2 of [Protocol]>
oiddescr = <name from section 3.3 of [LDAPIANA]>
EXCLAMATION = %x21 ; exclamation mark ("!")
ASTERISK = %x2A ; asterisk ("*")
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
extype = oid ; From section 1.4 of [Models].
exvalue = LDAPString ; From section 4.1.2 of
; [Protocol], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
EXCLAMATION = %x21 ; exclamation mark ("!")
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
The "ldap" prefix indicates an entry or entries accessible from 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].
Note that the <host> may contain literal IPv6 addresses as specified
in Section 3.2.2 of [RFC2396bis].
The dn is an LDAP Distinguished Name using the string format
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 <attributes> construct is used to indicate which attributes
should be returned from the entry or entries.
The scope construct is used to specify the scope of the search to
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
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].
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 0x21) is critical. An extension not prefixed with a
'!' character is non-critical.
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 LDAP extension mechanisms. Extensions may be supported or
unsupported by the client resolving the URL. An extension prefixed
with a '!' character (ASCII 0x21) is critical. An extension not
prefixed with a '!' character is non-critical.
If an LDAP URL extension is implemented (that is, if the
implementation understands it and is able to use it), the
implementation MUST make use of it. If an extension is not
implemented and is marked critical, the implementation MUST NOT
process the URL. If an extension is not implemented and it not
marked critical, the implementation MUST 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
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
implementation MUST make use of it. If an extension is not
implemented and is marked critical, the implementation MUST NOT
process the URL. If an extension is not implemented and it not
marked critical, the implementation MUST ignore the extension.
The extension type (<extype>) MAY be specified using the numeric OID
<numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
(e.g., myLDAPURLExtension). Use of the <descr> 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.
2.1. Escaping Using the % Method
2.1. Percent-Encoding
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 [RFC3629] as input. An octet MUST be escaped using the %
method described in section 2.4 of [RFC2396] in any of these
situations:
characters included in one of the following three productions defined
in [RFC2396bis]:
<reserved>
<unreserved>
<pct-encoded>
Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
input. An octet MUST be encoded using the percent-encoding mechanism
described in section 2.1 of [RFC2396bis] 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].
[RFC2396bis] or in the unreserved set defined in section 2.3 of
[RFC2396bis].
It is the single Reserved character '?' and occurs inside a dn,
filter, or other element of an LDAP URL.
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.
It is a comma character ',' that occurs inside an <exvalue>.
Note that before the % method of escaping is applied, the extensions
component of the LDAP URL may contain one or more null (zero) bytes.
No other component may.
Note that before the percent-encoding mechanism is applied, the
extensions component of the LDAP URL may contain one or more null
(zero) bytes. No other component may.
3. 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.10 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 "*").
SHOULD be used when a field is absent. Note that other documents MAY
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
scope
If scope is omitted, a scope of "base" is assumed.
specify different defaulting rules; for example, section 4.1.10 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.
filter
If filter is omitted, a filter of "(objectClass=*)" is assumed.
<host>
If no <host> is given, the client must have some apriori knowledge
of an appropriate LDAP server to contact.
extensions
If extensions is omitted, no extensions are assumed.
<port>
The default LDAP port is TCP port 389.
<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 by using the special <alluserattrs>
selector "*").
<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.
4. Examples
@ -305,6 +329,14 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
Both of these URLs correspond to a base object search of the
"o=University of Michigan,c=US" entry using a filter of
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
"(objectclass=*)", requesting all attributes.
The next example is an LDAP URL referring to only the postalAddress
@ -328,21 +360,15 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
The next example is an LDAP URL referring to all children of the c=GB
entry:
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
ldap://ldap1.example.com/c=GB?objectClass?one
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 '?'.
the use of the percent-encoding mechanism on the reserved character
'?'.
ldap://ldap2.example.com/o=Question%3f,c=US?mail
@ -356,17 +382,25 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
The filter in this example uses the LDAP escaping mechanism of \ to
encode three zero or null bytes in the value. In LDAP, the filter
would be written as (four-octet=\00\00\00\04). Because the \
character must be escaped in a URL, the \'s are escaped as %5c in the
URL encoding.
character must be escaped in a URL, the \'s are percent-encoded as
%5c (or %5C) in the URL encoding.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
The next example illustrates the interaction between the LDAP string
representation of DNs quoting mechanism and URL quoting mechanisms.
ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US
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
o=An Example\2C Inc.,c=US
That is, the left-most RDN value is:
@ -382,15 +416,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
These three URLs all point to the root DSE on the ldap.example.net
server.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
The final two examples show use of a hypothetical, experimental bind
name extension (the value associated with the extension is an LDAP DN).
@ -398,37 +423,45 @@ name extension (the value associated with the extension is an LDAP DN).
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.
e-bindname extension as critical. Notice the use of the
percent-encoding mechanism to encode the commas within the
distinguished name value in the e-bindname extension.
5. Security Considerations
General URL security considerations discussed in [RFC2396] are
General URL security considerations discussed in [RFC2396bis] 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
policies are violated.
policy that controls which servers the client will establish LDAP
sessions with using which security mechanisms, and SHOULD NOT
establish LDAP sessions that are inconsistent with this policy. If a
client chooses to reuse an existing LDAP session when resolving one
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
or more LDAP URLs, it MUST ensure that the session is compatible with
the URL and that no security 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
a client should use an anonymous LDAP session. (Note that clients
conforming to previous LDAP URL specifications, where all LDAP
sessions 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.
opening a transport 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
@ -439,14 +472,6 @@ name extension (the value associated with the extension is an LDAP DN).
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
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
Considerations section of [AuthMeth] for more information.
The LDAP URL format allows the specification of an arbitrary LDAP
@ -472,10 +497,15 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
[Filters] Smith, M. and Howes, T., "LDAP: String Representation of
Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
progress.
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
progress.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels," RFC 2119, BCP 14, March 1997.
@ -486,53 +516,23 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999.
[RFC2396bis]
Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax",
draft-fielding-uri-rfc2396bis-xx.txt, a work in progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
8. Informative References
None.
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. None.
9. 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.
10. Acknowledgements
9. Acknowledgements
The LDAP URL format was originally defined at the University of
Michigan. This material is based upon work supported by the National
@ -554,12 +554,14 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
11. Authors' Addresses
10. Authors' Addresses
Mark Smith, Editor
Pearl Crescent, LLC
@ -577,48 +579,57 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
+1 408 744-7509
howes@opsware.com
12. Appendix A: Changes Since RFC 2255
11. Appendix A: Changes Since RFC 2255
12.1. Technical Changes
11.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].
Added note and references to [RFC2732] to allow literal IPv6
addresses inside the hostport portion of the URL.
Replaced references to [RFC2396] with a reference to [RFC2396bis]
(this allows literal IPv6 addresses to be used inside the <host>
portion of the URL, and a note was added to remind the reader of this
enhancement). Referencing [RFC2396bis] required changes to the ABNF
and text so that productions that are no longer defined by
[RFC2396bis] are not used. For example, <hostport> is not defined by
[RFC2396bis] so it has been replaced with host [COLON port]. Note:
[RFC2396bis] includes new definitions for the "Reserved" and
"Unreserved" sets of characters, and the net result is that the
following two additional characters should be percent-encoded when
they appear anywhere in the data used to construct an LDAP URL: "["
and "]" (these two characters were first added to the Reserved set by
RFC 2732).
Added missing ASTERISK as an alternative for the attrdesc part of the
URL. It is believed that existing implementations of RFC 2255
Changed the definition of <attrdesc> to refer to <attributeSelector>
from [Protocol]. This allows use of "*" in 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.
Avoided use of <prose-val> (bracketed-string) productions in the
<dn>, <host>, <attrdesc>, and <exvalue> rules.
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
Changed the ABNF for <ldapurl> to group the <dn> component with the
preceding <SLASH>.
Changed the <extype> rule to be an <oid> from [Models].
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.
12.2. Editorial Changes
11.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
@ -641,50 +652,56 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
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
break within '!' sequence. Replaced "residing in the LDAP server"
with "accessible from the LDAP server" in the sentence immediately
following the ABNF. 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. Clarified and strengthened the
requirements with respect to processing of URLs that contain
implements and not implemented extensions (the approach now closely
matches that specified in [Protocol] for LDAP controls).
"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.
"URL Definition" section: removed second copy of <ldapurl> grammar
and following two paragraphs (editorial error in RFC 2255). Fixed
line break within '!' sequence. Reformatted the ABNF to improve
readability by aligning comments and adding some blank lines.
Replaced "residing in the LDAP server" with "accessible from the LDAP
server" in the sentence immediately following the ABNF. Removed the
sentence "Individual attrdesc names are as defined for
AttributeDescription in [Protocol]." because [Protocol]'s
<attributeSelector> is now used directly in the ABNF. Reworded last
paragraph to clarify which characters must be percent-encoded. Added
text to indicate that LDAP URLs are used for references and
referrals. Added text that refers to the ABNF from RFC 2234.
Clarified and strengthened the requirements with respect to
Smith & Howes Intended Category: Standards Track [Page 12]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
processing of URLs that contain implements and not implemented
extensions (the approach now closely matches that specified in
[Protocol] for LDAP controls).
"Defaults for Fields of the LDAP URL" section: added; formed by
moving text about defaults out of the "URL Definition" section.
Replaced direct reference to the attribute name "*" with a reference
to the special <alluserattrs> selector "*" defined in [Protocol].
"URL Processing" section: removed.
"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.
Changed the name of an attribute used in one example from "int" to
"four-octet" to avoid potential confusion. Added an example that
demonstrates the interaction between DN escaping and URL escaping.
Added some examples to show URL equivalence with respect to the dn
portion of the URL.
demonstrates the interaction between DN escaping and URL
percent-encoding. Added some examples to show URL equivalence with
respect to the <dn> portion of the URL. Used uppercase in some
examples to remind the reader that some tokens are case-insensitive.
"Security Considerations" section: Added a note about connection
reuse. Added a note about using strong authentication methods for
updates. Added a reference to [AuthMeth]. Added note that simply
opening a connection may violate some users' privacy requirements.
Adopted the working group's revised LDAP terminology specification by
replacing the word "connection" with "LDAP session" or "LDAP
connection" as appropriate.
"Acknowledgements" section: added statement about this being an
update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
@ -692,60 +709,82 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
"Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the
document. Added references to RFC 2234, RFC 2732, and RFC 3629.
Updated all RFC 1738 references to point to the appropriate sections
within RFC 2396. Updated the LDAP references to refer to LDAPBis WG
document. Added references to RFC 2234 and RFC 3629. Updated all
RFC 1738 references to point to the appropriate sections within
[RFC2396bis]. Updated the LDAP references to refer to LDAPBis WG
documents. Removed the reference to the LDAP Attribute Syntaxes
document and added references to the [AuthMeth], [LDAPIANA], and
[Roadmap] documents.
"Informative References" section: added for clarity.
"Informative References" section: added.
Header and "Authors' Addresses" sections: added "editor" next to Mark
Smith's name. Updated affiliation and contact information.
Copyright: updated the year.
13. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-url-06.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-06.txt. This section will be removed before
this document is published as an RFC.
Smith & Howes Intended Category: Standards Track [Page 13]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
13.1. Editorial Changes
Copyright: updated the year.
"Status of this Memo" section: replaced RFC 3668 (IPR) boilerplate
paragraph with the version that says "each author" instead of "I."
Throughout the document: surrounded the names of all ABNF productions
with "<" and ">" where they are used in descriptive text.
"URL Definition" section: replaced phrases such as "recognized by"
with "implemented by" when referring to LDAP URL extensions.
"URL Definition" section: added the following two sentences at the
end of the subsection on "Escaping Using the % Method":
Note that before the % method of escaping is applied, the
extensions component of the LDAP URL may contain one or more null
(zero) bytes. No other component may.
14. Intellectual Property Rights
12. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-url-08.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-08.txt. This section will be removed before
this document is published as an RFC.
12.1. Technical Changes
Throughout the document: Replaced references to [RFC2396] and
[RFC2732] with references to [RFC2396bis]. This required changes to
the ABNF and text so that productions that are no longer defined by
[RFC2396bis] are not used. For example, <hostport> is not defined by
[RFC2396bis] so it has been replaced with host [COLON port]. Note:
[RFC2396bis] includes new definitions for the "Reserved" and
"Unreserved" sets of characters, and the net result is that the
following two additional characters should be percent-encoded when
they appear anywhere in the data used to construct an LDAP URL: "["
and "]" (these two characters were first added to the Reserved set by
RFC 2732).
12.2. Editorial Changes
Throughout the document: Replaced phrases like "Escaping using the %
method" with "Percent-encoding" to be consistent with the terminology
used in [RFC2396bis].
"URL Definition" section: For consistency, replaced all occurrences
of the phrase 'see the "Percent-Encoding" section below' with
'subject to the provisions of the "Percent-Encoding" section below.'
Updated the copyright year to 2005.
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
Smith & Howes Intended Category: Standards Track [Page 14]
INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
@ -765,9 +804,9 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
15. Full Copyright
Full Copyright
Copyright (C) The Internet Society (2004). This document is subject
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
@ -775,48 +814,11 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
Smith & Howes Intended Category: Standards Track [Page 14]
INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
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.
This Internet Draft expires on 24 April 2005.
This Internet Draft expires on 4 July 2005.

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

File diff suppressed because it is too large Load diff