draft-ietf-ldapbis-url-00.txt   draft-ietf-ldapbis-url-01.txt 
Network Working Group Mark Smith, Editor Network Working Group Mark Smith, Editor
Request for Comments: DRAFT Netscape Communications Corp. Request for Comments: DRAFT Netscape Communications Corp.
Obsoletes: RFC 2255 Tim Howes Obsoletes: RFC 2255 Tim Howes
Loudcloud, Inc. Loudcloud, Inc.
21 February 2001 10 May 2001
The LDAP URL Format The LDAP URL Format
<draft-ietf-ldapbis-url-00.txt> <draft-ietf-ldapbis-url-01.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 45 skipping to change at page 1, line 45
document will be submitted as a Standards Track replacement for RFC document will be submitted as a Standards Track replacement for RFC
2255. 2255.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
2. Abstract 2. Abstract
LDAP is the Lightweight Directory Access Protocol, defined in LDAP is the Lightweight Directory Access Protocol, defined in
[RFC2251], [RFC2253], and [RFC2252]. This document describes a [RFC2251bis], [RFC2252bis], and [RFC2253bis]. This document
format for an LDAP Uniform Resource Locator. The format describes an describes a format for an LDAP Uniform Resource Locator. The format
LDAP search operation used to retrieve information from an LDAP describes an LDAP search operation used to retrieve information from
directory, or, in the context of an LDAPv3 referral or reference, the an LDAP directory, or, in the context of an LDAPv3 referral or
format describes a service where an LDAP operation may be progressed. reference, the format describes a service where an LDAP operation may
Note: not all of the parameters of the LDAP search operation be progressed. Note: not all of the parameters of the LDAP search
described in [RFC2251] can be expressed using the format defined in operation described in [RFC2251bis] can be expressed using the format
this document. defined in this document.
This document specifies the LDAP URL format for version 3 of LDAP and This 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, so that future documents can extension mechanism for LDAP URLs, so that future documents can
extend their functionality, for example, to provide access to new extend their functionality, for example, to provide access to new
LDAPv3 extensions as they are defined. LDAPv3 extensions as they are defined.
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 changes
relative to RFC 2255. relative to RFC 2255.
The key words "MUST", "MAY", and "SHOULD" used in this document are The key words "MUST", "MAY", and "SHOULD" used in this document are
to be interpreted as described in [RFC2119]. to be interpreted as described in [RFC2119].
3. URL Definition 3. 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]. [RFC2234].
ldapurl = scheme "://" [hostport] ["/" ldapurl = scheme "://" [hostport] ["/" dn
[dn ["?" [attributes] ["?" [scope] ["?" [attributes] ["?" [scope]
["?" [filter] ["?" extensions]]]]]] ["?" [filter] ["?" extensions]]]]]
scheme = "ldap" scheme = "ldap"
hostport = <hostport from Section 3.2.2 of RFC 2396 [RFC2396]> hostport = <hostport from Section 3.2.2 of [RFC2396]>
dn = <distinguishedName from Section 3 of [RFC2253]> dn = <distinguishedName from Section 3 of [RFC2253bis]>
attributes = attrdesc *("," attrdesc) attributes = attrdesc *("," attrdesc)
attrdesc = <AttributeDescription from Section 4.1.5 of [RFC2251]> / "*" attrdesc = <AttributeDescription from Section 4.1.5 of [RFC2251bis]> / "*"
scope = "base" / "one" / "sub" scope = "base" / "one" / "sub"
filter = <filter from Section 4 of [RFC2254]> filter = <filter from Section 4 of [RFC2254bis]>
extensions = extension *("," extension) extensions = extension *("," extension)
extension = ["!"] extype ["=" exvalue] extension = ["!"] extype ["=" exvalue]
extype = token / xtoken extype = oid / oiddescr
exvalue = <LDAPString from section 4.1.2 of [RFC2251]> exvalue = <LDAPString from section 4.1.2 of [RFC2251bis]>
token = <oid from section 4.1 of [RFC2252]> oid = <LDAPOID from section 4.1.2 of [RFC2251bis]>
xtoken = "x-" token oiddescr = <name from section 3.2 of [LDAP-IANA]>
The "ldap" prefix indicates an entry or entries residing in the LDAP The "ldap" prefix indicates an entry or entries residing in the LDAP
server running on the given hostname at the given portnumber. server running on the given hostname at the given portnumber.
The dn is an LDAP Distinguished Name using the string format The dn is an LDAP Distinguished Name using the string format
described in [RFC2253]. It identifies the base object of the LDAP described in [RFC2253bis]. 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 should The attributes construct is used to indicate which attributes should
be returned from the entry or entries. Individual attrdesc names are be returned from the entry or entries. Individual attrdesc names are
as defined for AttributeDescription in [RFC2251]. as defined for AttributeDescription in [RFC2251bis].
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 [RFC2254]. specified in [RFC2254bis].
The extensions construct provides the LDAP URL with an extensibility The extensions construct provides the LDAP URL with an extensibility
mechanism, allowing the capabilities of the URL to be extended in the mechanism, allowing the capabilities of the URL to be extended in the
future. Extensions are a simple comma-separated list of type=value future. Extensions are a simple comma-separated list of type=value
pairs, where the =value portion MAY be omitted for options not pairs, where the =value portion MAY be omitted for options not
requiring it. Each type=value pair is a separate extension. These requiring it. Each type=value pair is a separate extension. These
LDAP URL extensions are not necessarily related to any of the LDAPv3 LDAP URL extensions are not necessarily related to any of the LDAPv3
extension mechanisms. Extensions may be supported or unsupported by extension mechanisms. Extensions may be supported or unsupported by
the client resolving the URL. An extension prefixed with a '!' the client resolving the URL. An extension prefixed with a '!'
character (ASCII 33) is critical. An extension not prefixed with a character (ASCII 33) is critical. An extension not prefixed with a
skipping to change at page 3, line 42 skipping to change at page 3, line 42
If an extension is unsupported by the client, the client MUST NOT If an extension is unsupported by the client, the client MUST NOT
process the URL if the extension is critical. If an unsupported process the URL if the extension is critical. If an unsupported
extension is non-critical, the client MUST ignore the extension. extension is non-critical, the client MUST ignore the extension.
If a critical extension cannot be processed successfully by the If a critical extension cannot be processed successfully by the
client, the client MUST NOT process the URL. If a non-critical client, the client MUST NOT process the URL. If a non-critical
extension cannot be processed successfully by the client, the client extension cannot be processed successfully by the client, the client
SHOULD ignore the extension. SHOULD ignore the extension.
Extension types prefixed by "X-" or "x-" are reserved for use in The extension type (extype) MAY be specified using the oid form
bilateral agreements between communicating parties. Other extension (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use
types MUST be defined in this document, or in other standards-track of the oiddesc form SHOULD be restricted to registered object
documents. identifier descriptive names. See [LDAP-IANA] for registration
details and usage guidelines for descriptive names.
One LDAP URL extension is defined in this document (see the section No LDAP URL extensions are defined in this document. Other documents
"The Bindname Extension" below). Other documents or a future version or a future version of this document MAY define other extensions.
of this document MAY define other extensions.
Note that characters that are not safe (e.g., spaces) (as defined in Note that characters that are not safe (e.g., spaces) (as defined in
section 2.1 of RFC 2396 [RFC2396]), and the single Reserved character section 2.1 of [RFC2396]), and the single Reserved character '?'
'?' occurring inside a dn, filter, or other element of an LDAP URL occurring inside a dn, filter, or other element of an LDAP URL MUST
MUST be escaped using the % method described in section 2.4 of RFC be escaped using the % method described in section 2.4 of [RFC2396].
2396 [RFC2396]. If a comma character ',' occurs inside an extension If a comma character ',' occurs inside an extension value, the
value, the character MUST also be escaped using the % method. character MUST also be escaped using the % method.
4. Defaults for Fields of the LDAP URL 4. 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: other documents MAY SHOULD be used when a field is absent. Note: other documents MAY
specify different defaulting rules; for example, section 4.1.11 of specify different defaulting rules; for example, section 4.1.11 of
[RFC 2251] specifies a different rule for determining the correct DN [RFC2251bis] specifies a different rule for determining the correct
to use when it is absent in an LDAP URL that is returned as a DN to use when it is absent in an LDAP URL that is returned as a
referral. referral.
hostport hostport
The default LDAP port is TCP port 389. If no hostport is given, The default LDAP port is TCP port 389. If no hostport is given,
the client must have some apriori knowledge of an appropriate LDAP the client must have some apriori knowledge of an appropriate LDAP
server to contact. server to contact.
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, "".
skipping to change at page 4, line 43 skipping to change at page 4, line 43
scope scope
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.
5. The Bindname Extension 5. Examples
This section defines an LDAP URL extension for representing the
distinguished name for a client to use when authenticating to an LDAP
directory during resolution of an LDAP URL. Clients MAY implement
this extension.
The extension type is "bindname". The extension value is the
distinguished name of the directory entry to authenticate as, in the
same form as described for dn in the grammar above. The dn may be the
NULL string to specify unauthenticated access. The extension may be
either critical (prefixed with a '!' character) or non-critical (not
prefixed with a '!' character).
If the bindname extension is critical, the client resolving the URL
MUST authenticate to the directory using the given distinguished name
and an appropriate authentication method. Note that for a NULL
distinguished name, no bind MAY be required to obtain anonymous
access to the directory. If the extension is non-critical, the client
MAY bind to the directory using the given distinguished name.
6. URL Processing
This section describes how an LDAP URL SHOULD be resolved by a
client.
First, the client obtains a connection to the LDAP server referenced
in the URL, or an LDAP server of the client's choice if no LDAP
server is explicitly referenced. This connection MAY be opened
specifically for the purpose of resolving the URL or the client MAY
reuse an already open connection if the open connection is compatible
with the URL. The connection MAY provide confidentiality, integrity,
or other services, e.g., using TLS. Use of security services is at
the client's discretion if not specified in the URL but is encouraged
if the request or any potential responses contains sensitive
information. If the URL represents a referral for an update
operation, security services SHOULD be used.
Next, the client authenticates itself to the LDAP server. This step
is optional, unless the URL contains a critical bindname extension
with a non-NULL value. If a bindname extension is given, the client
proceeds according to the section above.
If a bindname extension is not specified, the client MAY bind to the
directory using an appropriate authentication method of its own
choosing (including NULL authentication). The client may interrogate
the server to determine the most appropriate method.
Next, the client performs the LDAP search operation specified in the
URL. Additional fields in the LDAP protocol search request, such as
sizelimit, timelimit, deref, and anything else not specified or
defaulted in the URL specification, MAY be set at the client's
discretion.
Once the search has completed, the client MAY close the connection to
the LDAP server, or the client MAY keep the connection open for
future use.
7. Examples
The following are some example LDAP URLs using the format defined The following are some example LDAP URLs using 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:
skipping to change at page 7, line 15 skipping to change at page 6, line 4
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" is given below, illustrating
the use of the escaping mechanism on the reserved character '?'. the use of the escaping 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 illustrates the interaction between LDAP and URL The next example illustrates the interaction between LDAP and URL
quoting mechanisms. quoting mechanisms.
ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04) ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04)
The filter in this example uses the LDAP escaping mechanism of \ to 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 (int=\00\00\00\04). Because the \ character must would be written as (int=\00\00\00\04). Because the \ character must
be escaped in a URL, the \'s are escaped as %5c in the URL encoding. be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
The final example shows the use of the bindname extension to specify The following three URLs that are equivalent, assuming that the
the dn a client should use for authentication when resolving the URL. defaulting rules specified in section 4 of this document are used:
ldap:///??sub??bindname=cn=Manager%2co=Foo ldap://ldap.example.net
ldap:///??sub??!bindname=cn=Manager%2co=Foo ldap://ldap.example.net/
ldap://ldap.example.net/?
The two URLs are the same, except that the second one marks the These three URLs all point to the root DSE on the ldap.example.net
server.
The final two examples show use of a hypothetical, experimental bind
name extension (the value associated with the extension is an LDAP DN).
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
The two URLs are the same, except that the second one marks the e-
bindname extension as critical. Notice the use of the % encoding bindname extension as critical. Notice the use of the % encoding
method to encode the comma in the distinguished name value in the method to encode the commas within the distinguished name value in
bindname extension. the e-bindname extension.
8. Security Considerations 6. Security Considerations
General URL security considerations discussed in RFC 2396 [RFC2396] General URL security considerations discussed in [RFC2396] are
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 about which servers to connect to using which security policy about which servers to connect to using which security
mechanisms, and SHOULD NOT make connections that are inconsistent mechanisms, and SHOULD NOT make connections that are inconsistent
with this policy. If a client chooses to reuse an existing with this policy. If a client chooses to reuse an existing
connection when resolving one or more LDAP URL, it MUST ensure that connection when resolving one or more LDAP URL, it MUST ensure that
the connection is compatible with the URL and that no security the connection is compatible with the URL and that no security
skipping to change at page 8, line 19 skipping to change at page 7, line 19
Some authentication methods, in particular reusable passwords sent to Some authentication methods, in particular reusable passwords sent to
the server, may reveal easily-abused information to the remote server the server, may reveal easily-abused information to the remote server
or to eavesdroppers in transit, and should not be used in URL or to eavesdroppers in transit, and should not be used in URL
processing unless explicitly permitted by policy. Confirmation by processing unless explicitly permitted by policy. Confirmation by
the human user of the use of authentication information is the human user of the use of authentication information is
appropriate in many circumstances. Use of strong authentication appropriate in many circumstances. Use of strong authentication
methods that do not reveal sensitive information is much preferred. methods that do not reveal sensitive information is much preferred.
If the URL represents a referral for an update operation, strong If the URL represents a referral for an update operation, strong
authentication methods SHOULD be used. Please refer to the Security authentication methods SHOULD be used. Please refer to the Security
Considerations section of [RFC2829] for more information. Considerations section of [RFC2829bis] 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, the initiation of a long-lived
search, etc. The security implications of resolving an LDAP URL are search, etc. The security implications of resolving an LDAP URL are
the same as those of resolving an LDAP search query. the same as those of resolving an LDAP search query.
9. Acknowledgements 7. 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 is an update to 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, and Jim Sermersheim deserve special thanks for their Kurt Zeilenga, and Jim Sermersheim deserve special thanks for their
contributions. contributions.
10. References 8. References
[LDAP-IANA] IETF LDAPBis WG, "IANA Considerations for LDAP", a work
in progress.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997. Requirement Levels," RFC 2119, March 1997.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory [RFC2251bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
Access Protocol (v3)", RFC 2251, December 1997. (v3)", a work in progress.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, [RFC2252bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
"Lightweight Directory Access Protocol (v3): Attribute Syntax (v3): Attribute Syntax Definitions", a work in progress.
Definitions", RFC 2252, December 1997.
[RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory [RFC2253bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol
Access Protocol (v3): UTF-8 String Representation of Distinguished (v3): UTF-8 String Representation of Distinguished Names", a work in
Names", RFC 2253, December 1997. progress.
[RFC2254] Howes, T., "A String Representation of LDAP Search [RFC2254bis] IETF LDAPBis WG, "A String Representation of LDAP Search
Filters", RFC 2254, December 1997. Filters", a work in progress.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, [RFC2829bis] IETF LDAPBis WG, "Authentication Methods for LDAP", a
"Authentication Methods for LDAP", RFC 2829, May 2000. work in progress.
11. Authors' Address 9. Authors' Address
Mark Smith, Editor Mark Smith, Editor
Netscape Communications Corp. Netscape Communications Corp.
Mailstop USCA17-201 Mailstop USCA17-201
4170 Network Circle 4170 Network Circle
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
+1 650 937-3477 +1 650 937-3477
mcs@netscape.com mcs@netscape.com
Tim Howes Tim Howes
Loudcloud, Inc. Loudcloud, Inc.
599 N. Mathilda Ave. 599 N. Mathilda Ave.
Sunnyvale, CA 94086 Sunnyvale, CA 94086
USA USA
+1 408 744-7509 +1 408 744-7509
howes@loudcloud.com howes@loudcloud.com
12. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at page 10, line 26 skipping to change at page 9, line 33
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13. Appendix A: Changes Since RFC 2255 11. Appendix A: Changes Since RFC 2255
13.1. Technical Changes 11.1. Technical Changes
"URL Definition" section: added missing "*" as an alternative for the "URL Definition" section: added missing "*" as an alternative for the
attrdesc part of the URL. It is believed that existing attrdesc part of the URL. It is believed that existing
implementations of RFC 2255 already support this. Added angle implementations of RFC 2255 already support this. Added angle
brackets around free-form prose in the "dn", "hostport", "attrdesc", brackets around free-form prose in the "dn", "hostport", "attrdesc",
"filter", "exvalue", and "token" rules. Simplified the "xtoken" rule "filter", and "exvalue" rules. Changed the ABNF for ldapurl to group
by removing the "X-" option (case insensitivity is taken care of by the dn component with the preceding slash. Changed the extype rule
the ABNF). Reordered rules to more closely follow the order the to be an LDAPOID from RFC2251bis or an OID description from LDAP-
elements appear in the URL. IANA. Changed the text about extension types so it references LDAP-
IANA. Reordered rules to more closely follow the order the elements
appear in the URL.
13.2. Editorial Changes "Bindname Extension": removed due to lack of known implementations.
11.2. Editorial Changes
"Abstract" section: changed the text indicate that RFC 2255 is "Abstract" section: changed the text indicate that RFC 2255 is
replaced by this document (instead of RFC 1959). Added text to replaced by this document (instead of RFC 1959). Added text to
indicate that LDAP URLs are used for references and referrals. Fixed indicate that LDAP URLs are used for references and referrals. Fixed
typo (replaced the nonsense phrase "to perform to retrieve" with typo (replaced the nonsense phrase "to perform to retrieve" with
"used to retrieve"). Added a note to let the reader know that not "used to retrieve"). Added a note to let the reader know that not
all of the parameters of the LDAP search operation described in all of the parameters of the LDAP search operation described in
[RFC2251] can be expressed using this format. [RFC2251bis] can be expressed using this format.
IESG Note: removed note about lack of satisfactory mandatory IESG Note: removed note about lack of satisfactory mandatory
authentication mechanisms. authentication mechanisms.
"URL Definition" section: removed second copy of ldapurl grammar and "URL Definition" section: removed second copy of ldapurl grammar and
following two paragraphs (editorial error in RFC 2255). Fixed line following two paragraphs (editorial error in RFC 2255). Fixed line
break within '!' sequence. Reworded last paragraph to clarify which break within '!' sequence. Reworded last paragraph to clarify which
characters must be URL escaped. Added text to indicate that LDAP characters must be URL escaped. Added text to indicate that LDAP
URLs are used for references and referrals. Added text that refers URLs are used for references and referrals. Added text that refers
to the ABNF from RFC 2234. to the ABNF from RFC 2234.
skipping to change at page 11, line 26 skipping to change at page 10, line 38
"URL Processing" section: clarified that connections MAY be reused "URL Processing" section: clarified that connections MAY be reused
only if the open connection is compatible with the URL. Added text only if the open connection is compatible with the URL. Added text
to indicate that use of security services is encouraged and that they to indicate that use of security services is encouraged and that they
SHOULD be used when updates are involved. Removed "dn" from SHOULD be used when updates are involved. Removed "dn" from
discussion of authentication methods. Added note that the client MAY discussion of authentication methods. Added note that the client MAY
interrogate the server to determine the most appropriate method. interrogate the server to determine the most appropriate method.
"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. comma within a DN. Revised the bindname example to use e-bindname.
Added some examples to show URL equivalence with respect to the dn
portion of the URL.
"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 RFC 2829. Added note that simply updates. Added a reference to RFC 2829. Added note that simply
opening a connection may violate some users' privacy requirements. opening a connection may violate some users' privacy requirements.
"Acknowledgements" section: added statement about this being an "Acknowledgements" section: added statement about this being an
update to RFC 2255. Added added Kurt Zeilenga and Jim Sermersheim. update to RFC 2255. Added added Kurt Zeilenga and Jim Sermersheim.
"References" section: changed from [1] style to [RFC2251] style "References" section: changed from [1] style to [RFC2251bis] style
throughout the document. Added references to RFCs 2234 and 2829. throughout the document. Added references to RFCs 2234 and 2829.
Updated RFC 1738 references to the appropriate sections within RFC Updated RFC 1738 references to the appropriate sections within RFC
2396. 2396. Updated the references to refer to LDAPBis WG documents.
Added a reference to the LDAP IANA document.
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.
"Appendix C: Loose Ends" section: added.
"Table of Contents" section: added. "Table of Contents" section: added.
14. Appendix B: Changes Since Previous Document Revision 12. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the last published This appendix lists all changes relative to the last published
revision, draft-smith-ldapv3-url-update-01.txt. Note that these revision, draft-ietf-ldapbis-url-00.txt. Note that these changes are
changes are also included in Appendix A, but are included here for also included in Appendix A, but are included here for those who have
those who have already reviewed draft-smith-ldapv3-url-update-01.txt. already reviewed draft-ietf-ldapbis-url-00.txt.
14.1. Technical Changes
"URL Definition" section: added angle brackets around free-form prose
in the "dn", "hostport", "attrdesc", "filter", "exvalue", and "token"
rules. Simplified the "xtoken" rule by removing the "X-" option
(case insensitivity is taken care of by the ABNF). Reordered rules
to more closely follow the order the elements appear in the URL.
14.2. Editorial Changes
Header: changed document from an individual submission to an ldapbis
working group submission. Discussion referred to the ietf-
ldapbis@openldap.org mailing list.
Header and "Authors' Addresses" sections: added "editor" next to Mark
Smith's name.
"Abstract" section: fixed typo (replaced the nonsense phrase "to
perform to retrieve" with "used to retrieve"). Added a note to let
the reader know that not all of the parameters of the LDAP search
operation described in [RFC2251] can be expressed using this format.
"URL Definition" section: added text that refers to the ABNF from RFC
2234.
"Defaults for Fields of the LDAP URL" section: added a note to
clarify that other specifications MAY specify different defaulting
rules.
Copyright: changed the year to 2001.
References: changed from [1] style to [RFC2251] style throughout the
document. Added a reference to RFC 2234. Updated RFC 1738
references to the appropriate sections within RFC 2396.
"Acknowledgements" section: added statement about this being an
update to RFC 2255. Added Jim Sermersheim.
"Loose Ends" section: removed item about referencing RFC 2396 instead 12.1. Technical Changes
of 1738 (done). Removed "Search URLs vs. Referral URLs" item (the
editor believe this has been resolved)." Added item about potentially
supporting userinfo in LDAP URLs. Added item about not supporting
all parameters of the LDAPv3 search operation.
15. Appendix C: Loose Ends "URL Definition" section: changed the ABNF for ldapurl to group the
dn component with the preceding slash. Changed the extype rule to be
is an LDAPOID from RFC2251bis or an OID description from LDAP-IANA.
Changed the text about extension types so it references LDAP-IANA.
Other Extensions: Suggestions for TLS and SASL URL extensions have "Bindname Extension": removed due to lack of known implementations.
been made, but more discussion is needed about whether they are
needed, how they will be specified, and whether they should be added
to this document.
We need to consider whether it makes sense to support constructs like 12.2. Editorial Changes
<userinfo>@<host>:<port> within the hostport field. We do not want
to preclude this in the future, but we may keep the details out of
this document. Note this specification uses the "hostport" construct
from RFC 2396, but not the "server" construct (which is the one that
contains "userinfo"):
server = [ [ userinfo "@" ] hostport ] "Examples" section: revised the bindname example to use e-bindname
hostport = host [ ":" port ] and added some examples to show URL equivalence with respect to the
dn portion of the URL.
Therefore, it may be necessary to replace "hostport" with "server" in "Appendix C: Loose Ends": removed this section entirely.
this specification.
Some parameters of the LDAPv3 search operation defined in section References: updated references to refer to LDAPBis WG documents.
4.5.1 of RFC 2251 are not supported by the LDAP URL format, e.g., Added a reference to the LDAP IANA document.
derefAliases, sizeLimit, timeLimit, typesOnly, controls. Some
ldapbis working group participants would like to see them supported,
while others see this as "out of scope" for ldapbis. Support for
these options could be added using the extension mechanism.
This Internet Draft expires on 21 August 2001. This Internet Draft expires on 10 November 2001.
1. Status of this Memo............................................1 1. Status of this Memo............................................1
2. Abstract.......................................................1 2. Abstract.......................................................1
3. URL Definition.................................................2 3. URL Definition.................................................2
4. Defaults for Fields of the LDAP URL............................4 4. Defaults for Fields of the LDAP URL............................4
5. The Bindname Extension.........................................4 5. Examples.......................................................4
6. URL Processing.................................................5 6. Security Considerations........................................6
7. Examples.......................................................6 7. Acknowledgements...............................................7
8. Security Considerations........................................7 8. References.....................................................7
9. Acknowledgements...............................................8 9. Authors' Address...............................................8
10. References.....................................................8 10. Full Copyright Statement.......................................9
11. Authors' Address...............................................9 11. Appendix A: Changes Since RFC 2255.............................9
12. Full Copyright Statement.......................................9 11.1. Technical Changes...........................................9
13. Appendix A: Changes Since RFC 2255.............................10 11.2. Editorial Changes...........................................10
13.1. Technical Changes...........................................10 12. Appendix B: Changes Since Previous Document Revision...........11
13.2. Editorial Changes...........................................10 12.1. Technical Changes...........................................11
14. Appendix B: Changes Since Previous Document Revision...........12 12.2. Editorial Changes...........................................11
14.1. Technical Changes...........................................12
14.2. Editorial Changes...........................................12
15. Appendix C: Loose Ends.........................................13
 End of changes. 

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