draft-ietf-ldapbis-url-06.txt   draft-ietf-ldapbis-url-07.txt 
Network Working Group Mark Smith, Editor Network Working Group Mark Smith, Editor
Request for Comments: DRAFT Pearl Crescent, LLC Request for Comments: DRAFT Pearl Crescent, LLC
Obsoletes: RFC 2255 Tim Howes Obsoletes: RFC 2255 Tim Howes
Expires: 14 January 2005 Opsware, Inc. Expires: 24 April 2005 Opsware, Inc.
14 July 2004 24 October 2004
LDAP: Uniform Resource Locator LDAP: Uniform Resource Locator
<draft-ietf-ldapbis-url-06.txt> <draft-ietf-ldapbis-url-07.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she become
disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with RFC 3668.
This document is intended to be published as a Standards Track RFC, This document is intended to be published as a Standards Track RFC,
replacing RFC 2255. Distribution of this memo is unlimited. replacing RFC 2255. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF Technical discussion of this document will take place on the IETF
LDAP (v3) Revision (ldapbis) Working Group mailing list LDAP (v3) Revision (ldapbis) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly <ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the editor <mcs@pearlcrescent.com>. to the editor <mcs@pearlcrescent.com>.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 34 skipping to change at page 2, line 34
6. IANA Considerations............................................9 6. IANA Considerations............................................9
7. Normative References...........................................9 7. Normative References...........................................9
8. Informative References.........................................10 8. Informative References.........................................10
9. Intellectual Property Rights...................................10 9. Intellectual Property Rights...................................10
10. Acknowledgements...............................................10 10. Acknowledgements...............................................10
11. Authors' Addresses.............................................11 11. Authors' Addresses.............................................11
12. Appendix A: Changes Since RFC 2255.............................11 12. Appendix A: Changes Since RFC 2255.............................11
12.1. Technical Changes...........................................11 12.1. Technical Changes...........................................11
12.2. Editorial Changes...........................................12 12.2. Editorial Changes...........................................12
13. Appendix B: Changes Since Previous Document Revision...........13 13. Appendix B: Changes Since Previous Document Revision...........13
13.1. Technical Changes...........................................14 13.1. Editorial Changes...........................................14
13.2. Editorial Changes...........................................14
14. Intellectual Property Rights...................................14 14. Intellectual Property Rights...................................14
15. Full Copyright.................................................15 15. Full Copyright.................................................14
1. Introduction 1. Introduction
LDAP is the Lightweight Directory Access Protocol, defined in LDAP is the Lightweight Directory Access Protocol, defined in
[Protocol]. This document specifies the LDAP URL format for version [Protocol]. This document specifies the LDAP URL format for version
3 of LDAP and clarifies how LDAP URLs are resolved. This document 3 of LDAP and clarifies how LDAP URLs are resolved. This document
also defines an extension mechanism for LDAP URLs, so that future also defines an extension mechanism for LDAP URLs, so that future
documents can extend their functionality, for example, to provide documents can extend their functionality, for example, to provide
access to new LDAPv3 extensions as they are defined. Note: not all access to new LDAPv3 extensions as they are defined. Note: not all
of the parameters of the LDAP search operation described in of the parameters of the LDAP search operation described in
skipping to change at page 4, line 37 skipping to change at page 4, line 37
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 0x21) is critical. An extension not prefixed with a character (ASCII 0x21) is critical. An extension not prefixed with a
'!' character is non-critical. '!' character is non-critical.
If an LDAP URL extension is recognized by an implementation (that is, If an LDAP URL extension is implemented (that is, if the
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
recognized 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 recognized and it not marked process the URL. If an extension is not implemented and it not
critical, the implementation MUST ignore the extension. marked critical, the implementation MUST 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 [LDAPIANA] 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 one or more or a future version of this document MAY define one or more
extensions. extensions.
skipping to change at page 5, line 24 skipping to change at page 5, line 24
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
[RFC2396] or in the unreserved set defined in section 2.3 of [RFC2396] or in the unreserved set defined in section 2.3 of
[RFC2396]. [RFC2396].
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 extension value. It is a comma character ',' that occurs inside an extension value.
Note that before the % method of escaping is applied, the extensions
component of the LDAP URL may contain one or more null (zero) bytes.
No other component may.
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: other documents MAY SHOULD be used when a field is absent. Note: 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 [Protocol] specifies a different rule for determining the correct DN
to use when it is absent in an LDAP URL that is returned as a to use when it is absent in an LDAP URL that is returned as a
referral. referral.
skipping to change at page 12, line 39 skipping to change at page 12, line 39
"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. Replaced "residing in the LDAP server" break within '!' sequence. Replaced "residing in the LDAP server"
with "accessible from the LDAP server" in the sentence immediately with "accessible from the LDAP server" in the sentence immediately
following the ABNF. Reworded last paragraph to clarify which following the ABNF. 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. Clarified and strengthened the to the ABNF from RFC 2234. Clarified and strengthened the
requirements with respect to processing of URLs that contain requirements with respect to processing of URLs that contain
recognized and unrecognized extensions (the approach now matches that implements and not implemented extensions (the approach now closely
specified in [Protocol] for LDAP controls). matches that specified in [Protocol] 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.
"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.
skipping to change at page 13, line 43 skipping to change at page 13, line 43
"Informative References" section: added for clarity. "Informative References" section: added for clarity.
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.
13. Appendix B: Changes Since Previous Document Revision 13. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the previously published This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-url-05.txt. Note that when appropriate revision, draft-ietf-ldapbis-url-06.txt. Note that when appropriate
these changes are also included in Appendix A, but are also included these changes are also included in Appendix A, but are also included
here for the benefit of the people who have already reviewed here for the benefit of the people who have already reviewed
draft-ietf-ldapbis-url-05.txt. This section will be removed before draft-ietf-ldapbis-url-06.txt. This section will be removed before
this document is published as an RFC. this document is published as an RFC.
13.1. Technical Changes 13.1. Editorial Changes
"URL Definition" section: changed the hex value for SLASH to 0x2F (it
was 0x5C which is "\" not "/"). Also, broke some long lines into two
lines to avoid exceeding the 72 column limit.
13.2. Editorial Changes
"Status of this Memo", "Intellectual Property Rights", and "Full
Copyright" sections: updated to use boilerplate from RFC 3667 and RFC
3668.
"Status of this Memo", "Abstract" and "Table of Contents" sections:
removed section numbers.
"Introduction" section: added missing RFC 2119 keywords. "Status of this Memo" section: replaced RFC 3668 (IPR) boilerplate
paragraph with the version that says "each author" instead of "I."
"URL Definition" section: replaced "residing in the LDAP server" with "URL Definition" section: replaced phrases such as "recognized by"
"accessible from the LDAP server" in the sentence immediately with "implemented by" when referring to LDAP URL extensions.
following the ABNF. Also, added the explanatory phrase "(that is, if
the implementation understands it and is able to use it)" to the
sentence that begins "If an LDAP URL extension is recognized by an
implementation...." Also, replaced "ASCII 33" with ASCII 0x21 in the
text that refers to the "!" character.
"IANA Considerations" section: added. "URL Definition" section: added the following two sentences at the
end of the subsection on "Escaping Using the % Method":
Note that before the % method of escaping is applied, the
extensions component of the LDAP URL may contain one or more null
(zero) bytes. No other component may.
14. Intellectual Property Rights 14. Intellectual Property Rights
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
skipping to change at page 15, line 25 skipping to change at page 15, line 8
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet Draft expires on 14 January 2005. This Internet Draft expires on 24 April 2005.
 End of changes. 

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