4 Network Working Group Mark Smith, Editor
5 Request for Comments: DRAFT Pearl Crescent, LLC
6 Obsoletes: RFC 2255 Tim Howes
7 Expires: 4 July 2005 Opsware, Inc.
12 LDAP: Uniform Resource Locator
13 <draft-ietf-ldapbis-url-09.txt>
19 By submitting this Internet-Draft, each author represents that any
20 applicable patent or other IPR claims of which he or she is aware
21 have been or will be disclosed, and any of which he or she become
22 aware will be disclosed, in accordance with RFC 3668.
24 This document is intended to be published as a Standards Track RFC,
25 replacing RFC 2255. Distribution of this memo is unlimited.
26 Technical discussion of this document will take place on the IETF
27 LDAP (v3) Revision (ldapbis) Working Group mailing list
28 <ietf-ldapbis@openldap.org>. Please send editorial comments directly
29 to the editor <mcs@pearlcrescent.com>.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF), its areas, and its working groups. Note that
33 other groups may also distribute working documents as
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than a "work in progress."
41 The list of current Internet-Drafts can be accessed at
42 http://www.ietf.org/1id-abstracts.html
44 The list of Internet-Draft Shadow Directories can be accessed at
45 http://www.ietf.org/shadow.html
47 Copyright (C) The Internet Society (2004). All Rights Reserved.
48 Please see the Full Copyright section near the end of this document
55 Smith & Howes Intended Category: Standards Track [Page 1]
57 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
62 This document describes a format for a Lightweight Directory Access
63 Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL
64 describes an LDAP search operation that is used to retrieve
65 information from an LDAP directory, or, in the context of an LDAP
66 referral or reference, an LDAP URL describes a service where an LDAP
67 operation may be progressed.
71 Status of this Memo............................................1
72 Abstract.......................................................2
73 Table of Contents..............................................2
74 1. Introduction...................................................2
75 2. URL Definition.................................................3
76 2.1. Percent-Encoding............................................5
77 3. Defaults for Fields of the LDAP URL............................5
78 4. Examples.......................................................6
79 5. Security Considerations........................................8
80 6. IANA Considerations............................................9
81 7. Normative References...........................................9
82 8. Informative References.........................................10
83 9. Acknowledgements...............................................10
84 10. Authors' Addresses.............................................11
85 11. Appendix A: Changes Since RFC 2255.............................11
86 11.1. Technical Changes...........................................11
87 11.2. Editorial Changes...........................................12
88 12. Appendix B: Changes Since Previous Document Revision...........14
89 12.1. Technical Changes...........................................14
90 12.2. Editorial Changes...........................................14
91 Intellectual Property Rights...................................14
92 Full Copyright.................................................15
96 LDAP is the Lightweight Directory Access Protocol [Roadmap]. This
97 document specifies the LDAP URL format for version 3 of LDAP and
98 clarifies how LDAP URLs are resolved. This document also defines an
99 extension mechanism for LDAP URLs. This mechanism may be used to
100 provide access to new LDAP extensions.
102 Note that not all of the parameters of the LDAP search operation
103 described in [Protocol] can be expressed using the format defined in
104 this document. Note also that URLs may be used to represent reference
105 knowledge, including for non-search operations.
111 Smith & Howes Intended Category: Standards Track [Page 2]
113 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
116 This document is a integral part of the LDAP technical specification
117 [Roadmap] which obsoletes the previously defined LDAP technical
118 specification, RFC 3377, in its entirety.
120 This document replaces RFC 2255. See Appendix A for a list of changes
121 relative to RFC 2255.
123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
125 document are to be interpreted as described in BCP 14 [RFC2119].
129 An LDAP URL begins with the protocol prefix "ldap" and is defined by
130 the following grammar, following the ABNF notation defined in
133 ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
134 [SLASH dn [QUESTION [attributes]
135 [QUESTION [scope] [QUESTION [filter]
136 [QUESTION extensions]]]]]
137 ; <host> and <port> are defined
138 ; in Sections 3.2.2 and 3.2.3
140 ; <filter> is from Section 3 of
141 ; [Filters], subject to the
143 ; "Percent-Encoding" section
148 dn = distinguishedName ; From Section 3 of [LDAPDN],
149 ; subject to the provisions of
150 ; the "Percent-Encoding"
153 attributes = attrdesc *(COMMA attrdesc)
154 attrdesc = selector *(COMMA selector)
155 selector = attributeSelector ; From Section 4.5.1 of
156 ; [Protocol], subject to the
158 ; "Percent-Encoding" section
161 scope = "base" / "one" / "sub"
162 extensions = extension *(COMMA extension)
163 extension = [EXCLAMATION] extype [EQUALS exvalue]
167 Smith & Howes Intended Category: Standards Track [Page 3]
169 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
172 extype = oid ; From section 1.4 of [Models].
174 exvalue = LDAPString ; From section 4.1.2 of
175 ; [Protocol], subject to the
177 ; "Percent-Encoding" section
180 EXCLAMATION = %x21 ; exclamation mark ("!")
181 SLASH = %x2F ; forward slash ("/")
182 COLON = %x3A ; colon (":")
183 QUESTION = %x3F ; question mark ("?")
186 The "ldap" prefix indicates an entry or entries accessible from the
187 LDAP server running on the given hostname at the given portnumber.
188 Note that the <host> may contain literal IPv6 addresses as specified
189 in Section 3.2.2 of [RFC2396bis].
191 The <dn> is an LDAP Distinguished Name using the string format
192 described in [LDAPDN]. It identifies the base object of the LDAP
193 search or the target of a non-search operation.
195 The <attributes> construct is used to indicate which attributes
196 should be returned from the entry or entries.
198 The <scope> construct is used to specify the scope of the search to
199 perform in the given LDAP server. The allowable scopes are "base"
200 for a base object search, "one" for a one-level search, or "sub" for
203 The <filter> is used to specify the search filter to apply to entries
204 within the specified scope during the search. It has the format
205 specified in [Filters].
207 The <extensions> construct provides the LDAP URL with an
208 extensibility mechanism, allowing the capabilities of the URL to be
209 extended in the future. Extensions are a simple comma-separated list
210 of type=value pairs, where the =value portion MAY be omitted for
211 options not requiring it. Each type=value pair is a separate
212 extension. These LDAP URL extensions are not necessarily related to
213 any of the LDAP extension mechanisms. Extensions may be supported or
214 unsupported by the client resolving the URL. An extension prefixed
215 with a '!' character (ASCII 0x21) is critical. An extension not
216 prefixed with a '!' character is non-critical.
218 If an LDAP URL extension is implemented (that is, if the
219 implementation understands it and is able to use it), the
223 Smith & Howes Intended Category: Standards Track [Page 4]
225 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
228 implementation MUST make use of it. If an extension is not
229 implemented and is marked critical, the implementation MUST NOT
230 process the URL. If an extension is not implemented and it not
231 marked critical, the implementation MUST ignore the extension.
233 The extension type (<extype>) MAY be specified using the numeric OID
234 <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
235 (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be
236 restricted to registered object identifier descriptive names. See
237 [LDAPIANA] for registration details and usage guidelines for
240 No LDAP URL extensions are defined in this document. Other documents
241 or a future version of this document MAY define one or more
244 2.1. Percent-Encoding
246 A generated LDAP URL MUST consist only of the restricted set of
247 characters included in one of the following three productions defined
254 Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
255 input. An octet MUST be encoded using the percent-encoding mechanism
256 described in section 2.1 of [RFC2396bis] in any of these situations:
258 The octet is not in the reserved set defined in section 2.2 of
259 [RFC2396bis] or in the unreserved set defined in section 2.3 of
262 It is the single Reserved character '?' and occurs inside a <dn>,
263 <filter>, or other element of an LDAP URL.
265 It is a comma character ',' that occurs inside an <exvalue>.
267 Note that before the percent-encoding mechanism is applied, the
268 extensions component of the LDAP URL may contain one or more null
269 (zero) bytes. No other component may.
271 3. Defaults for Fields of the LDAP URL
273 Some fields of the LDAP URL are optional, as described above. In the
274 absence of any other specification, the following general defaults
275 SHOULD be used when a field is absent. Note that other documents MAY
279 Smith & Howes Intended Category: Standards Track [Page 5]
281 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
284 specify different defaulting rules; for example, section 4.1.10 of
285 [Protocol] specifies a different rule for determining the correct DN
286 to use when it is absent in an LDAP URL that is returned as a
290 If no <host> is given, the client must have some apriori knowledge
291 of an appropriate LDAP server to contact.
294 The default LDAP port is TCP port 389.
297 If no <dn> is given, the default is the zero-length DN, "".
300 If the <attributes> part is omitted, all user attributes of the
301 entry or entries should be requested (e.g., by setting the
302 attributes field AttributeDescriptionList in the LDAP search
303 request to a NULL list, or by using the special <alluserattrs>
307 If <scope> is omitted, a <scope> of "base" is assumed.
310 If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
313 If <extensions> is omitted, no extensions are assumed.
318 The following are some example LDAP URLs using the format defined
319 above. The first example is an LDAP URL referring to the University
320 of Michigan entry, available from an LDAP server of the client's
323 ldap:///o=University%20of%20Michigan,c=US
325 The next example is an LDAP URL referring to the University of
326 Michigan entry in a particular ldap server:
328 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
330 Both of these URLs correspond to a base object search of the
331 "o=University of Michigan,c=US" entry using a filter of
335 Smith & Howes Intended Category: Standards Track [Page 6]
337 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
340 "(objectclass=*)", requesting all attributes.
342 The next example is an LDAP URL referring to only the postalAddress
343 attribute of the University of Michigan entry:
345 ldap://ldap1.example.net/o=University%20of%20Michigan,
348 The corresponding LDAP search operation is the same as in the
349 previous example, except that only the postalAddress attribute is
352 The next example is an LDAP URL referring to the set of entries found
353 by querying the given LDAP server on port 6666 and doing a subtree
354 search of the University of Michigan for any entry with a common name
355 of "Babs Jensen", retrieving all attributes:
357 ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
358 c=US??sub?(cn=Babs%20Jensen)
360 The next example is an LDAP URL referring to all children of the c=GB
363 LDAP://ldap1.example.com/c=GB?objectClass?ONE
365 The objectClass attribute is requested to be returned along with the
366 entries, and the default filter of "(objectclass=*)" is used.
368 The next example is an LDAP URL to retrieve the mail attribute for
369 the LDAP entry named "o=Question?,c=US" is given below, illustrating
370 the use of the percent-encoding mechanism on the reserved character
373 ldap://ldap2.example.com/o=Question%3f,c=US?mail
375 The next example (which is broken into two lines for readability)
376 illustrates the interaction between the LDAP string representation of
377 filters quoting mechanism and URL quoting mechanisms.
379 ldap://ldap3.example.com/o=Babsco,c=US
380 ???(four-octet=%5c00%5c00%5c00%5c04)
382 The filter in this example uses the LDAP escaping mechanism of \ to
383 encode three zero or null bytes in the value. In LDAP, the filter
384 would be written as (four-octet=\00\00\00\04). Because the \
385 character must be escaped in a URL, the \'s are percent-encoded as
386 %5c (or %5C) in the URL encoding.
391 Smith & Howes Intended Category: Standards Track [Page 7]
393 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
396 The next example illustrates the interaction between the LDAP string
397 representation of DNs quoting mechanism and URL quoting mechanisms.
399 ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
401 The DN encoded in the above URL is:
403 o=An Example\2C Inc.,c=US
405 That is, the left-most RDN value is:
409 The following three URLs that are equivalent, assuming that the
410 defaulting rules specified in section 4 of this document are used:
412 ldap://ldap.example.net
413 ldap://ldap.example.net/
414 ldap://ldap.example.net/?
416 These three URLs all point to the root DSE on the ldap.example.net
419 The final two examples show use of a hypothetical, experimental bind
420 name extension (the value associated with the extension is an LDAP DN).
422 ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
423 ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
425 The two URLs are the same, except that the second one marks the
426 e-bindname extension as critical. Notice the use of the
427 percent-encoding mechanism to encode the commas within the
428 distinguished name value in the e-bindname extension.
431 5. Security Considerations
433 General URL security considerations discussed in [RFC2396bis] are
434 relevant for LDAP URLs.
436 The use of security mechanisms when processing LDAP URLs requires
437 particular care, since clients may encounter many different servers
438 via URLs, and since URLs are likely to be processed automatically,
439 without user intervention. A client SHOULD have a user-configurable
440 policy that controls which servers the client will establish LDAP
441 sessions with using which security mechanisms, and SHOULD NOT
442 establish LDAP sessions that are inconsistent with this policy. If a
443 client chooses to reuse an existing LDAP session when resolving one
447 Smith & Howes Intended Category: Standards Track [Page 8]
449 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
452 or more LDAP URLs, it MUST ensure that the session is compatible with
453 the URL and that no security policies are violated.
455 Sending authentication information, no matter the mechanism, may
456 violate a user's privacy requirements. In the absence of specific
457 policy permitting authentication information to be sent to a server,
458 a client should use an anonymous LDAP session. (Note that clients
459 conforming to previous LDAP URL specifications, where all LDAP
460 sessions are anonymous and unprotected, are consistent with this
461 specification; they simply have the default security policy.) Simply
462 opening a transport connection to another server may violate some
463 users' privacy requirements, so clients should provide the user with
464 a way to control URL processing.
466 Some authentication methods, in particular reusable passwords sent to
467 the server, may reveal easily-abused information to the remote server
468 or to eavesdroppers in transit, and should not be used in URL
469 processing unless explicitly permitted by policy. Confirmation by
470 the human user of the use of authentication information is
471 appropriate in many circumstances. Use of strong authentication
472 methods that do not reveal sensitive information is much preferred.
473 If the URL represents a referral for an update operation, strong
474 authentication methods SHOULD be used. Please refer to the Security
475 Considerations section of [AuthMeth] for more information.
477 The LDAP URL format allows the specification of an arbitrary LDAP
478 search operation to be performed when evaluating the LDAP URL.
479 Following an LDAP URL may cause unexpected results, for example, the
480 retrieval of large amounts of data, the initiation of a long-lived
481 search, etc. The security implications of resolving an LDAP URL are
482 the same as those of resolving an LDAP search query.
484 6. IANA Considerations
486 This document has no actions for IANA.
488 7. Normative References
490 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
491 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a
494 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
495 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
498 [Filters] Smith, M. and Howes, T., "LDAP: String Representation of
499 Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
503 Smith & Howes Intended Category: Standards Track [Page 9]
505 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
510 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
511 Requirement Levels," RFC 2119, BCP 14, March 1997.
513 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
514 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
516 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
517 Specifications: ABNF", RFC 2234, November 1997.
520 Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform
521 Resource Identifiers (URI): Generic Syntax",
522 draft-fielding-uri-rfc2396bis-xx.txt, a work in progress.
524 [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
525 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
527 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
528 RFC 3629, November 2003.
530 8. Informative References
532 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
533 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. None.
537 The LDAP URL format was originally defined at the University of
538 Michigan. This material is based upon work supported by the National
539 Science Foundation under Grant No. NCR-9416667. The support of both
540 the University of Michigan and the National Science Foundation is
541 gratefully acknowledged.
543 This document is an update to RFC 2255 by Tim Howes and Mark Smith.
544 Changes included in this revised specification are based upon
545 discussions among the authors, discussions within the LDAP (v3)
546 Revision Working Group (ldapbis), and discussions within other IETF
547 Working Groups. The contributions of individuals in these working
548 groups is gratefully acknowledged. Several people in particular have
549 made valuable comments on this document; RL "Bob" Morgan, Mark Wahl,
550 Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
551 thanks for their contributions.
559 Smith & Howes Intended Category: Standards Track [Page 10]
561 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
564 10. Authors' Addresses
572 mcs@pearlcrescent.com
582 11. Appendix A: Changes Since RFC 2255
584 11.1. Technical Changes
586 The following technical changes were made to the contents of the "URL
589 Revised all of the ABNF to use common productions from [Models].
591 Replaced references to [RFC2396] with a reference to [RFC2396bis]
592 (this allows literal IPv6 addresses to be used inside the <host>
593 portion of the URL, and a note was added to remind the reader of this
594 enhancement). Referencing [RFC2396bis] required changes to the ABNF
595 and text so that productions that are no longer defined by
596 [RFC2396bis] are not used. For example, <hostport> is not defined by
597 [RFC2396bis] so it has been replaced with host [COLON port]. Note:
598 [RFC2396bis] includes new definitions for the "Reserved" and
599 "Unreserved" sets of characters, and the net result is that the
600 following two additional characters should be percent-encoded when
601 they appear anywhere in the data used to construct an LDAP URL: "["
602 and "]" (these two characters were first added to the Reserved set by
605 Changed the definition of <attrdesc> to refer to <attributeSelector>
606 from [Protocol]. This allows use of "*" in the <attrdesc> part of
607 the URL. It is believed that existing implementations of RFC 2255
608 already support this.
610 Avoided use of <prose-val> (bracketed-string) productions in the
611 <dn>, <host>, <attrdesc>, and <exvalue> rules.
615 Smith & Howes Intended Category: Standards Track [Page 11]
617 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
620 Changed the ABNF for <ldapurl> to group the <dn> component with the
623 Changed the <extype> rule to be an <oid> from [Models].
625 Changed the text about extension types so it references [LDAPIANA].
626 Reordered rules to more closely follow the order the elements appear
629 "Bindname Extension": removed due to lack of known implementations.
632 11.2. Editorial Changes
634 Changed document title to include "LDAP:" prefix.
636 IESG Note: removed note about lack of satisfactory mandatory
637 authentication mechanisms.
639 "Status of this Memo" section: updated boilerplate to match current
642 "Abstract" section: separated from introductory material.
644 "Table of Contents" and "IANA Considerations" sections: added.
646 "Introduction" section: new section; separated from the Abstract.
647 Changed the text indicate that RFC 2255 is replaced by this document
648 (instead of RFC 1959). Added text to indicate that LDAP URLs are
649 used for references and referrals. Fixed typo (replaced the nonsense
650 phrase "to perform to retrieve" with "used to retrieve"). Added a
651 note to let the reader know that not all of the parameters of the
652 LDAP search operation described in [Protocol] can be expressed using
655 "URL Definition" section: removed second copy of <ldapurl> grammar
656 and following two paragraphs (editorial error in RFC 2255). Fixed
657 line break within '!' sequence. Reformatted the ABNF to improve
658 readability by aligning comments and adding some blank lines.
659 Replaced "residing in the LDAP server" with "accessible from the LDAP
660 server" in the sentence immediately following the ABNF. Removed the
661 sentence "Individual attrdesc names are as defined for
662 AttributeDescription in [Protocol]." because [Protocol]'s
663 <attributeSelector> is now used directly in the ABNF. Reworded last
664 paragraph to clarify which characters must be percent-encoded. Added
665 text to indicate that LDAP URLs are used for references and
666 referrals. Added text that refers to the ABNF from RFC 2234.
667 Clarified and strengthened the requirements with respect to
671 Smith & Howes Intended Category: Standards Track [Page 12]
673 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
676 processing of URLs that contain implements and not implemented
677 extensions (the approach now closely matches that specified in
678 [Protocol] for LDAP controls).
680 "Defaults for Fields of the LDAP URL" section: added; formed by
681 moving text about defaults out of the "URL Definition" section.
682 Replaced direct reference to the attribute name "*" with a reference
683 to the special <alluserattrs> selector "*" defined in [Protocol].
685 "URL Processing" section: removed.
687 "Examples" section: Modified examples to use example.com and
688 example.net hostnames. Added missing '?' to the LDAP URL example
689 whose filter contains three null bytes. Removed space after one
690 comma within a DN. Revised the bindname example to use e-bindname.
691 Changed the name of an attribute used in one example from "int" to
692 "four-octet" to avoid potential confusion. Added an example that
693 demonstrates the interaction between DN escaping and URL
694 percent-encoding. Added some examples to show URL equivalence with
695 respect to the <dn> portion of the URL. Used uppercase in some
696 examples to remind the reader that some tokens are case-insensitive.
698 "Security Considerations" section: Added a note about connection
699 reuse. Added a note about using strong authentication methods for
700 updates. Added a reference to [AuthMeth]. Added note that simply
701 opening a connection may violate some users' privacy requirements.
702 Adopted the working group's revised LDAP terminology specification by
703 replacing the word "connection" with "LDAP session" or "LDAP
704 connection" as appropriate.
706 "Acknowledgements" section: added statement about this being an
707 update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
710 "Normative References" section: renamed from "References" per new RFC
711 guidelines. Changed from [1] style to [Protocol] style throughout the
712 document. Added references to RFC 2234 and RFC 3629. Updated all
713 RFC 1738 references to point to the appropriate sections within
714 [RFC2396bis]. Updated the LDAP references to refer to LDAPBis WG
715 documents. Removed the reference to the LDAP Attribute Syntaxes
716 document and added references to the [AuthMeth], [LDAPIANA], and
719 "Informative References" section: added.
721 Header and "Authors' Addresses" sections: added "editor" next to Mark
722 Smith's name. Updated affiliation and contact information.
727 Smith & Howes Intended Category: Standards Track [Page 13]
729 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
732 Copyright: updated the year.
734 Throughout the document: surrounded the names of all ABNF productions
735 with "<" and ">" where they are used in descriptive text.
739 12. Appendix B: Changes Since Previous Document Revision
741 This appendix lists all changes relative to the previously published
742 revision, draft-ietf-ldapbis-url-08.txt. Note that when appropriate
743 these changes are also included in Appendix A, but are also included
744 here for the benefit of the people who have already reviewed
745 draft-ietf-ldapbis-url-08.txt. This section will be removed before
746 this document is published as an RFC.
748 12.1. Technical Changes
750 Throughout the document: Replaced references to [RFC2396] and
751 [RFC2732] with references to [RFC2396bis]. This required changes to
752 the ABNF and text so that productions that are no longer defined by
753 [RFC2396bis] are not used. For example, <hostport> is not defined by
754 [RFC2396bis] so it has been replaced with host [COLON port]. Note:
755 [RFC2396bis] includes new definitions for the "Reserved" and
756 "Unreserved" sets of characters, and the net result is that the
757 following two additional characters should be percent-encoded when
758 they appear anywhere in the data used to construct an LDAP URL: "["
759 and "]" (these two characters were first added to the Reserved set by
762 12.2. Editorial Changes
764 Throughout the document: Replaced phrases like "Escaping using the %
765 method" with "Percent-encoding" to be consistent with the terminology
766 used in [RFC2396bis].
768 "URL Definition" section: For consistency, replaced all occurrences
769 of the phrase 'see the "Percent-Encoding" section below' with
770 'subject to the provisions of the "Percent-Encoding" section below.'
772 Updated the copyright year to 2005.
775 Intellectual Property Rights
777 The IETF takes no position regarding the validity or scope of any
778 Intellectual Property Rights or other rights that might be claimed to
779 pertain to the implementation or use of the technology described in
783 Smith & Howes Intended Category: Standards Track [Page 14]
785 INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
788 this document or the extent to which any license under such rights
789 might or might not be available; nor does it represent that it has
790 made any independent effort to identify any such rights. Information
791 on the procedures with respect to rights in RFC documents can be
792 found in BCP 78 and BCP 79.
794 Copies of IPR disclosures made to the IETF Secretariat and any
795 assurances of licenses to be made available, or the result of an
796 attempt made to obtain a general license or permission for the use of
797 such proprietary rights by implementers or users of this
798 specification can be obtained from the IETF on-line IPR repository at
799 http://www.ietf.org/ipr.
801 The IETF invites any interested party to bring to its attention any
802 copyrights, patents or patent applications, or other proprietary
803 rights that may cover technology that may be required to implement
804 this standard. Please address the information to the IETF at
809 Copyright (C) The Internet Society (2005). This document is subject
810 to the rights, licenses and restrictions contained in BCP 78, and
811 except as set forth therein, the authors retain all their rights.
813 This document and the information contained herein are provided on an
814 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
815 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
816 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
817 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
818 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
819 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
821 This Internet Draft expires on 4 July 2005.
839 Smith & Howes Intended Category: Standards Track [Page 15]