draft-ietf-ldapbis-url-09.txt   rfc4516.txt 
Network Working Group Mark Smith, Editor Network Working Group M. Smith, Ed.
Request for Comments: DRAFT Pearl Crescent, LLC Request for Comments: 4516 Pearl Crescent, LLC
Obsoletes: RFC 2255 Tim Howes Obsoletes: 2255 T. Howes
Expires: 4 July 2005 Opsware, Inc. Category: Standards Track Opsware, Inc.
June 2006
4 January 2005
LDAP: Uniform Resource Locator
<draft-ietf-ldapbis-url-09.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she become
aware will be disclosed, in accordance with RFC 3668.
This document is intended to be published as a Standards Track RFC,
replacing RFC 2255. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF
LDAP (v3) Revision (ldapbis) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the editor <mcs@pearlcrescent.com>.
Internet-Drafts are working documents of the Internet Engineering Lightweight Directory Access Protocol (LDAP):
Task Force (IETF), its areas, and its working groups. Note that Uniform Resource Locator
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 a "work in progress."
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/1id-abstracts.html Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2006).
Please see the Full Copyright section near the end of this document
for more information.
Abstract Abstract
This document describes a format for a Lightweight Directory Access This document describes a format for a Lightweight Directory Access
Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL
describes an LDAP search operation that is used to retrieve describes an LDAP search operation that is used to retrieve
information from an LDAP directory, or, in the context of an LDAP information from an LDAP directory, or, in the context of an LDAP
referral or reference, an LDAP URL describes a service where an LDAP referral or reference, an LDAP URL describes a service where an LDAP
operation may be progressed. operation may be progressed.
Table of Contents Table of Contents
Status of this Memo............................................1 1. Introduction ....................................................2
Abstract.......................................................2 2. URL Definition ..................................................2
Table of Contents..............................................2 2.1. Percent-Encoding ...........................................4
1. Introduction...................................................2 3. Defaults for Fields of the LDAP URL .............................5
2. URL Definition.................................................3 4. Examples ........................................................6
2.1. Percent-Encoding............................................5 5. Security Considerations .........................................8
3. Defaults for Fields of the LDAP URL............................5 6. Normative References ............................................9
4. Examples.......................................................6 7. Informative References .........................................10
5. Security Considerations........................................8 8. Acknowledgements ...............................................10
6. IANA Considerations............................................9 Appendix A: Changes Since RFC 2255 ................................11
7. Normative References...........................................9 A.1. Technical Changes .........................................11
8. Informative References.........................................10 A.2. Editorial Changes .........................................11
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 1. Introduction
LDAP is the Lightweight Directory Access Protocol [Roadmap]. This LDAP is the Lightweight Directory Access Protocol [RFC4510]. This
document specifies the LDAP URL format for version 3 of LDAP and document specifies the LDAP URL format for version 3 of LDAP and
clarifies how LDAP URLs are resolved. This document also defines an clarifies how LDAP URLs are resolved. This document also defines an
extension mechanism for LDAP URLs. This mechanism may be used to extension mechanism for LDAP URLs. This mechanism may be used to
provide access to new LDAP extensions. provide access to new LDAP extensions.
Note that not all of the parameters of the LDAP search operation Note that not all the parameters of the LDAP search operation
described in [Protocol] can be expressed using the format defined in described in [RFC4511] can be expressed using the format defined in
this document. Note also that URLs may be used to represent reference this document. Note also that URLs may be used to represent
knowledge, including for non-search operations. reference knowledge, including that for non-search operations.
This document is a integral part of the LDAP technical specification This document is an integral part of the LDAP technical specification
[Roadmap] which obsoletes the previously defined LDAP technical [RFC4510], which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety. specification, RFC 3377, in its entirety.
This document replaces RFC 2255. See Appendix A for a list of changes This document replaces RFC 2255. See Appendix A for a list of
relative to RFC 2255. changes relative to RFC 2255.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119].
2. URL Definition 2. URL Definition
An LDAP URL begins with the protocol prefix "ldap" and is defined by An LDAP URL begins with the protocol prefix "ldap" and is defined by
the following grammar, following the ABNF notation defined in the following grammar, following the ABNF notation defined in
[RFC2234]. [RFC4234].
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" 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 [RFC3986].
; <filter> is from Section 3 of
; [RFC4515], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
dn = distinguishedName ; From Section 3 of [LDAPDN], scheme = "ldap"
; subject to the provisions of dn = distinguishedName ; From Section 3 of [RFC4514],
; the "Percent-Encoding" ; subject to the provisions of
; section below. ; the "Percent-Encoding"
; section below.
attributes = attrdesc *(COMMA attrdesc) attributes = attrdesc *(COMMA attrdesc)
attrdesc = selector *(COMMA selector) attrdesc = selector *(COMMA selector)
selector = attributeSelector ; From Section 4.5.1 of selector = attributeSelector ; From Section 4.5.1 of
; [Protocol], subject to the ; [RFC4511], subject to the
; provisions of the ; provisions of the
; "Percent-Encoding" section ; "Percent-Encoding" section
; below. ; below.
scope = "base" / "one" / "sub" scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension) extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue] extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid ; From section 1.4 of [Models]. extype = oid ; From section 1.4 of [RFC4512].
exvalue = LDAPString ; From section 4.1.2 of exvalue = LDAPString ; From section 4.1.2 of
; [Protocol], subject to the ; [RFC4511], subject to the
; provisions of the ; provisions of the
; "Percent-Encoding" section ; "Percent-Encoding" section
; below. ; below.
EXCLAMATION = %x21 ; exclamation mark ("!") EXCLAMATION = %x21 ; exclamation mark ("!")
SLASH = %x2F ; forward slash ("/") SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":") COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?") QUESTION = %x3F ; question mark ("?")
The "ldap" prefix indicates an entry or entries accessible from the The "ldap" prefix indicates an entry or entries accessible from the
LDAP server running on the given hostname at the given portnumber. LDAP server running on the given hostname at the given portnumber.
Note that the <host> may contain literal IPv6 addresses as specified Note that the <host> may contain literal IPv6 addresses as specified
in Section 3.2.2 of [RFC2396bis]. in Section 3.2.2 of [RFC3986].
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 described in [RFC4514]. It identifies the base object of the LDAP
search or the target of a non-search operation. search or the target of a non-search operation.
The <attributes> construct is used to indicate which attributes The <attributes> construct is used to indicate which attributes
should be returned from the entry or entries. 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" 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 for a base object search, "one" for a one-level search, or "sub" for
a subtree search. 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 within the specified scope during the search. It has the format
specified in [Filters]. specified in [RFC4515].
The <extensions> construct provides the LDAP URL with an The <extensions> construct provides the LDAP URL with an
extensibility mechanism, allowing the capabilities of the URL to be extensibility mechanism, allowing the capabilities of the URL to be
extended in the future. Extensions are a simple comma-separated list extended in the future. Extensions are a simple comma-separated list
of type=value pairs, where the =value portion MAY be omitted for of type=value pairs, where the =value portion MAY be omitted for
options not requiring it. Each type=value pair is a separate options not requiring it. Each type=value pair is a separate
extension. These LDAP URL extensions are not necessarily related to extension. These LDAP URL extensions are not necessarily related to
any of the LDAP extension mechanisms. Extensions may be supported or any of the LDAP extension mechanisms. Extensions may be supported or
unsupported by the client resolving the URL. An extension prefixed unsupported by the client resolving the URL. An extension prefixed
with a '!' character (ASCII 0x21) is critical. An extension not with a '!' character (ASCII 0x21) is critical. An extension not
prefixed with a '!' character is non-critical. prefixed with a '!' character is non-critical.
If an LDAP URL extension is implemented (that is, if the If an LDAP URL extension is implemented (that is, if the
implementation understands it and is able to use it), the implementation understands it and is able to use it), the
implementation MUST make use of it. If an extension is not implementation MUST make use of it. If an extension is not
implemented and is marked critical, the implementation MUST NOT implemented and is marked critical, the implementation MUST NOT
process the URL. If an extension is not implemented and it not process the URL. If an extension is not implemented and is not
marked critical, the implementation MUST ignore the extension. marked critical, the implementation MUST ignore the extension.
The extension type (<extype>) MAY be specified using the numeric OID The extension type (<extype>) MAY be specified using the numeric OID
<numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
(e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be
restricted to registered object identifier descriptive names. See restricted to registered object identifier descriptive names. See
[LDAPIANA] for registration details and usage guidelines for [RFC4520] for registration details and usage guidelines for
descriptive names. descriptive names.
No LDAP URL extensions are defined in this document. Other documents No LDAP URL extensions are defined in this document. Other documents
or a future version of this document MAY define one or more or a future version of this document MAY define one or more
extensions. extensions.
2.1. Percent-Encoding 2.1. Percent-Encoding
A generated LDAP URL MUST consist only of the restricted set of A generated LDAP URL MUST consist only of the restricted set of
characters included in one of the following three productions defined characters included in one of the following three productions defined
in [RFC2396bis]: in [RFC3986]:
<reserved> <reserved>
<unreserved> <unreserved>
<pct-encoded> <pct-encoded>
Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
input. An octet MUST be encoded using the percent-encoding mechanism input. An octet MUST be encoded using the percent-encoding mechanism
described in section 2.1 of [RFC2396bis] in any of these situations: described in section 2.1 of [RFC3986] in any of these situations:
The octet is not in the reserved set defined in section 2.2 of The octet is not in the reserved set defined in section 2.2 of
[RFC2396bis] or in the unreserved set defined in section 2.3 of [RFC3986] or in the unreserved set defined in section 2.3 of
[RFC2396bis]. [RFC3986].
It is the single Reserved character '?' and occurs inside a <dn>, It is the single Reserved character '?' and occurs inside a <dn>,
<filter>, or other element of an LDAP URL. <filter>, or other element of an LDAP URL.
It is a comma character ',' that occurs inside an <exvalue>. It is a comma character ',' that occurs inside an <exvalue>.
Note that before the percent-encoding mechanism is applied, the Note that before the percent-encoding mechanism is applied, the
extensions component of the LDAP URL may contain one or more null extensions component of the LDAP URL may contain one or more null
(zero) bytes. No other component may. (zero) bytes. No other component may.
3. Defaults for Fields of the LDAP URL 3. Defaults for Fields of the LDAP URL
Some fields of the LDAP URL are optional, as described above. In the Some fields of the LDAP URL are optional, as described above. In the
absence of any other specification, the following general defaults absence of any other specification, the following general defaults
SHOULD be used when a field is absent. Note that other documents MAY SHOULD be used when a field is absent. Note that other documents MAY
specify different defaulting rules; for example, section 4.1.10 of specify different defaulting rules; for example, section 4.1.10 of
[Protocol] specifies a different rule for determining the correct DN [RFC4511] specifies a different rule for determining the correct DN
to use when it is absent in an LDAP URL that is returned as a to use when it is absent in an LDAP URL that is returned as a
referral. referral.
<host> <host>
If no <host> is given, the client must have some apriori knowledge If no <host> is given, the client must have some a priori
of an appropriate LDAP server to contact. knowledge of an appropriate LDAP server to contact.
<port> <port>
The default LDAP port is TCP port 389. The default LDAP port is TCP port 389.
<dn> <dn>
If no <dn> is given, the default is the zero-length DN, "". If no <dn> is given, the default is the zero-length DN, "".
<attributes> <attributes>
If the <attributes> part is omitted, all user attributes of the If the <attributes> part is omitted, all user attributes of the
entry or entries should be requested (e.g., by setting the entry or entries should be requested (e.g., by setting the
skipping to change at page 6, line 37 skipping to change at page 6, line 7
If <scope> is omitted, a <scope> of "base" is assumed. If <scope> is omitted, a <scope> of "base" is assumed.
<filter> <filter>
If <filter> is omitted, a filter of "(objectClass=*)" is assumed. If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
<extensions> <extensions>
If <extensions> is omitted, no extensions are assumed. If <extensions> is omitted, no extensions are assumed.
4. Examples 4. Examples
The following are some example LDAP URLs using the format defined The following are some example LDAP URLs that use the format defined
above. The first example is an LDAP URL referring to the University above. The first example is an LDAP URL referring to the University
of Michigan entry, available from an LDAP server of the client's of Michigan entry, available from an LDAP server of the client's
choosing: choosing:
ldap:///o=University%20of%20Michigan,c=US ldap:///o=University%20of%20Michigan,c=US
The next example is an LDAP URL referring to the University of The next example is an LDAP URL referring to the University of
Michigan entry in a particular ldap server: Michigan entry in a particular ldap server:
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
Both of these URLs correspond to a base object search of the Both of these URLs correspond to a base object search of the
"o=University of Michigan,c=US" entry using a filter of "o=University of Michigan,c=US" entry using a filter of
"(objectclass=*)", requesting all attributes. "(objectclass=*)", requesting all attributes.
The next example is an LDAP URL referring to only the postalAddress The next example is an LDAP URL referring to only the postalAddress
attribute of the University of Michigan entry: attribute of the University of Michigan entry:
ldap://ldap1.example.net/o=University%20of%20Michigan, ldap://ldap1.example.net/o=University%20of%20Michigan,
c=US?postalAddress c=US?postalAddress
The corresponding LDAP search operation is the same as in the The corresponding LDAP search operation is the same as in the
previous example, except that only the postalAddress attribute is previous example, except that only the postalAddress attribute is
requested. requested.
The next example is an LDAP URL referring to the set of entries found The next example is an LDAP URL referring to the set of entries found
by querying the given LDAP server on port 6666 and doing a subtree by querying the given LDAP server on port 6666 and doing a subtree
search of the University of Michigan for any entry with a common name search of the University of Michigan for any entry with a common name
of "Babs Jensen", retrieving all attributes: of "Babs Jensen", retrieving all attributes:
ldap://ldap1.example.net:6666/o=University%20of%20Michigan, ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen) c=US??sub?(cn=Babs%20Jensen)
The next example is an LDAP URL referring to all children of the c=GB The next example is an LDAP URL referring to all children of the c=GB
entry: entry:
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 The objectClass attribute is requested to be returned along with the
entries, and the default filter of "(objectclass=*)" is used. entries, and the default filter of "(objectclass=*)" is used.
The next example is an LDAP URL to retrieve the mail attribute for 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 LDAP entry named "o=Question?,c=US", illustrating the use of the
the use of the percent-encoding mechanism on the reserved character percent-encoding mechanism on the reserved character '?'.
'?'.
ldap://ldap2.example.com/o=Question%3f,c=US?mail ldap://ldap2.example.com/o=Question%3f,c=US?mail
The next example (which is broken into two lines for readability) The next example (which is broken into two lines for readability)
illustrates the interaction between the LDAP string representation of illustrates the interaction between the LDAP string representation of
filters quoting mechanism and URL quoting mechanisms. the filters-quoting mechanism and the URL-quoting mechanisms.
ldap://ldap3.example.com/o=Babsco,c=US ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04) ???(four-octet=%5c00%5c00%5c00%5c04)
The filter in this example uses the LDAP escaping mechanism of \ to 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 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 \ would be written as (four-octet=\00\00\00\04). Because the \
character must be escaped in a URL, the \'s are percent-encoded as character must be escaped in a URL, the \s are percent-encoded as %5c
%5c (or %5C) in the URL encoding. (or %5C) in the URL encoding.
The next example illustrates the interaction between the LDAP string The next example illustrates the interaction between the LDAP string
representation of DNs quoting mechanism and URL quoting mechanisms. representation of the 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: 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: That is, the left-most RDN value is:
An Example, Inc. An Example, Inc.
The following three URLs that are equivalent, assuming that the The following three URLs are equivalent, assuming that the defaulting
defaulting rules specified in section 4 of this document are used: rules specified in Section 3 of this document are used:
ldap://ldap.example.net ldap://ldap.example.net
ldap://ldap.example.net/ ldap://ldap.example.net/
ldap://ldap.example.net/? ldap://ldap.example.net/?
These three URLs all point to the root DSE on the ldap.example.net These three URLs point to the root DSE on the ldap.example.net
server. server.
The final two examples show use of a hypothetical, experimental bind The final two examples show use of a hypothetical, experimental bind
name extension (the value associated with the extension is an LDAP DN). name extension (the value associated with the extension is an LDAP
DN).
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
The two URLs are the same, except that the second one marks the The two URLs are the same, except that the second one marks the
e-bindname extension as critical. Notice the use of the e-bindname extension as critical. Notice the use of the percent-
percent-encoding mechanism to encode the commas within the encoding mechanism to encode the commas within the distinguished name
distinguished name value in the e-bindname extension. value in the e-bindname extension.
5. Security Considerations 5. Security Considerations
General URL security considerations discussed in [RFC2396bis] are The general URL security considerations discussed in [RFC3986] are
relevant for LDAP URLs. relevant for LDAP URLs.
The use of security mechanisms when processing LDAP URLs requires The use of security mechanisms when processing LDAP URLs requires
particular care, since clients may encounter many different servers particular care, since clients may encounter many different servers
via URLs, and since URLs are likely to be processed automatically, via URLs, and since URLs are likely to be processed automatically,
without user intervention. A client SHOULD have a user-configurable without user intervention. A client SHOULD have a user-configurable
policy that controls which servers the client will establish LDAP policy that controls which servers the client will establish LDAP
sessions with using which security mechanisms, and SHOULD NOT sessions with and with which security mechanisms, and SHOULD NOT
establish LDAP sessions that are inconsistent with this policy. If a establish LDAP sessions that are inconsistent with this policy. If a
client chooses to reuse an existing LDAP session when resolving one client chooses to reuse an existing LDAP session when resolving one
or more LDAP URLs, it MUST ensure that the session is compatible with or more LDAP URLs, it MUST ensure that the session is compatible with
the URL and that no security policies are violated. the URL and that no security policies are violated.
Sending authentication information, no matter the mechanism, may Sending authentication information, no matter the mechanism, may
violate a user's privacy requirements. In the absence of specific violate a user's privacy requirements. In the absence of specific
policy permitting authentication information to be sent to a server, policy permitting authentication information to be sent to a server,
a client should use an anonymous LDAP session. (Note that clients a client should use an anonymous LDAP session. (Note that clients
conforming to previous LDAP URL specifications, where all LDAP conforming to previous LDAP URL specifications, where all LDAP
sessions are anonymous and unprotected, are consistent with this sessions are anonymous and unprotected, are consistent with this
specification; they simply have the default security policy.) Simply specification; they simply have the default security policy.) Simply
opening a transport connection to another server may violate some opening a transport connection to another server may violate some
users' privacy requirements, so clients should provide the user with users' privacy requirements, so clients should provide the user with
a way to control URL processing. a way to control URL processing.
Some authentication methods, in particular reusable passwords sent to Some authentication methods, in particular, reusable passwords sent
the server, may reveal easily-abused information to the remote server to the server, may reveal easily-abused information to the remote
or to eavesdroppers in transit, and should not be used in URL server or to eavesdroppers in transit and should not be used in URL
processing unless explicitly permitted by policy. Confirmation by processing unless they are explicitly permitted by policy.
the human user of the use of authentication information is Confirmation by the human user of the use of authentication
appropriate in many circumstances. Use of strong authentication information is appropriate in many circumstances. Use of strong
methods that do not reveal sensitive information is much preferred. authentication methods that do not reveal sensitive information is
If the URL represents a referral for an update operation, strong much preferred. If the URL represents a referral for an update
authentication methods SHOULD be used. Please refer to the Security operation, strong authentication methods SHOULD be used. Please
Considerations section of [AuthMeth] for more information. refer to the Security Considerations section of [RFC4513] for more
information.
The LDAP URL format allows the specification of an arbitrary LDAP The LDAP URL format allows the specification of an arbitrary LDAP
search operation to be performed when evaluating the LDAP URL. search operation to be performed when evaluating the LDAP URL.
Following an LDAP URL may cause unexpected results, for example, the Following an LDAP URL may cause unexpected results, for example, the
retrieval of large amounts of data, the initiation of a long-lived retrieval of large amounts of data or the initiation of a long-lived
search, etc. The security implications of resolving an LDAP URL are search. The security implications of resolving an LDAP URL are the
the same as those of resolving an LDAP search query. same as those of resolving an LDAP search query.
6. IANA Considerations 6. Normative References
This document has no actions for IANA. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7. Normative References [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods", [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a Resource Identifier (URI): Generic Syntax", STD 66, RFC
work in progress. 3986, January 2005.
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work Specifications: ABNF", RFC 4234, October 2005.
in progress.
[Filters] Smith, M. and Howes, T., "LDAP: String Representation of [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in (LDAP): Technical Specification Road Map", RFC 4510, June
progress. 2006.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Requirement Levels," RFC 2119, BCP 14, March 1997. Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
draft-ietf-ldapbis-protocol-xx.txt, a work in progress. (LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
Specifications: ABNF", RFC 2234, November 1997. (LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006.
[RFC2396bis] [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform (LDAP): String Representation of Distinguished Names", RFC
Resource Identifiers (URI): Generic Syntax", 4514, June 2006.
draft-fielding-uri-rfc2396bis-xx.txt, a work in progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road [RFC4515] Smith, M. Ed. and T. Howes, "Lightweight Directory Access
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. Protocol (LDAP): String Representation of Search Filters",
RFC 4515, June 2006.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 7. Informative References
RFC 3629, November 2003.
8. Informative References [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. None. Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
9. Acknowledgements 8. Acknowledgements
The LDAP URL format was originally defined at the University of The LDAP URL format was originally defined at the University of
Michigan. This material is based upon work supported by the National Michigan. This material is based upon work supported by the National
Science Foundation under Grant No. NCR-9416667. The support of both Science Foundation under Grant No. NCR-9416667. The support of both
the University of Michigan and the National Science Foundation is the University of Michigan and the National Science Foundation is
gratefully acknowledged. gratefully acknowledged.
This document is an update to RFC 2255 by Tim Howes and Mark Smith. This document obsoletes RFC 2255 by Tim Howes and Mark Smith.
Changes included in this revised specification are based upon Changes included in this revised specification are based upon
discussions among the authors, discussions within the LDAP (v3) discussions among the authors, discussions within the LDAP (v3)
Revision Working Group (ldapbis), and discussions within other IETF Revision Working Group (ldapbis), and discussions within other IETF
Working Groups. The contributions of individuals in these working Working Groups. The contributions of individuals in these working
groups is gratefully acknowledged. Several people in particular have groups is gratefully acknowledged. Several people in particular have
made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, made valuable comments on this document: RL "Bob" Morgan, Mark Wahl,
Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
thanks for their contributions. thanks for their contributions.
10. Authors' Addresses Appendix A: Changes Since RFC 2255
Mark Smith, Editor
Pearl Crescent, LLC
447 Marlpool Dr.
Saline, MI 48176
USA
+1 734 944-2856
mcs@pearlcrescent.com
Tim Howes
Opsware, Inc.
599 N. Mathilda Ave.
Sunnyvale, CA 94085
USA
+1 408 744-7509
howes@opsware.com
11. Appendix A: Changes Since RFC 2255
11.1. Technical Changes A.1. Technical Changes
The following technical changes were made to the contents of the "URL The following technical changes were made to the contents of the "URL
Definition" section: Definition" section:
Revised all of the ABNF to use common productions from [Models]. Revised all of the ABNF to use common productions from [RFC4512].
Replaced references to [RFC2396] with a reference to [RFC2396bis] Replaced references to [RFC2396] with a reference to [RFC3986] (this
(this allows literal IPv6 addresses to be used inside the <host> allows literal IPv6 addresses to be used inside the <host> portion of
portion of the URL, and a note was added to remind the reader of this the URL, and a note was added to remind the reader of this
enhancement). Referencing [RFC2396bis] required changes to the ABNF enhancement). Referencing [RFC3986] required changes to the ABNF and
and text so that productions that are no longer defined by text so that productions that are no longer defined by [RFC3986] are
[RFC2396bis] are not used. For example, <hostport> is not defined by not used. For example, <hostport> is not defined by [RFC3986] so it
[RFC2396bis] so it has been replaced with host [COLON port]. Note: has been replaced with host [COLON port]. Note that [RFC3986]
[RFC2396bis] includes new definitions for the "Reserved" and includes new definitions for the "Reserved" and "Unreserved" sets of
"Unreserved" sets of characters, and the net result is that the characters, and the net result is that the following two additional
following two additional characters should be percent-encoded when characters should be percent-encoded when they appear anywhere in the
they appear anywhere in the data used to construct an LDAP URL: "[" data used to construct an LDAP URL: "[" and "]" (these two characters
and "]" (these two characters were first added to the Reserved set by were first added to the Reserved set by RFC 2732).
RFC 2732).
Changed the definition of <attrdesc> to refer to <attributeSelector> Changed the definition of <attrdesc> to refer to <attributeSelector>
from [Protocol]. This allows use of "*" in the <attrdesc> part of from [RFC4511]. This allows the use of "*" in the <attrdesc> part of
the URL. It is believed that existing implementations of RFC 2255 the URL. It is believed that existing implementations of RFC 2255
already support this. already support this.
Avoided use of <prose-val> (bracketed-string) productions in the Avoided use of <prose-val> (bracketed-string) productions in the
<dn>, <host>, <attrdesc>, and <exvalue> rules. <dn>, <host>, <attrdesc>, and <exvalue> rules.
Changed the ABNF for <ldapurl> to group the <dn> component with the Changed the ABNF for <ldapurl> to group the <dn> component with the
preceding <SLASH>. preceding <SLASH>.
Changed the <extype> rule to be an <oid> from [Models]. Changed the <extype> rule to be an <oid> from [RFC4512].
Changed the text about extension types so it references [LDAPIANA]. Changed the text about extension types so it references [RFC4520].
Reordered rules to more closely follow the order the elements appear Reordered rules to more closely follow the order in which the
in the URL. elements appear in the URL.
"Bindname Extension": removed due to lack of known implementations. "Bindname Extension": removed due to lack of known implementations.
11.2. Editorial Changes A.2. Editorial Changes
Changed document title to include "LDAP:" prefix. Changed document title to include "LDAP:" prefix.
IESG Note: removed note about lack of satisfactory mandatory IESG Note: removed note about lack of satisfactory mandatory
authentication mechanisms. authentication mechanisms.
"Status of this Memo" section: updated boilerplate to match current "Status of this Memo" section: updated boilerplate to match current
I-D guidelines. I-D guidelines.
"Abstract" section: separated from introductory material. "Abstract" section: separated from introductory material.
"Table of Contents" and "IANA Considerations" sections: added. "Table of Contents" and "Intellectual Property" sections: added.
"Introduction" section: new section; separated from the Abstract. "Introduction" section: new section; separated from the Abstract.
Changed the text indicate that RFC 2255 is replaced by this document Changed the text indicate that RFC 2255 is replaced by this document
(instead of RFC 1959). Added text to indicate that LDAP URLs are (instead of RFC 1959). Added text to indicate that LDAP URLs are
used for references and referrals. Fixed typo (replaced the nonsense used for references and referrals. Fixed typo (replaced the nonsense
phrase "to perform to retrieve" with "used to retrieve"). Added a phrase "to perform to retrieve" with "used to retrieve"). Added a
note to let the reader know that not all of the parameters of the note to let the reader know that not all of the parameters of the
LDAP search operation described in [Protocol] can be expressed using LDAP search operation described in [RFC4511] can be expressed using
this format. this format.
"URL Definition" section: removed second copy of <ldapurl> grammar "URL Definition" section: removed second copy of <ldapurl> grammar
and following two paragraphs (editorial error in RFC 2255). Fixed and following two paragraphs (editorial error in RFC 2255). Fixed
line break within '!' sequence. Reformatted the ABNF to improve line break within '!' sequence. Reformatted the ABNF to improve
readability by aligning comments and adding some blank lines. readability by aligning comments and adding some blank lines.
Replaced "residing in the LDAP server" with "accessible from the LDAP Replaced "residing in the LDAP server" with "accessible from the LDAP
server" in the sentence immediately following the ABNF. Removed the server" in the sentence immediately following the ABNF. Removed the
sentence "Individual attrdesc names are as defined for sentence "Individual attrdesc names are as defined for
AttributeDescription in [Protocol]." because [Protocol]'s AttributeDescription in [RFC4511]." because [RFC4511]'s
<attributeSelector> is now used directly in the ABNF. Reworded last <attributeSelector> is now used directly in the ABNF. Reworded last
paragraph to clarify which characters must be percent-encoded. Added paragraph to clarify which characters must be percent-encoded. Added
text to indicate that LDAP URLs are used for references and text to indicate that LDAP URLs are used for references and
referrals. Added text that refers to the ABNF from RFC 2234. referrals. Added text that refers to the ABNF from RFC 4234.
Clarified and strengthened the requirements with respect to Clarified and strengthened the requirements with respect to
processing of URLs that contain implements and not implemented processing of URLs that contain implemented and not implemented
extensions (the approach now closely matches that specified in extensions (the approach now closely matches that specified in
[Protocol] for LDAP controls). [RFC4511] for LDAP controls).
"Defaults for Fields of the LDAP URL" section: added; formed by "Defaults for Fields of the LDAP URL" section: added; formed by
moving text about defaults out of the "URL Definition" section. moving text about defaults out of the "URL Definition" section.
Replaced direct reference to the attribute name "*" with a reference Replaced direct reference to the attribute name "*" with a reference
to the special <alluserattrs> selector "*" defined in [Protocol]. to the special <alluserattrs> selector "*" defined in [RFC4511].
"URL Processing" section: removed. "URL Processing" section: removed.
"Examples" section: Modified examples to use example.com and "Examples" section: Modified examples to use example.com and
example.net hostnames. Added missing '?' to the LDAP URL example example.net hostnames. Added missing '?' to the LDAP URL example
whose filter contains three null bytes. Removed space after one whose filter contains three null bytes. Removed space after one
comma within a DN. Revised the bindname example to use e-bindname. 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 Changed the name of an attribute used in one example from "int" to
"four-octet" to avoid potential confusion. Added an example that "four-octet" to avoid potential confusion. Added an example that
demonstrates the interaction between DN escaping and URL demonstrates the interaction between DN escaping and URL percent-
percent-encoding. Added some examples to show URL equivalence with encoding. Added some examples to show URL equivalence with respect
respect to the <dn> portion of the URL. Used uppercase in some to the <dn> portion of the URL. Used uppercase in some examples to
examples to remind the reader that some tokens are case-insensitive. remind the reader that some tokens are case-insensitive.
"Security Considerations" section: Added a note about connection "Security Considerations" section: Added a note about connection
reuse. Added a note about using strong authentication methods for reuse. Added a note about using strong authentication methods for
updates. Added a reference to [AuthMeth]. Added note that simply updates. Added a reference to [RFC4513]. Added note that simply
opening a connection may violate some users' privacy requirements. opening a connection may violate some users' privacy requirements.
Adopted the working group's revised LDAP terminology specification by Adopted the working group's revised LDAP terminology specification by
replacing the word "connection" with "LDAP session" or "LDAP replacing the word "connection" with "LDAP session" or "LDAP
connection" as appropriate. connection" as appropriate.
"Acknowledgements" section: added statement about this being an "Acknowledgements" section: added statement that this document
update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and obsoletes RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
Hallvard Furuseth. Hallvard Furuseth.
"Normative References" section: renamed from "References" per new RFC "Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the guidelines. Changed from [1] style to [RFC4511] style throughout the
document. Added references to RFC 2234 and RFC 3629. Updated all document. Added references to RFC 4234 and RFC 3629. Updated all
RFC 1738 references to point to the appropriate sections within RFC 1738 references to point to the appropriate sections within
[RFC2396bis]. Updated the LDAP references to refer to LDAPBis WG [RFC3986]. Updated the LDAP references to refer to LDAPBis WG
documents. Removed the reference to the LDAP Attribute Syntaxes documents. Removed the reference to the LDAP Attribute Syntaxes
document and added references to the [AuthMeth], [LDAPIANA], and document and added references to the [RFC4513], [RFC4520], and
[Roadmap] documents. [RFC4510] documents.
"Informative References" section: added. "Informative References" section: added.
Header and "Authors' Addresses" sections: added "editor" next to Mark Header and "Authors' Addresses" sections: added "editor" next to Mark
Smith's name. Updated affiliation and contact information. Smith's name. Updated affiliation and contact information.
Copyright: updated the year. Copyright: updated the year.
Throughout the document: surrounded the names of all ABNF productions Throughout the document: surrounded the names of all ABNF productions
with "<" and ">" where they are used in descriptive text. with "<" and ">" where they are used in descriptive text.
12. Appendix B: Changes Since Previous Document Revision Authors' Addresses
This appendix lists all changes relative to the previously published Mark Smith, Editor
revision, draft-ietf-ldapbis-url-08.txt. Note that when appropriate Pearl Crescent, LLC
these changes are also included in Appendix A, but are also included 447 Marlpool Dr.
here for the benefit of the people who have already reviewed Saline, MI 48176
draft-ietf-ldapbis-url-08.txt. This section will be removed before USA
this document is published as an RFC.
12.1. Technical Changes Phone: +1 734 944-2856
EMail: mcs@pearlcrescent.com
Throughout the document: Replaced references to [RFC2396] and Tim Howes
[RFC2732] with references to [RFC2396bis]. This required changes to Opsware, Inc.
the ABNF and text so that productions that are no longer defined by 599 N. Mathilda Ave.
[RFC2396bis] are not used. For example, <hostport> is not defined by Sunnyvale, CA 94085
[RFC2396bis] so it has been replaced with host [COLON port]. Note: USA
[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 Phone: +1 408 744-7509
EMail: howes@opsware.com
Throughout the document: Replaced phrases like "Escaping using the % Full Copyright Statement
method" with "Percent-encoding" to be consistent with the terminology
used in [RFC2396bis].
"URL Definition" section: For consistency, replaced all occurrences Copyright (C) The Internet Society (2006).
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. 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.
Intellectual Property 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
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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 15, line 23 skipping to change at page 15, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Acknowledgement
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
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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet Draft expires on 4 July 2005. Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 108 change blocks. 
317 lines changed or deleted 260 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/