draft-ietf-ldapbis-url-04.txt   draft-ietf-ldapbis-url-05.txt 
Network Working Group Mark Smith, Editor Network Working Group Mark Smith, Editor
Request for Comments: DRAFT Netscape Communications Corp. Request for Comments: DRAFT Pearl Crescent, LLC
Obsoletes: RFC 2255 Tim Howes Obsoletes: RFC 2255 Tim Howes
Expires: 25 April 2004 Opsware, Inc. Expires: 13 August 2004 Opsware, Inc.
25 October 2003 13 February 2004
LDAP: Uniform Resource Locator LDAP: Uniform Resource Locator
<draft-ietf-ldapbis-url-04.txt> <draft-ietf-ldapbis-url-05.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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)
Revision (ldapbis) Working Group mailing list <ietf- Revision (ldapbis) Working Group mailing list <ietf-
ldapbis@openldap.org>. ldapbis@openldap.org>.
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
2. Abstract 2. Abstract
This document describes a format for an LDAP Uniform Resource Locator This document describes a format for an LDAP Uniform Resource Locator
(URL). An LDAP URL describes an LDAP search operation that is used (URL). An LDAP URL describes an LDAP search operation that is used
to retrieve information from an LDAP directory, or, in the context of to retrieve information from an LDAP directory, or, in the context of
an LDAPv3 referral or reference, an LDAP URL describes a service an LDAPv3 referral or reference, an LDAP URL describes a service
where an LDAP operation may be progressed. where an LDAP operation may be progressed.
3. Table of Contents 3. Table of Contents
1. Status of this Memo............................................1 1. Status of this Memo............................................1
2. Abstract.......................................................1 2. Abstract.......................................................1
3. Table of Contents..............................................2 3. Table of Contents..............................................2
4. Introduction...................................................2 4. Introduction...................................................2
5. URL Definition.................................................2 5. URL Definition.................................................3
5.1. Escaping Using the Method.................................4 5.1. Escaping Using the % Method.................................4
6. Defaults for Fields of the LDAP URL............................5 6. Defaults for Fields of the LDAP URL............................5
7. Examples.......................................................6 7. Examples.......................................................5
8. Security Considerations........................................8 8. Security Considerations........................................7
9. Normative References...........................................8 9. Normative References...........................................8
10. Informative References.........................................9 10. Informative References.........................................9
11. Intellectual Property Rights...................................9 11. Intellectual Property Rights...................................9
12. Acknowledgements...............................................10 12. Acknowledgements...............................................10
13. Authors' Address...............................................10 13. Authors' Addresses.............................................10
14. Full Copyright Statement.......................................11 14. Full Copyright Statement.......................................11
15. Appendix A: Changes Since RFC 2255.............................11 15. Appendix A: Changes Since RFC 2255.............................11
15.1. Technical Changes...........................................11 15.1. Technical Changes...........................................11
15.2. Editorial Changes...........................................12 15.2. Editorial Changes...........................................12
16. Appendix B: Changes Since Previous Document Revision...........13 16. Appendix B: Changes Since Previous Document Revision...........13
16.1. Technical Changes...........................................14 16.1. Technical Changes...........................................14
16.2. Editorial Changes...........................................14 16.2. Editorial Changes...........................................14
4. Introduction 4. Introduction
skipping to change at page 3, line 28 skipping to change at page 3, line 32
; see the "Escaping Using the % Method" section below. ; see the "Escaping Using the % Method" section below.
scope = "base" / "one" / "sub" scope = "base" / "one" / "sub"
filter = <filter from Section 4 of [Filters]> filter = <filter from Section 4 of [Filters]>
; see the "Escaping Using the % Method" section below. ; see the "Escaping Using the % Method" section below.
extensions = extension *(COMMA extension) extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue] extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid / oiddescr extype = oid / oiddescr
exvalue = <LDAPString from section 4.1.2 of [Protocol]> exvalue = <LDAPString from section 4.1.2 of [Protocol]>
; see the "Escaping Using the % Method" section below. ; see the "Escaping Using the % Method" section below.
oid = <LDAPOID from section 4.1.2 of [Protocol]> oid = <LDAPOID from section 4.1.2 of [Protocol]>
oiddescr = <name from section 3.3 of [RFC3383]> oiddescr = <name from section 3.3 of [LDAPIANA]>
EXCLAMATION = %x21 ; exclamation mark ("!") EXCLAMATION = %x21 ; exclamation mark ("!")
ASTERISK = %x2A ; asterisk ("*") ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":") COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?") QUESTION = %x3F ; question mark ("?")
SLASH = %x5C; forward slash ("/") SLASH = %x5C; forward slash ("/")
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. Note server running on the given hostname at the given portnumber. Note
that the hostport may contain literal IPv6 addresses as specified in that the hostport may contain literal IPv6 addresses as specified in
skipping to change at page 4, line 22 skipping to change at page 4, line 25
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
'!' character is non-critical. '!' character is non-critical.
If an extension is supported by the client, the client MUST obey the If an LDAP URL extension is recognized by an implementation, the
extension if the extension is critical. The client SHOULD obey implementation MUST make use of it. If an extension is not
supported extensions that are non-critical. recognized and is marked critical, the implementation MUST NOT
process the URL. If an extension is not recognized and it not marked
If an extension is unsupported by the client, the client MUST NOT critical, the implementation MUST ignore the extension.
process the URL if the extension is critical. If an unsupported
extension is non-critical, the client MUST ignore the extension.
If a critical extension cannot be processed successfully by the
client, the client MUST NOT process the URL. If a non-critical
extension cannot be processed successfully by the client, the client
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 [RFC3383] for registration details identifier descriptive names. See [LDAPIANA] for registration
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.
5.1. Escaping Using the % Method 5.1. Escaping Using the % Method
A generated LDAP URL MUST consist only of the restricted set of A generated LDAP URL MUST consist only of the restricted set of
characters included in the uric production that is defined in section characters included in the uric production that is defined in section
2 of [RFC2396]. Implementations SHOULD accept other valid UTF-8 2 of [RFC2396]. Implementations SHOULD accept other valid UTF-8
strings [UTF-8] as input. An octet MUST be escaped using the % strings [RFC3629] as input. An octet MUST be escaped using the %
method described in section 2.4 of [RFC2396] in any of these method described in section 2.4 of [RFC2396] in any of these
situations: situations:
The octet is not in the reserved set defined in section 2.2 of The octet is not in the reserved set defined in section 2.2 of
[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.
6. 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.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.
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
skipping to change at page 7, line 7 skipping to change at page 6, line 48
The objectClass attribute is requested to be returned along with the The objectClass attribute is requested to be returned along with the
entries, and the default filter of "(objectclass=*)" is used. entries, and the default filter of "(objectclass=*)" is used.
The next example is an LDAP URL to retrieve the mail attribute for The next example is an LDAP URL to retrieve the mail attribute for
the LDAP entry named "o=Question?,c=US" is given below, illustrating the LDAP entry named "o=Question?,c=US" 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 the LDAP string The next example (which is broken into two lines for readability)
representation of filters quoting mechanism and URL quoting illustrates the interaction between the LDAP string representation of
mechanisms. filters quoting mechanism and URL quoting mechanisms.
ldap://ldap3.example.com/o=Babsco,c=US???(four-octet=%5c00%5c00%5c00%5c04) ldap://ldap3.example.com/o=Babsco,c=US
IP The filter in this example uses the LDAP escaping mechanism of \ ???(four-octet=%5c00%5c00%5c00%5c04)
to encode three zero or null bytes in the value. In LDAP, the filter
The filter in this example uses the LDAP escaping mechanism of \ to
encode three zero or null bytes in the value. In LDAP, the filter
would be written as (four-octet=\00\00\00\04). Because the \ would be written as (four-octet=\00\00\00\04). Because the \
character must be escaped in a URL, the \'s are escaped as %5c in the character must be escaped in a URL, the \'s are escaped as %5c in the
URL encoding. URL encoding.
The next example illustrates the interaction between the LDAP string The next example illustrates the interaction between the LDAP string
representation of DNs quoting mechanism and URL quoting mechanisms. representation of DNs quoting mechanism and URL quoting mechanisms.
ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US
The DN encoded in the above URL is: The DN encoded in the above URL is:
skipping to change at page 8, line 52 skipping to change at page 8, line 47
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. Normative References 9. Normative References
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a
work in progress.
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
progress. in progress.
[Filters] Smith, M. and Howes, T., "LDAP: String Representation of [Filters] Smith, M. and Howes, T., "LDAP: String Representation of
Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
progress. progress.
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
ldapbis-bcp64-xx.txt, 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, BCP 14, March 1997. Requirement Levels," RFC 2119, BCP 14, March 1997.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-ietf-
ietf-ldapbis-protocol-xx.txt, a work in progress. ldapbis-protocol-xx.txt, a work in progress.
[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.
[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.
[RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access Protocol
(LDAP)", RFC 3383, September 2002.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods", [RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Literal
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a work in IPv6 Addresses in URL's", RFC 2732, December 1999.
progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
draft-yergeau-rfc2279bis-xx.txt, a work in progress. RFC 3629, November 2003.
10. Informative References 10. Informative References
None. None.
11. Intellectual Property Rights 11. 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 or other rights that might be claimed to intellectual property 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
skipping to change at page 10, line 36 skipping to change at page 10, line 31
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, Jim Sermersheim, and Hallvard Furuseth deserve special Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
thanks for their contributions. thanks for their contributions.
13. Authors' Address 13. Authors' Addresses
Mark Smith, Editor Mark Smith, Editor
Netscape Communications Corp. Pearl Crescent, LLC
360 W. Caribbean Drive 447 Marlpool Dr.
Sunnyvale, CA 94089 Saline, MI 48176
USA USA
+1 650 937-3477 +1 734 944-2856
MarkCSmithWork@aol.com mcs@pearlcrescent.com
Tim Howes Tim Howes
Opsware, Inc. Opsware, Inc.
599 N. Mathilda Ave. 599 N. Mathilda Ave.
Sunnyvale, CA 94085 Sunnyvale, CA 94085
USA USA
+1 408 744-7509 +1 408 744-7509
howes@opsware.com howes@opsware.com
14. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 12, line 9 skipping to change at page 12, line 9
URL. It is believed that existing implementations of RFC 2255 URL. It is believed that existing implementations of RFC 2255
already support this. already support this.
Added angle brackets around free-form prose in the "dn", "hostport", Added angle brackets around free-form prose in the "dn", "hostport",
"attrdesc", "filter", and "exvalue" rules. "attrdesc", "filter", and "exvalue" rules.
Changed the ABNF for ldapurl to group the dn component with the Changed the ABNF for ldapurl to group the dn component with the
preceding slash. preceding slash.
Changed the extype rule to be an LDAPOID from [Protocol] or an OID Changed the extype rule to be an LDAPOID from [Protocol] or an OID
description from [RFC3383]. description from [LDAPIANA].
Changed the text about extension types so it references [RFC3383]. Changed the text about extension types so it references [LDAPIANA].
Reordered rules to more closely follow the order the elements appear Reordered rules to more closely follow the order the elements appear
in the URL. in the URL.
"Bindname Extension": removed due to lack of known implementations. "Bindname Extension": removed due to lack of known implementations.
15.2. Editorial Changes 15.2. Editorial Changes
Changed document title to include "LDAP:" prefix. Changed document title to include "LDAP:" prefix.
IESG Note: removed note about lack of satisfactory mandatory IESG Note: removed note about lack of satisfactory mandatory
skipping to change at page 12, line 45 skipping to change at page 12, line 45
phrase "to perform to retrieve" with "used to retrieve"). Added a phrase "to perform to retrieve" with "used to retrieve"). Added a
note to let the reader know that not all of the parameters of the note to let the reader know that not all of the parameters of the
LDAP search operation described in [Protocol] can be expressed using LDAP search operation described in [Protocol] can be expressed using
this format. this format.
"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. Clarified and strengthened the
requirements with respect to processing of URLs that contain
recognized and unrecognized extensions (the approach now 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 21 skipping to change at page 13, line 24
whose filter contains three null bytes. Removed space after one whose filter contains three null bytes. Removed space after one
comma within a DN. Revised the bindname example to use e-bindname. comma within a DN. Revised the bindname example to use e-bindname.
Changed the name of an attribute used in one example from "int" to Changed the name of an attribute used in one example from "int" to
"four-octet" to avoid potential confusion. Added an example that "four-octet" to avoid potential confusion. Added an example that
demonstrates the interaction between DN escaping and URL escaping. demonstrates the interaction between DN escaping and URL escaping.
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 [AuthMeth]. 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 Kurt Zeilenga, Jim Sermersheim, and update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
Hallvard Furuseth. Hallvard Furuseth.
"Normative References" section: renamed from "References" per new RFC "Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the guidelines. Changed from [1] style to [Protocol] style throughout the
document. Added references to RFCs 2234, 2829, and 3383. Updated document. Added references to RFC 2234, RFC 2732, and RFC 3629.
RFC 1738 references to the appropriate sections within RFC 2396. Updated all RFC 1738 references to point to the appropriate sections
Updated the references to refer to LDAPBis WG documents. Removed the within RFC 2396. Updated the LDAP references to refer to LDAPBis WG
reference to the LDAP Attribute Syntaxes document and added a documents. Removed the reference to the LDAP Attribute Syntaxes
reference to the Roadmap document. document and added references to the [AuthMeth], [LDAPIANA], and
[Roadmap] documents.
"Informative References" section: added for clarity. "Informative References" section: added for clarity.
Header and "Authors' Address" 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.
16. Appendix B: Changes Since Previous Document Revision 16. 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-03.txt. Note that when appropriate revision, draft-ietf-ldapbis-url-04.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 draft- here for the benefit of the people who have already reviewed draft-
ietf-ldapbis-url-03.txt. This section will be removed before this ietf-ldapbis-url-04.txt. This section will be removed before this
document is published as an RFC. document is published as an RFC.
16.1. Technical Changes 16.1. Technical Changes
None. Clarified and strengthened the requirements with respect to
processing of URLs that contain recognized and unrecognized
extensions (the approach now matches that specified in [Protocol] for
LDAP controls).
16.2. Editorial Changes 16.2. Editorial Changes
"URL Definition" section: added comments in the ABNF to point the "URL Definition" section: corrected a section reference to
reader to the "Escaping Using the % Method" section, which was [Protocol].
changed into a section of its own to highlight the importance of
escaping the URL components correctly.
"Examples" section: changed the name of an attribute used in one
example from "int" to "four-octet" to avoid potential confusion.
Replaced all occurrences of "asterix" with the correctly spelled
"asterisk."
"Normative References" section: changed UTF-8 reference to point to "Examples" section: improved formatting and fixed a typographic error
the UTF-8 Internet Draft; replace [LDAPIANA] Internet Draft reference (removed extraneous "IP") in the "four-octet" example.
with a reference to RFC 3383.
"Intellectual Property Rights" section: added. "Normative References" section: changed the UTF-8 reference to point
to RFC 3629, changed the RFC 3383 reference to point to the LDAP IANA
Internet Draft, and indented the reference descriptions to enhance
readability.
Author's Addresses section: New email address for Mark Smith. Authors' Addresses section: New contact information for Mark Smith.
"Full Copyright Statement" section: updated text to match latest IETF Updated the copyright year to 2004.
guidelines.
This Internet Draft expires on 25 April 2004. This Internet Draft expires on 13 August 2004.
 End of changes. 

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