draft-ietf-ldapbis-url-01.txt   draft-ietf-ldapbis-url-02.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. Expires: 9 February 2003 Loudcloud, Inc.
10 May 2001 9 August 2002
The LDAP URL Format LDAP: Uniform Resource Locator
<draft-ietf-ldapbis-url-01.txt> <draft-ietf-ldapbis-url-02.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.
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute Internet-Drafts are working documents of the Internet Engineering
working documents as Internet-Drafts. Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Discussion of this document should take place on the LDAP (v3) Discussion of this document should take place on the LDAP (v3)
Revison (ldapbis) Working Group mailing list <ietf- Revision (ldapbis) Working Group mailing list <ietf-
ldapbis@openldap.org>. After appropriate review and discussion, this ldapbis@openldap.org>.
document will be submitted as a Standards Track replacement for RFC
2255.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
2. Abstract 2. Abstract
This document describes a format for an LDAP Uniform Resource Locator
(URL). An LDAP URL describes an LDAP search operation that is used
to retrieve information from an LDAP directory, or, in the context of
an LDAPv3 referral or reference, an LDAP URL describes a service
where an LDAP operation may be progressed.
3. Table of Contents
1. Status of this Memo............................................1
2. Abstract.......................................................1
3. Table of Contents..............................................2
4. Introduction...................................................2
5. URL Definition.................................................2
6. Defaults for Fields of the LDAP URL............................4
7. Examples.......................................................5
8. Security Considerations........................................7
9. Acknowledgements...............................................8
10. Normative References...........................................8
11. Authors' Address...............................................9
12. Full Copyright Statement.......................................9
13. Appendix A: Changes Since RFC 2255.............................10
13.1. Technical Changes...........................................10
13.2. Editorial Changes...........................................10
14. Appendix B: Changes Since Previous Document Revision...........11
14.1. Technical Changes...........................................11
14.2. Editorial Changes...........................................12
4. Introduction
LDAP is the Lightweight Directory Access Protocol, defined in LDAP is the Lightweight Directory Access Protocol, defined in
[RFC2251bis], [RFC2252bis], and [RFC2253bis]. This document [Protocol]. This document specifies the LDAP URL format for version
describes a format for an LDAP Uniform Resource Locator. The format 3 of LDAP and clarifies how LDAP URLs are resolved. This document
describes an LDAP search operation used to retrieve information from also defines an extension mechanism for LDAP URLs, so that future
an LDAP directory, or, in the context of an LDAPv3 referral or documents can extend their functionality, for example, to provide
reference, the format describes a service where an LDAP operation may access to new LDAPv3 extensions as they are defined. Note: not all
be progressed. Note: not all of the parameters of the LDAP search of the parameters of the LDAP search operation described in
operation described in [RFC2251bis] can be expressed using the format [Protocol] can be expressed using the format defined in this
defined in this document. document.
This document specifies the LDAP URL format for version 3 of LDAP and This document is an integral part of the LDAP Technical Specification
clarifies how LDAP URLs are resolved. This document also defines an [Roadmap].
extension mechanism for LDAP URLs, so that future documents can
extend their functionality, for example, to provide access to new
LDAPv3 extensions as they are defined.
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 5. 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] ["/" dn ldapurl = scheme "://" [hostport] ["/" dn
["?" [attributes] ["?" [scope] ["?" [attributes] ["?" [scope]
["?" [filter] ["?" extensions]]]]] ["?" [filter] ["?" extensions]]]]]
scheme = "ldap" scheme = "ldap"
hostport = <hostport from Section 3.2.2 of [RFC2396]> hostport = <hostport from Section 3.2.2 of [RFC2396]>
dn = <distinguishedName from Section 3 of [RFC2253bis]> dn = <distinguishedName from Section 3 of [LDAPDN]>
attributes = attrdesc *("," attrdesc) attributes = attrdesc *("," attrdesc)
attrdesc = <AttributeDescription from Section 4.1.5 of [RFC2251bis]> / "*" attrdesc = <AttributeDescription from Section 4.1.4 of [Protocol]> / "*"
scope = "base" / "one" / "sub" scope = "base" / "one" / "sub"
filter = <filter from Section 4 of [RFC2254bis]> filter = <filter from Section 4 of [Filters]>
extensions = extension *("," extension) extensions = extension *("," extension)
extension = ["!"] extype ["=" exvalue] extension = ["!"] extype ["=" exvalue]
extype = oid / oiddescr extype = oid / oiddescr
exvalue = <LDAPString from section 4.1.2 of [RFC2251bis]> exvalue = <LDAPString from section 4.1.2 of [Protocol]>
oid = <LDAPOID from section 4.1.2 of [RFC2251bis]> oid = <LDAPOID from section 4.1.2 of [Protocol]>
oiddescr = <name from section 3.2 of [LDAP-IANA]> oiddescr = <name from section 3.3 of [LDAPIANA]>
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 [RFC2253bis]. It identifies the base object of the LDAP described in [LDAPDN]. 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 [RFC2251bis]. as defined for AttributeDescription in [Protocol].
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 [RFC2254bis]. specified in [Filters].
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 45 skipping to change at page 4, line 21
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.
The extension type (extype) MAY be specified using the oid form The extension type (extype) MAY be specified using the oid form
(e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use
of the oiddesc form SHOULD be restricted to registered object of the oiddesc form SHOULD be restricted to registered object
identifier descriptive names. See [LDAP-IANA] for registration identifier descriptive names. See [LDAPIANA] for registration
details and usage guidelines for descriptive names. details and usage guidelines for 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 other extensions. or a future version 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 [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 MUST occurring inside a dn, filter, or other element of an LDAP URL MUST
be escaped using the % method described in section 2.4 of [RFC2396]. be escaped using the % method described in section 2.4 of [RFC2396].
If a comma character ',' occurs inside an extension value, the If a comma character ',' occurs inside an extension 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 6. 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
[RFC2251bis] specifies a different rule for determining the correct [Protocol] specifies a different rule for determining the correct DN
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.
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 5, line 21
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. Examples 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 6, line 30 skipping to change at page 7, line 6
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 e- 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 commas within the distinguished name value in method to encode the commas within the distinguished name value in
the e-bindname extension. the e-bindname extension.
6. Security Considerations 8. Security Considerations
General URL security considerations discussed in [RFC2396] are General URL security considerations discussed in [RFC2396] 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
skipping to change at page 7, line 19 skipping to change at page 7, line 42
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 [RFC2829bis] for more information. Considerations section of [AuthMeth] 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.
7. Acknowledgements 9. 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.
8. References 10. Normative 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
Requirement Levels," RFC 2119, March 1997.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Specifications: ABNF", RFC 2234, November 1997. Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in
progress.
[RFC2251bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
(v3)", a work in progress. ldapbis-iana-xx.txt, a work in progress.
[RFC2252bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol [Filters] Smith, M. and Howes, T., "LDAP: String Representation of
(v3): Attribute Syntax Definitions", a work in progress. Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
progress. [RFC2119] Bradner, S., "Key Words for use in RFCs to
Indicate Requirement Levels," RFC 2119, BCP 14, March 1997.
[RFC2253bis] IETF LDAPBis WG, "Lightweight Directory Access Protocol [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-
(v3): UTF-8 String Representation of Distinguished Names", a work in ietf-ldapbis-protocol-xx.txt, a work in progress.
progress.
[RFC2254bis] IETF LDAPBis WG, "A String Representation of LDAP Search [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Filters", a work in progress. Specifications: ABNF", RFC 2234, November 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998. 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.
[RFC2829bis] IETF LDAPBis WG, "Authentication Methods for LDAP", a [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
work in progress. draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a work in
progress.
9. Authors' Address [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
11. Authors' Address
Mark Smith, Editor Mark Smith, Editor
Netscape Communications Corp. Netscape Communications Corp.
Mailstop USCA17-201 360 W. Caribbean Drive
4170 Network Circle Sunnyvale, CA 94089
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
10. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). 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
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 9, line 33 skipping to change at page 10, line 5
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.
11. Appendix A: Changes Since RFC 2255 13. Appendix A: Changes Since RFC 2255
11.1. Technical Changes 13.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", and "exvalue" rules. Changed the ABNF for ldapurl to group "filter", and "exvalue" rules. Changed the ABNF for ldapurl to group
the dn component with the preceding slash. Changed the extype rule the dn component with the preceding slash. Changed the extype rule
to be an LDAPOID from RFC2251bis or an OID description from LDAP- to be an LDAPOID from [Protocol] or an OID description from
IANA. Changed the text about extension types so it references LDAP- [LDAPIANA]. Changed the text about extension types so it references
IANA. Reordered rules to more closely follow the order the elements [LDAPIANA]. Reordered rules to more closely follow the order the
appear 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 13.2. Editorial Changes
"Abstract" section: changed the text indicate that RFC 2255 is "Abstract" section: separated from introductory material.
replaced by this document (instead of RFC 1959). Added text to
indicate that LDAP URLs are used for references and referrals. Fixed "Table of Contents" section: added.
typo (replaced the nonsense phrase "to perform to retrieve" with
"used to retrieve"). Added a note to let the reader know that not "Introduction" section: new section; separated from the Abstract.
all of the parameters of the LDAP search operation described in Changed the text indicate that RFC 2255 is replaced by this document
[RFC2251bis] can be expressed using this format. (instead of RFC 1959). Added text to indicate that LDAP URLs are
used for references and referrals. Fixed typo (replaced the nonsense
phrase "to perform to retrieve" with "used to retrieve"). Added a
note to let the reader know that not all of the parameters of the
LDAP search operation described in [Protocol] can be expressed using
this format.
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 10, line 48 skipping to change at page 11, line 22
comma within a DN. Revised the bindname example to use e-bindname. comma within a DN. Revised the bindname example to use e-bindname.
Added some examples to show URL equivalence with respect to the dn Added some examples to show URL equivalence with respect to the dn
portion of the URL. 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 Kurt Zeilenga and Jim Sermersheim.
"References" section: changed from [1] style to [RFC2251bis] style "Normative References" section: renamed from "References" per new RFC
throughout the document. Added references to RFCs 2234 and 2829. guidelines. Changed from [1] style to [Protocol] style throughout the
Updated RFC 1738 references to the appropriate sections within RFC document. Added references to RFCs 2234 and 2829. Updated RFC 1738
2396. Updated the references to refer to LDAPBis WG documents. references to the appropriate sections within RFC 2396. Updated the
Added a reference to the LDAP IANA document. references to refer to LDAPBis WG documents. Removed the reference to
the LDAP Attribute Syntaxes document and added references to the LDAP
IANA and Roadmap documents.
Header and "Authors' Addresses" sections: added "editor" next to Mark Header and "Authors' Address" 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.
"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-ietf-ldapbis-url-00.txt. Note that these changes are revision, draft-ietf-ldapbis-url-01.txt. Note that these changes are
also included in Appendix A, but are included here for those who have also included in Appendix A, but are included here for those who have
already reviewed draft-ietf-ldapbis-url-00.txt. already reviewed draft-ietf-ldapbis-url-01.txt.
12.1. Technical Changes 14.1. Technical Changes
"URL Definition" section: changed the ABNF for ldapurl to group the None.
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.
"Bindname Extension": removed due to lack of known implementations. 14.2. Editorial Changes
12.2. Editorial Changes "Abstract" section: separated from introductory material.
"Examples" section: revised the bindname example to use e-bindname "Table of Contents" section: moved to correct location (after
and added some examples to show URL equivalence with respect to the Abstract).
dn portion of the URL.
"Appendix C: Loose Ends": removed this section entirely. "Introduction" section: new section; separated from the Abstract.
References: updated references to refer to LDAPBis WG documents. Copyright: updated the year to 2002.
Added a reference to the LDAP IANA document.
This Internet Draft expires on 10 November 2001. "URL Definition" section: updated section references to match current
LDAPBis drafts.
1. Status of this Memo............................................1 "Normative References" section: renamed from "References" per new RFC
2. Abstract.......................................................1 guidelines. Replaced [RFC2251bis] style references with textual ones
3. URL Definition.................................................2 like [Protocol] for LDAPBis documents and updated reference format to
4. Defaults for Fields of the LDAP URL............................4 match that used in other LDAPBis drafts. Removed references to
5. Examples.......................................................4 LDAPBis Attribute Syntaxes document and added a reference to the
6. Security Considerations........................................6 Roadmap document. Added "BCP 14" to the RFC 2119 reference.
7. Acknowledgements...............................................7
8. References.....................................................7 "Authors' Address" section: updated Mark Smith's postal address.
9. Authors' Address...............................................8
10. Full Copyright Statement.......................................9 This Internet Draft expires on 9 February 2003.
11. Appendix A: Changes Since RFC 2255.............................9
11.1. Technical Changes...........................................9
11.2. Editorial Changes...........................................10
12. Appendix B: Changes Since Previous Document Revision...........11
12.1. Technical Changes...........................................11
12.2. Editorial Changes...........................................11
 End of changes. 

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