draft-ietf-ldapbis-url-08.txt   draft-ietf-ldapbis-url-09.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: 16 May 2005 Opsware, Inc. Expires: 4 July 2005 Opsware, Inc.
16 November 2004 4 January 2005
LDAP: Uniform Resource Locator LDAP: Uniform Resource Locator
<draft-ietf-ldapbis-url-08.txt> <draft-ietf-ldapbis-url-09.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she become have been or will be disclosed, and any of which he or she become
aware will be 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.
skipping to change at page 2, line 21 skipping to change at page 2, line 21
referral or reference, an LDAP URL describes a service where an LDAP referral or reference, an LDAP URL describes a service where an LDAP
operation may be progressed. operation may be progressed.
Table of Contents Table of Contents
Status of this Memo............................................1 Status of this Memo............................................1
Abstract.......................................................2 Abstract.......................................................2
Table of Contents..............................................2 Table of Contents..............................................2
1. Introduction...................................................2 1. Introduction...................................................2
2. URL Definition.................................................3 2. URL Definition.................................................3
2.1. Escaping Using the % Method.................................5 2.1. Percent-Encoding............................................5
3. Defaults for Fields of the LDAP URL............................5 3. Defaults for Fields of the LDAP URL............................5
4. Examples.......................................................6 4. Examples.......................................................6
5. Security Considerations........................................8 5. Security Considerations........................................8
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. Acknowledgements...............................................10 9. Acknowledgements...............................................10
10. Authors' Addresses.............................................10 10. Authors' Addresses.............................................11
11. Appendix A: Changes Since RFC 2255.............................11 11. Appendix A: Changes Since RFC 2255.............................11
11.1. Technical Changes...........................................11 11.1. Technical Changes...........................................11
11.2. Editorial Changes...........................................11 11.2. Editorial Changes...........................................12
12. Appendix B: Changes Since Previous Document Revision...........13 12. Appendix B: Changes Since Previous Document Revision...........14
12.1. Technical Changes...........................................13 12.1. Technical Changes...........................................14
12.2. Editorial Changes...........................................14 12.2. Editorial Changes...........................................14
Intellectual Property Rights...................................15 Intellectual Property Rights...................................14
Full Copyright.................................................15 Full Copyright.................................................15
1. Introduction 1. Introduction
LDAP is the Lightweight Directory Access Protocol [Roadmap]. This LDAP is the Lightweight Directory Access Protocol [Roadmap]. This
document specifies the LDAP URL format for version 3 of LDAP and document specifies the LDAP URL format for version 3 of LDAP and
clarifies how LDAP URLs are resolved. This document also defines an clarifies how LDAP URLs are resolved. This document also defines an
extension mechanism for LDAP URLs. This mechanism may be used to extension mechanism for LDAP URLs. This mechanism may be used to
provide access to new LDAP extensions. provide access to new LDAP extensions.
skipping to change at page 3, line 22 skipping to change at page 3, line 22
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119].
2. URL Definition 2. URL Definition
An LDAP URL begins with the protocol prefix "ldap" and is defined by An LDAP URL begins with the protocol prefix "ldap" and is defined by
the following grammar, following the ABNF notation defined in the following grammar, following the ABNF notation defined in
[RFC2234]. [RFC2234].
ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
[QUESTION [attributes] [QUESTION [scope] [SLASH dn [QUESTION [attributes]
[QUESTION [filter] [QUESTION extensions]]]]] [QUESTION [scope] [QUESTION [filter]
; <hostport> is from Section [QUESTION extensions]]]]]
; 3.2.2 of [RFC2396] as updated ; <host> and <port> are defined
; by [RFC2732] to allow IPv6 ; in Sections 3.2.2 and 3.2.3
; literal addresses. ; of [RFC2396bis].
; <filter> is from Section 3 of ; <filter> is from Section 3 of
; [Filters], subject to the ; [Filters], subject to the
; provisions of the "Escaping ; provisions of the
; Using the % Method" section ; "Percent-Encoding" section
; below. ; below.
scheme = "ldap" scheme = "ldap"
dn = distinguishedName ; From Section 3 of [LDAPDN]. dn = distinguishedName ; From Section 3 of [LDAPDN],
; See the "Escaping Using the ; subject to the provisions of
; % Method" section below. ; the "Percent-Encoding"
; section below.
attributes = attrdesc *(COMMA attrdesc) attributes = attrdesc *(COMMA attrdesc)
attrdesc = selector *(COMMA selector) attrdesc = selector *(COMMA selector)
selector = attributeSelector ; From Section 4.5.1 of selector = attributeSelector ; From Section 4.5.1 of
; [Protocol]. See the "Escaping ; [Protocol], subject to the
; Using the % Method" section ; provisions of the
; "Percent-Encoding" section
; below. ; below.
scope = "base" / "one" / "sub" scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension) extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue] extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid ; From section 1.4 of [Models]. extype = oid ; From section 1.4 of [Models].
exvalue = LDAPString ; From section 4.1.2 of exvalue = LDAPString ; From section 4.1.2 of
; [Protocol]. See the "Escaping ; [Protocol], subject to the
; Using the % Method" section ; provisions of the
; "Percent-Encoding" section
; below. ; below.
EXCLAMATION = %x21 ; exclamation mark ("!") EXCLAMATION = %x21 ; exclamation mark ("!")
SLASH = %x2F ; forward slash ("/") SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":") COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?") QUESTION = %x3F ; question mark ("?")
The "ldap" prefix indicates an entry or entries accessible from the The "ldap" prefix indicates an entry or entries accessible from the
LDAP server running on the given hostname at the given portnumber. LDAP server running on the given hostname at the given portnumber.
Note that the <hostport> may contain literal IPv6 addresses as Note that the <host> may contain literal IPv6 addresses as specified
specified in [RFC2732]. in Section 3.2.2 of [RFC2396bis].
The <dn> is an LDAP Distinguished Name using the string format The <dn> is an LDAP Distinguished Name using the string format
described in [LDAPDN]. It identifies the base object of the LDAP described in [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 The <attributes> construct is used to indicate which attributes
should be returned from the entry or entries. should be returned from the entry or entries.
The <scope> construct is used to specify the scope of the search to The <scope> construct is used to specify the scope of the search to
perform in the given LDAP server. The allowable scopes are "base" perform in the given LDAP server. The allowable scopes are "base"
skipping to change at page 5, line 17 skipping to change at page 5, line 20
<numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
(e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be
restricted to registered object identifier descriptive names. See restricted to registered object identifier descriptive names. See
[LDAPIANA] for registration details and usage guidelines for [LDAPIANA] for registration details and usage guidelines for
descriptive names. descriptive names.
No LDAP URL extensions are defined in this document. Other documents No LDAP URL extensions are defined in this document. Other documents
or a future version of this document MAY define one or more or a future version of this document MAY define one or more
extensions. extensions.
2.1. Escaping Using the % Method 2.1. Percent-Encoding
A generated LDAP URL MUST consist only of the restricted set of A generated LDAP URL MUST consist only of the restricted set of
characters included in the <uric> production that is defined in characters included in one of the following three productions defined
section 2 of [RFC2396]. Implementations SHOULD accept other valid in [RFC2396bis]:
UTF-8 strings [RFC3629] as input. An octet MUST be escaped using the
% method described in section 2.4 of [RFC2396] in any of these <reserved>
situations: <unreserved>
<pct-encoded>
Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
input. An octet MUST be encoded using the percent-encoding mechanism
described in section 2.1 of [RFC2396bis] in any of these situations:
The octet is not in the reserved set defined in section 2.2 of The octet is not in the reserved set defined in section 2.2 of
[RFC2396] or in the unreserved set defined in section 2.3 of [RFC2396bis] or in the unreserved set defined in section 2.3 of
[RFC2396]. [RFC2396bis].
It is the single Reserved character '?' and occurs inside a <dn>, It is the single Reserved character '?' and occurs inside a <dn>,
<filter>, or other element of an LDAP URL. <filter>, or other element of an LDAP URL.
It is a comma character ',' that occurs inside an <exvalue>. It is a comma character ',' that occurs inside an <exvalue>.
Note that before the % method of escaping is applied, the extensions Note that before the percent-encoding mechanism is applied, the
component of the LDAP URL may contain one or more null (zero) bytes. extensions component of the LDAP URL may contain one or more null
No other component may. (zero) bytes. No other component may.
3. Defaults for Fields of the LDAP URL 3. Defaults for Fields of the LDAP URL
Some fields of the LDAP URL are optional, as described above. In the Some fields of the LDAP URL are optional, as described above. In the
absence of any other specification, the following general defaults absence of any other specification, the following general defaults
SHOULD be used when a field is absent. Note that other documents MAY SHOULD be used when a field is absent. Note that other documents MAY
specify different defaulting rules; for example, section 4.1.10 of specify different defaulting rules; for example, section 4.1.10 of
[Protocol] specifies a different rule for determining the correct DN [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> <host>
The default LDAP port is TCP port 389. If no <hostport> is given, If no <host> is given, the client must have some apriori knowledge
the client must have some apriori knowledge of an appropriate LDAP of an appropriate LDAP server to contact.
server to contact.
<port>
The default LDAP port is TCP port 389.
<dn> <dn>
If no <dn> is given, the default is the zero-length DN, "". If no <dn> is given, the default is the zero-length DN, "".
<attributes> <attributes>
If the <attributes> part is omitted, all user attributes of the If the <attributes> part is omitted, all user attributes of the
entry or entries should be requested (e.g., by setting the entry or entries should be requested (e.g., by setting the
attributes field AttributeDescriptionList in the LDAP search attributes field AttributeDescriptionList in the LDAP search
request to a NULL list, or by using the special <alluserattrs> request to a NULL list, or by using the special <alluserattrs>
selector "*"). selector "*").
skipping to change at page 7, line 24 skipping to change at page 7, line 34
The next example is an LDAP URL referring to all children of the c=GB The next example is an LDAP URL referring to all children of the c=GB
entry: entry:
LDAP://ldap1.example.com/c=GB?objectClass?ONE LDAP://ldap1.example.com/c=GB?objectClass?ONE
The objectClass attribute is requested to be returned along with the The objectClass attribute is requested to be returned along with the
entries, and the default filter of "(objectclass=*)" is used. entries, and the default filter of "(objectclass=*)" is used.
The next example is an LDAP URL to retrieve the mail attribute for The next example is an LDAP URL to retrieve the mail attribute for
the LDAP entry named "o=Question?,c=US" is given below, illustrating the LDAP entry named "o=Question?,c=US" is given below, illustrating
the use of the escaping mechanism on the reserved character '?'. the use of the percent-encoding mechanism on the reserved character
'?'.
ldap://ldap2.example.com/o=Question%3f,c=US?mail ldap://ldap2.example.com/o=Question%3f,c=US?mail
The next example (which is broken into two lines for readability) The next example (which is broken into two lines for readability)
illustrates the interaction between the LDAP string representation of illustrates the interaction between the LDAP string representation of
filters quoting mechanism and URL quoting mechanisms. filters quoting mechanism and URL quoting mechanisms.
ldap://ldap3.example.com/o=Babsco,c=US ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04) ???(four-octet=%5c00%5c00%5c00%5c04)
The filter in this example uses the LDAP escaping mechanism of \ to The filter in this example uses the LDAP escaping mechanism of \ to
encode three zero or null bytes in the value. In LDAP, the filter encode three zero or null bytes in the value. In LDAP, the filter
would be written as (four-octet=\00\00\00\04). Because the \ would be written as (four-octet=\00\00\00\04). Because the \
character must be escaped in a URL, the \'s are escaped as %5c (or character must be escaped in a URL, the \'s are percent-encoded as
%5C) in the URL encoding. %5c (or %5C) in the URL encoding.
The next example illustrates the interaction between the LDAP string The next example illustrates the interaction between the LDAP string
representation of DNs quoting mechanism and URL quoting mechanisms. representation of DNs quoting mechanism and URL quoting mechanisms.
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
The DN encoded in the above URL is: The DN encoded in the above URL is:
o=An Example\2C Inc.,c=US o=An Example\2C Inc.,c=US
skipping to change at page 8, line 24 skipping to change at page 8, line 35
These three URLs all point to the root DSE on the ldap.example.net These three URLs all point to the root DSE on the ldap.example.net
server. server.
The final two examples show use of a hypothetical, experimental bind The final two examples show use of a hypothetical, experimental bind
name extension (the value associated with the extension is an LDAP DN). name extension (the value associated with the extension is an LDAP DN).
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
The two URLs are the same, except that the second one marks the The two URLs are the same, except that the second one marks the
e-bindname extension as critical. Notice the use of the % encoding e-bindname extension as critical. Notice the use of the
method to encode the commas within the distinguished name value in percent-encoding mechanism to encode the commas within the
the e-bindname extension. distinguished name value in the e-bindname extension.
5. Security Considerations 5. Security Considerations
General URL security considerations discussed in [RFC2396] are General URL security considerations discussed in [RFC2396bis] are
relevant for LDAP URLs. relevant for LDAP URLs.
The use of security mechanisms when processing LDAP URLs requires The use of security mechanisms when processing LDAP URLs requires
particular care, since clients may encounter many different servers particular care, since clients may encounter many different servers
via URLs, and since URLs are likely to be processed automatically, via URLs, and since URLs are likely to be processed automatically,
without user intervention. A client SHOULD have a user-configurable without user intervention. A client SHOULD have a user-configurable
policy that controls which servers the client will establish LDAP policy that controls which servers the client will establish LDAP
sessions with using which security mechanisms, and SHOULD NOT sessions with using which security mechanisms, and SHOULD NOT
establish LDAP sessions that are inconsistent with this policy. If a establish LDAP sessions that are inconsistent with this policy. If a
client chooses to reuse an existing LDAP session when resolving one client chooses to reuse an existing LDAP session when resolving one
skipping to change at page 10, line 5 skipping to change at page 10, line 15
[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", [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress. draft-ietf-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 [RFC2396bis]
Resource Identifiers (URI): Generic Syntax", RFC 2396, Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform
August 1998. Resource Identifiers (URI): Generic Syntax",
draft-fielding-uri-rfc2396bis-xx.txt, a work in progress.
[RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999.
[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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003. RFC 3629, November 2003.
8. Informative References 8. Informative References
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
skipping to change at page 11, line 20 skipping to change at page 11, line 32
11. Appendix A: Changes Since RFC 2255 11. Appendix A: Changes Since RFC 2255
11.1. Technical Changes 11.1. Technical Changes
The following technical changes were made to the contents of the "URL The following technical changes were made to the contents of the "URL
Definition" section: Definition" section:
Revised all of the ABNF to use common productions from [Models]. Revised all of the ABNF to use common productions from [Models].
Added note and references to [RFC2732] to allow literal IPv6 Replaced references to [RFC2396] with a reference to [RFC2396bis]
addresses inside the hostport portion of the URL. (this allows literal IPv6 addresses to be used inside the <host>
portion of the URL, and a note was added to remind the reader of this
enhancement). Referencing [RFC2396bis] required changes to the ABNF
and text so that productions that are no longer defined by
[RFC2396bis] are not used. For example, <hostport> is not defined by
[RFC2396bis] so it has been replaced with host [COLON port]. Note:
[RFC2396bis] includes new definitions for the "Reserved" and
"Unreserved" sets of characters, and the net result is that the
following two additional characters should be percent-encoded when
they appear anywhere in the data used to construct an LDAP URL: "["
and "]" (these two characters were first added to the Reserved set by
RFC 2732).
Changed the definition of <attrdesc> to refer to <attributeSelector> Changed the definition of <attrdesc> to refer to <attributeSelector>
from [Protocol]. This allows use of "*" in the <attrdesc> part of from [Protocol]. This allows use of "*" in the <attrdesc> part of
the URL. It is believed that existing implementations of RFC 2255 the URL. It is believed that existing implementations of RFC 2255
already support this. already support this.
Avoided use of <prose-val> (bracketed-string) productions in the Avoided use of <prose-val> (bracketed-string) productions in the
<dn>, <hostport>, <attrdesc>, and <exvalue> rules. <dn>, <host>, <attrdesc>, and <exvalue> rules.
Changed the ABNF for <ldapurl> to group the <dn> component with the Changed the ABNF for <ldapurl> to group the <dn> component with the
preceding <SLASH>. preceding <SLASH>.
Changed the <extype> rule to be an <oid> from [Models]. Changed the <extype> rule to be an <oid> from [Models].
Changed the text about extension types so it references [LDAPIANA]. 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.
skipping to change at page 12, line 27 skipping to change at page 12, line 48
"URL Definition" section: removed second copy of <ldapurl> grammar "URL Definition" section: removed second copy of <ldapurl> grammar
and following two paragraphs (editorial error in RFC 2255). Fixed and following two paragraphs (editorial error in RFC 2255). Fixed
line break within '!' sequence. Reformatted the ABNF to improve line break within '!' sequence. Reformatted the ABNF to improve
readability by aligning comments and adding some blank lines. readability by aligning comments and adding some blank lines.
Replaced "residing in the LDAP server" with "accessible from the LDAP Replaced "residing in the LDAP server" with "accessible from the LDAP
server" in the sentence immediately following the ABNF. Removed the server" in the sentence immediately following the ABNF. Removed the
sentence "Individual attrdesc names are as defined for sentence "Individual attrdesc names are as defined for
AttributeDescription in [Protocol]." because [Protocol]'s AttributeDescription in [Protocol]." because [Protocol]'s
<attributeSelector> is now used directly in the ABNF. Reworded last <attributeSelector> is now used directly in the ABNF. Reworded last
paragraph to clarify which characters must be URL escaped. Added paragraph to clarify which characters must be percent-encoded. Added
text to indicate that LDAP URLs are used for references and text to indicate that LDAP URLs are used for references and
referrals. Added text that refers to the ABNF from RFC 2234. referrals. Added text that refers to the ABNF from RFC 2234.
Clarified and strengthened the requirements with respect to Clarified and strengthened the requirements with respect to
processing of URLs that contain implements and not implemented processing of URLs that contain implements and not implemented
extensions (the approach now closely matches that specified in extensions (the approach now closely matches that specified in
[Protocol] for LDAP controls). [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.
Replaced direct reference to the attribute name "*" with a reference Replaced direct reference to the attribute name "*" with a reference
to the special <alluserattrs> selector "*" defined in [Protocol]. to the special <alluserattrs> selector "*" defined in [Protocol].
"URL Processing" section: removed. "URL Processing" section: removed.
"Examples" section: Modified examples to use example.com and "Examples" section: Modified examples to use example.com and
example.net hostnames. Added missing '?' to the LDAP URL example example.net hostnames. Added missing '?' to the LDAP URL example
whose filter contains three null bytes. Removed space after one whose filter contains three null bytes. Removed space after one
comma within a DN. Revised the bindname example to use e-bindname. comma within a DN. Revised the bindname example to use e-bindname.
Changed the name of an attribute used in one example from "int" to Changed the name of an attribute used in one example from "int" to
"four-octet" to avoid potential confusion. Added an example that "four-octet" to avoid potential confusion. Added an example that
demonstrates the interaction between DN escaping and URL escaping. demonstrates the interaction between DN escaping and URL
Added some examples to show URL equivalence with respect to the <dn> percent-encoding. Added some examples to show URL equivalence with
portion of the URL. Used uppercase in some examples to remind the respect to the <dn> portion of the URL. Used uppercase in some
reader that some tokens are case-insensitive. examples to remind the reader that some tokens are case-insensitive.
"Security Considerations" section: Added a note about connection "Security Considerations" section: Added a note about connection
reuse. Added a note about using strong authentication methods for reuse. Added a note about using strong authentication methods for
updates. Added a reference to [AuthMeth]. Added note that simply updates. Added a reference to [AuthMeth]. Added note that simply
opening a connection may violate some users' privacy requirements. opening a connection may violate some users' privacy requirements.
Adopted the working group's revised LDAP terminology specification by Adopted the working group's revised LDAP terminology specification by
replacing the word "connection" with "LDAP session" or "LDAP replacing the word "connection" with "LDAP session" or "LDAP
connection" as appropriate. connection" as appropriate.
"Acknowledgements" section: added statement about this being an "Acknowledgements" section: added statement 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 RFC 2234, RFC 2732, and RFC 3629. document. Added references to RFC 2234 and RFC 3629. Updated all
Updated all RFC 1738 references to point to the appropriate sections RFC 1738 references to point to the appropriate sections within
within RFC 2396. Updated the LDAP references to refer to LDAPBis WG [RFC2396bis]. Updated the LDAP references to refer to LDAPBis WG
documents. Removed the reference to the LDAP Attribute Syntaxes documents. Removed the reference to the LDAP Attribute Syntaxes
document and added references to the [AuthMeth], [LDAPIANA], and document and added references to the [AuthMeth], [LDAPIANA], and
[Roadmap] documents. [Roadmap] documents.
"Informative References" section: added. "Informative References" section: added.
Header and "Authors' Addresses" sections: added "editor" next to Mark Header and "Authors' Addresses" sections: added "editor" next to Mark
Smith's name. Updated affiliation and contact information. Smith's name. Updated affiliation and contact information.
Copyright: updated the year. Copyright: updated the year.
Throughout the document: surrounded the names of all ABNF productions Throughout the document: surrounded the names of all ABNF productions
with "<" and ">" where they are used in descriptive text. with "<" and ">" where they are used in descriptive text.
12. Appendix B: Changes Since Previous Document Revision 12. 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-07.txt. Note that when appropriate revision, draft-ietf-ldapbis-url-08.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-07.txt. This section will be removed before draft-ietf-ldapbis-url-08.txt. This section will be removed before
this document is published as an RFC. this document is published as an RFC.
12.1. Technical Changes 12.1. Technical Changes
"URL Definition" section: avoid the use of <prose-val> Throughout the document: Replaced references to [RFC2396] and
(bracketed-string) productions. Use <attributeSelector> from [RFC2732] with references to [RFC2396bis]. This required changes to
[Protocol] and <oid> from [Models]; this allowed <oid>, <oiddescr>, the ABNF and text so that productions that are no longer defined by
and <ASTERISK> to be removed from this document. Include correct [RFC2396bis] are not used. For example, <hostport> is not defined by
section references for [Protocol] and [Filters]. [RFC2396bis] so it has been replaced with host [COLON port]. Note:
[RFC2396bis] includes new definitions for the "Reserved" and
"Unreserved" sets of characters, and the net result is that the
following two additional characters should be percent-encoded when
they appear anywhere in the data used to construct an LDAP URL: "["
and "]" (these two characters were first added to the Reserved set by
RFC 2732).
12.2. Editorial Changes 12.2. Editorial Changes
"Abstract" section: spelled out LDAP on first use. Throughout the document: Replaced phrases like "Escaping using the %
method" with "Percent-encoding" to be consistent with the terminology
"Introduction" section: referenced [Roadmap] upon first use of LDAP used in [RFC2396bis].
and expanded the paragraph that begins "This document is an integral
part of the LDAP technical specification..." to match the text used
in [Protocol]. Also re-worded the text that describes the extension
mechanism.
"URL Definition" section: reformatted the ABNF to improve readability
by aligning comments and adding some blank lines. Removed the
sentence "Individual attrdesc names are as defined for
AttributeDescription in [Protocol]." because [Protocol]'s
<attributeSelector> is now used directly in the ABNF. Replaced one
occurrence of "extension value" with <exvalue> to improve clarity.
"Defaults for Fields of the LDAP URL" section: in the <attributes>
paragraph, replaced this phrase:
or (in LDAPv3) by requesting the special attribute name "*"
with the following:
by using the special <alluserattrs> selector "*"
"Examples" section: used uppercase "LDAP" and "ONE" in an example to
remind the reader that these tokens are case-insensitive. Likewise,
used uppercase in some hex escaped strings (e.g., replace "%5c" with
"%5C").
"Security Considerations" section: adopted the working group's
revised LDAP terminology specification by updating the 2nd and 3rd
paragraphs to replace the word "connection" with "LDAP session" or
"LDAP connection" as appropriate.
References: moved [LDAPIANA] to "Informative References."
Changed these two sections to unnumbered ones: "Intellectual Property
Rights" and "Full Copyright." Removed the extra "Intellectual
Property Rights" section.
Throughout the document: surrounded the names of all ABNF productions "URL Definition" section: For consistency, replaced all occurrences
with "<" and ">" where they are used in descriptive text. of the phrase 'see the "Percent-Encoding" section below' with
'subject to the provisions of the "Percent-Encoding" section below.'
Throughout the document: replaced "Note: ..." constructs with "Note Updated the copyright year to 2005.
that ...."
Intellectual Property Rights 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 34 skipping to change at page 15, line 25
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Full Copyright
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
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 16 May 2005. This Internet Draft expires on 4 July 2005.
 End of changes. 

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