2 Network Working Group Mark Smith, Editor
3 Request for Comments: DRAFT Pearl Crescent, LLC
4 Obsoletes: RFC 2255 Tim Howes
5 Expires: 24 April 2005 Opsware, Inc.
10 LDAP: Uniform Resource Locator
11 <draft-ietf-ldapbis-url-07.txt>
17 By submitting this Internet-Draft, each author represents that any
18 applicable patent or other IPR claims of which he or she is aware
19 have been or will be disclosed, and any of which he or she become
20 aware will be disclosed, in accordance with RFC 3668.
22 This document is intended to be published as a Standards Track RFC,
23 replacing RFC 2255. Distribution of this memo is unlimited.
24 Technical discussion of this document will take place on the IETF
25 LDAP (v3) Revision (ldapbis) Working Group mailing list
26 <ietf-ldapbis@openldap.org>. Please send editorial comments directly
27 to the editor <mcs@pearlcrescent.com>.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF), its areas, and its working groups. Note that
31 other groups may also distribute working documents as
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than a "work in progress."
39 The list of current Internet-Drafts can be accessed at
40 http://www.ietf.org/1id-abstracts.html
42 The list of Internet-Draft Shadow Directories can be accessed at
43 http://www.ietf.org/shadow.html
45 Copyright (C) The Internet Society (2004). All Rights Reserved.
46 Please see the Full Copyright section near the end of this document
53 Smith & Howes Intended Category: Standards Track [Page 1]
55 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
60 This document describes a format for an LDAP Uniform Resource Locator
61 (URL). An LDAP URL describes an LDAP search operation that is used
62 to retrieve information from an LDAP directory, or, in the context of
63 an LDAPv3 referral or reference, an LDAP URL describes a service
64 where an LDAP operation may be progressed.
68 Status of this Memo............................................1
69 Abstract.......................................................2
70 Table of Contents..............................................2
71 1. Introduction...................................................2
72 2. URL Definition.................................................3
73 2.1. Escaping Using the % Method.................................5
74 3. Defaults for Fields of the LDAP URL............................5
75 4. Examples.......................................................6
76 5. Security Considerations........................................8
77 6. IANA Considerations............................................9
78 7. Normative References...........................................9
79 8. Informative References.........................................10
80 9. Intellectual Property Rights...................................10
81 10. Acknowledgements...............................................10
82 11. Authors' Addresses.............................................11
83 12. Appendix A: Changes Since RFC 2255.............................11
84 12.1. Technical Changes...........................................11
85 12.2. Editorial Changes...........................................12
86 13. Appendix B: Changes Since Previous Document Revision...........13
87 13.1. Editorial Changes...........................................14
88 14. Intellectual Property Rights...................................14
89 15. Full Copyright.................................................14
93 LDAP is the Lightweight Directory Access Protocol, defined in
94 [Protocol]. This document specifies the LDAP URL format for version
95 3 of LDAP and clarifies how LDAP URLs are resolved. This document
96 also defines an extension mechanism for LDAP URLs, so that future
97 documents can extend their functionality, for example, to provide
98 access to new LDAPv3 extensions as they are defined. Note: not all
99 of the parameters of the LDAP search operation described in
100 [Protocol] can be expressed using the format defined in this
103 This document is an integral part of the LDAP Technical Specification
109 Smith & Howes Intended Category: Standards Track [Page 2]
111 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
114 This document replaces RFC 2255. See Appendix A for a list of changes
115 relative to RFC 2255.
117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
119 document are to be interpreted as described in BCP 14 [RFC2119].
123 An LDAP URL begins with the protocol prefix "ldap" and is defined by
124 the following grammar, following the ABNF notation defined in
127 ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn
128 [QUESTION [attributes] [QUESTION [scope]
129 [QUESTION [filter] [QUESTION extensions]]]]]
131 hostport = <hostport from Section 3.2.2 of [RFC2396]>
132 ; As updated by [RFC2732] to allow
133 ; IPv6 literal addresses
134 dn = <distinguishedName from Section 3 of [LDAPDN]>
135 ; See the "Escaping Using the % Method"
137 attributes = attrdesc *(COMMA attrdesc)
138 attrdesc = <AttributeDescription
139 from Section 4.1.4 of [Protocol]>
141 ; See the "Escaping Using the % Method"
143 scope = "base" / "one" / "sub"
144 filter = <filter from Section 4 of [Filters]>
145 ; See the "Escaping Using the % Method"
147 extensions = extension *(COMMA extension)
148 extension = [EXCLAMATION] extype [EQUALS exvalue]
149 extype = oid / oiddescr
150 exvalue = <LDAPString from section 4.1.2 of [Protocol]>
151 ; See the "Escaping Using the % Method"
153 oid = <LDAPOID from section 4.1.2 of [Protocol]>
154 oiddescr = <name from section 3.3 of [LDAPIANA]>
156 EXCLAMATION = %x21 ; exclamation mark ("!")
157 ASTERISK = %x2A ; asterisk ("*")
158 SLASH = %x2F ; forward slash ("/")
159 COLON = %x3A ; colon (":")
160 QUESTION = %x3F ; question mark ("?")
165 Smith & Howes Intended Category: Standards Track [Page 3]
167 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
170 The "ldap" prefix indicates an entry or entries accessible from the
171 LDAP server running on the given hostname at the given portnumber.
172 Note that the hostport may contain literal IPv6 addresses as
173 specified in [RFC2732].
175 The dn is an LDAP Distinguished Name using the string format
176 described in [LDAPDN]. It identifies the base object of the LDAP
177 search or the target of a non-search operation.
179 The attributes construct is used to indicate which attributes should
180 be returned from the entry or entries. Individual attrdesc names are
181 as defined for AttributeDescription in [Protocol].
183 The scope construct is used to specify the scope of the search to
184 perform in the given LDAP server. The allowable scopes are "base"
185 for a base object search, "one" for a one-level search, or "sub" for
188 The filter is used to specify the search filter to apply to entries
189 within the specified scope during the search. It has the format
190 specified in [Filters].
192 The extensions construct provides the LDAP URL with an extensibility
193 mechanism, allowing the capabilities of the URL to be extended in the
194 future. Extensions are a simple comma-separated list of type=value
195 pairs, where the =value portion MAY be omitted for options not
196 requiring it. Each type=value pair is a separate extension. These
197 LDAP URL extensions are not necessarily related to any of the LDAPv3
198 extension mechanisms. Extensions may be supported or unsupported by
199 the client resolving the URL. An extension prefixed with a '!'
200 character (ASCII 0x21) is critical. An extension not prefixed with a
201 '!' character is non-critical.
203 If an LDAP URL extension is implemented (that is, if the
204 implementation understands it and is able to use it), the
205 implementation MUST make use of it. If an extension is not
206 implemented and is marked critical, the implementation MUST NOT
207 process the URL. If an extension is not implemented and it not
208 marked critical, the implementation MUST ignore the extension.
210 The extension type (extype) MAY be specified using the oid form
211 (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use
212 of the oiddesc form SHOULD be restricted to registered object
213 identifier descriptive names. See [LDAPIANA] for registration
214 details and usage guidelines for descriptive names.
216 No LDAP URL extensions are defined in this document. Other documents
217 or a future version of this document MAY define one or more
221 Smith & Howes Intended Category: Standards Track [Page 4]
223 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
228 2.1. Escaping Using the % Method
230 A generated LDAP URL MUST consist only of the restricted set of
231 characters included in the uric production that is defined in section
232 2 of [RFC2396]. Implementations SHOULD accept other valid UTF-8
233 strings [RFC3629] as input. An octet MUST be escaped using the %
234 method described in section 2.4 of [RFC2396] in any of these
237 The octet is not in the reserved set defined in section 2.2 of
238 [RFC2396] or in the unreserved set defined in section 2.3 of
241 It is the single Reserved character '?' and occurs inside a dn,
242 filter, or other element of an LDAP URL.
244 It is a comma character ',' that occurs inside an extension value.
246 Note that before the % method of escaping is applied, the extensions
247 component of the LDAP URL may contain one or more null (zero) bytes.
248 No other component may.
250 3. Defaults for Fields of the LDAP URL
252 Some fields of the LDAP URL are optional, as described above. In the
253 absence of any other specification, the following general defaults
254 SHOULD be used when a field is absent. Note: other documents MAY
255 specify different defaulting rules; for example, section 4.1.10 of
256 [Protocol] specifies a different rule for determining the correct DN
257 to use when it is absent in an LDAP URL that is returned as a
261 The default LDAP port is TCP port 389. If no hostport is given,
262 the client must have some apriori knowledge of an appropriate LDAP
266 If no dn is given, the default is the zero-length DN, "".
269 If the attributes part is omitted, all user attributes of the
270 entry or entries should be requested (e.g., by setting the
271 attributes field AttributeDescriptionList in the LDAP search
272 request to a NULL list, or (in LDAPv3) by requesting the special
277 Smith & Howes Intended Category: Standards Track [Page 5]
279 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
283 If scope is omitted, a scope of "base" is assumed.
286 If filter is omitted, a filter of "(objectClass=*)" is assumed.
289 If extensions is omitted, no extensions are assumed.
294 The following are some example LDAP URLs using the format defined
295 above. The first example is an LDAP URL referring to the University
296 of Michigan entry, available from an LDAP server of the client's
299 ldap:///o=University%20of%20Michigan,c=US
301 The next example is an LDAP URL referring to the University of
302 Michigan entry in a particular ldap server:
304 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
306 Both of these URLs correspond to a base object search of the
307 "o=University of Michigan,c=US" entry using a filter of
308 "(objectclass=*)", requesting all attributes.
310 The next example is an LDAP URL referring to only the postalAddress
311 attribute of the University of Michigan entry:
313 ldap://ldap1.example.net/o=University%20of%20Michigan,
316 The corresponding LDAP search operation is the same as in the
317 previous example, except that only the postalAddress attribute is
320 The next example is an LDAP URL referring to the set of entries found
321 by querying the given LDAP server on port 6666 and doing a subtree
322 search of the University of Michigan for any entry with a common name
323 of "Babs Jensen", retrieving all attributes:
325 ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
326 c=US??sub?(cn=Babs%20Jensen)
328 The next example is an LDAP URL referring to all children of the c=GB
333 Smith & Howes Intended Category: Standards Track [Page 6]
335 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
338 ldap://ldap1.example.com/c=GB?objectClass?one
340 The objectClass attribute is requested to be returned along with the
341 entries, and the default filter of "(objectclass=*)" is used.
343 The next example is an LDAP URL to retrieve the mail attribute for
344 the LDAP entry named "o=Question?,c=US" is given below, illustrating
345 the use of the escaping mechanism on the reserved character '?'.
347 ldap://ldap2.example.com/o=Question%3f,c=US?mail
349 The next example (which is broken into two lines for readability)
350 illustrates the interaction between the LDAP string representation of
351 filters quoting mechanism and URL quoting mechanisms.
353 ldap://ldap3.example.com/o=Babsco,c=US
354 ???(four-octet=%5c00%5c00%5c00%5c04)
356 The filter in this example uses the LDAP escaping mechanism of \ to
357 encode three zero or null bytes in the value. In LDAP, the filter
358 would be written as (four-octet=\00\00\00\04). Because the \
359 character must be escaped in a URL, the \'s are escaped as %5c in the
362 The next example illustrates the interaction between the LDAP string
363 representation of DNs quoting mechanism and URL quoting mechanisms.
365 ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US
367 The DN encoded in the above URL is:
369 o=An Example\2c Inc.,c=US
371 That is, the left-most RDN value is:
375 The following three URLs that are equivalent, assuming that the
376 defaulting rules specified in section 4 of this document are used:
378 ldap://ldap.example.net
379 ldap://ldap.example.net/
380 ldap://ldap.example.net/?
382 These three URLs all point to the root DSE on the ldap.example.net
389 Smith & Howes Intended Category: Standards Track [Page 7]
391 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
394 The final two examples show use of a hypothetical, experimental bind
395 name extension (the value associated with the extension is an LDAP DN).
397 ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
398 ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
400 The two URLs are the same, except that the second one marks the
401 e-bindname extension as critical. Notice the use of the % encoding
402 method to encode the commas within the distinguished name value in
403 the e-bindname extension.
406 5. Security Considerations
408 General URL security considerations discussed in [RFC2396] are
409 relevant for LDAP URLs.
411 The use of security mechanisms when processing LDAP URLs requires
412 particular care, since clients may encounter many different servers
413 via URLs, and since URLs are likely to be processed automatically,
414 without user intervention. A client SHOULD have a user-configurable
415 policy about which servers to connect to using which security
416 mechanisms, and SHOULD NOT make connections that are inconsistent
417 with this policy. If a client chooses to reuse an existing
418 connection when resolving one or more LDAP URL, it MUST ensure that
419 the connection is compatible with the URL and that no security
420 policies are violated.
422 Sending authentication information, no matter the mechanism, may
423 violate a user's privacy requirements. In the absence of specific
424 policy permitting authentication information to be sent to a server,
425 a client should use an anonymous connection. (Note that clients
426 conforming to previous LDAP URL specifications, where all connections
427 are anonymous and unprotected, are consistent with this
428 specification; they simply have the default security policy.) Simply
429 opening a connection to another server may violate some users'
430 privacy requirements, so clients should provide the user with a way
431 to control URL processing.
433 Some authentication methods, in particular reusable passwords sent to
434 the server, may reveal easily-abused information to the remote server
435 or to eavesdroppers in transit, and should not be used in URL
436 processing unless explicitly permitted by policy. Confirmation by
437 the human user of the use of authentication information is
438 appropriate in many circumstances. Use of strong authentication
439 methods that do not reveal sensitive information is much preferred.
440 If the URL represents a referral for an update operation, strong
441 authentication methods SHOULD be used. Please refer to the Security
445 Smith & Howes Intended Category: Standards Track [Page 8]
447 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
450 Considerations section of [AuthMeth] for more information.
452 The LDAP URL format allows the specification of an arbitrary LDAP
453 search operation to be performed when evaluating the LDAP URL.
454 Following an LDAP URL may cause unexpected results, for example, the
455 retrieval of large amounts of data, the initiation of a long-lived
456 search, etc. The security implications of resolving an LDAP URL are
457 the same as those of resolving an LDAP search query.
459 6. IANA Considerations
461 This document has no actions for IANA.
463 7. Normative References
465 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
466 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a
469 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
470 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
473 [Filters] Smith, M. and Howes, T., "LDAP: String Representation of
474 Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
477 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
478 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
480 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
481 Requirement Levels," RFC 2119, BCP 14, March 1997.
483 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
484 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
486 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
487 Specifications: ABNF", RFC 2234, November 1997.
489 [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
490 Resource Identifiers (URI): Generic Syntax", RFC 2396,
493 [RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Literal
494 IPv6 Addresses in URL's", RFC 2732, December 1999.
496 [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
497 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
501 Smith & Howes Intended Category: Standards Track [Page 9]
503 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
506 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
507 RFC 3629, November 2003.
509 8. Informative References
513 9. Intellectual Property Rights
515 The IETF takes no position regarding the validity or scope of any
516 intellectual property or other rights that might be claimed to
517 pertain to the implementation or use of the technology described in
518 this document or the extent to which any license under such rights
519 might or might not be available; neither does it represent that it
520 has made any effort to identify any such rights. Information on the
521 IETF's procedures with respect to rights in standards-track and
522 standards-related documentation can be found in BCP-11. Copies of
523 claims of rights made available for publication and any assurances of
524 licenses to be made available, or the result of an attempt made to
525 obtain a general license or permission for the use of such
526 proprietary rights by implementors or users of this specification can
527 be obtained from the IETF Secretariat.
529 The IETF invites any interested party to bring to its attention any
530 copyrights, patents or patent applications, or other proprietary
531 rights which may cover technology that may be required to practice
532 this standard. Please address the information to the IETF Executive
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.
557 Smith & Howes Intended Category: Standards Track [Page 10]
559 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
562 11. Authors' Addresses
570 mcs@pearlcrescent.com
580 12. Appendix A: Changes Since RFC 2255
582 12.1. Technical Changes
584 The following technical changes were made to the contents of the "URL
587 Revised all of the ABNF to use common productions from [Models].
589 Added note and references to [RFC2732] to allow literal IPv6
590 addresses inside the hostport portion of the URL.
592 Added missing ASTERISK as an alternative for the attrdesc part of the
593 URL. It is believed that existing implementations of RFC 2255
594 already support this.
596 Added angle brackets around free-form prose in the "dn", "hostport",
597 "attrdesc", "filter", and "exvalue" rules.
599 Changed the ABNF for ldapurl to group the dn component with the
602 Changed the extype rule to be an LDAPOID from [Protocol] or an OID
603 description from [LDAPIANA].
605 Changed the text about extension types so it references [LDAPIANA].
606 Reordered rules to more closely follow the order the elements appear
613 Smith & Howes Intended Category: Standards Track [Page 11]
615 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
618 "Bindname Extension": removed due to lack of known implementations.
621 12.2. Editorial Changes
623 Changed document title to include "LDAP:" prefix.
625 IESG Note: removed note about lack of satisfactory mandatory
626 authentication mechanisms.
628 "Status of this Memo" section: updated boilerplate to match current
631 "Abstract" section: separated from introductory material.
633 "Table of Contents" and "IANA Considerations" sections: added.
635 "Introduction" section: new section; separated from the Abstract.
636 Changed the text indicate that RFC 2255 is replaced by this document
637 (instead of RFC 1959). Added text to indicate that LDAP URLs are
638 used for references and referrals. Fixed typo (replaced the nonsense
639 phrase "to perform to retrieve" with "used to retrieve"). Added a
640 note to let the reader know that not all of the parameters of the
641 LDAP search operation described in [Protocol] can be expressed using
644 "URL Definition" section: removed second copy of ldapurl grammar and
645 following two paragraphs (editorial error in RFC 2255). Fixed line
646 break within '!' sequence. Replaced "residing in the LDAP server"
647 with "accessible from the LDAP server" in the sentence immediately
648 following the ABNF. Reworded last paragraph to clarify which
649 characters must be URL escaped. Added text to indicate that LDAP
650 URLs are used for references and referrals. Added text that refers
651 to the ABNF from RFC 2234. Clarified and strengthened the
652 requirements with respect to processing of URLs that contain
653 implements and not implemented extensions (the approach now closely
654 matches that specified in [Protocol] for LDAP controls).
656 "Defaults for Fields of the LDAP URL" section: added; formed by
657 moving text about defaults out of the "URL Definition" section.
659 "URL Processing" section: clarified that connections MAY be reused
660 only if the open connection is compatible with the URL. Added text
661 to indicate that use of security services is encouraged and that they
662 SHOULD be used when updates are involved. Removed "dn" from
663 discussion of authentication methods. Added note that the client MAY
664 interrogate the server to determine the most appropriate method.
669 Smith & Howes Intended Category: Standards Track [Page 12]
671 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
674 "Examples" section: Modified examples to use example.com and
675 example.net hostnames. Added missing '?' to the LDAP URL example
676 whose filter contains three null bytes. Removed space after one
677 comma within a DN. Revised the bindname example to use e-bindname.
678 Changed the name of an attribute used in one example from "int" to
679 "four-octet" to avoid potential confusion. Added an example that
680 demonstrates the interaction between DN escaping and URL escaping.
681 Added some examples to show URL equivalence with respect to the dn
684 "Security Considerations" section: Added a note about connection
685 reuse. Added a note about using strong authentication methods for
686 updates. Added a reference to [AuthMeth]. Added note that simply
687 opening a connection may violate some users' privacy requirements.
689 "Acknowledgements" section: added statement about this being an
690 update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
693 "Normative References" section: renamed from "References" per new RFC
694 guidelines. Changed from [1] style to [Protocol] style throughout the
695 document. Added references to RFC 2234, RFC 2732, and RFC 3629.
696 Updated all RFC 1738 references to point to the appropriate sections
697 within RFC 2396. Updated the LDAP references to refer to LDAPBis WG
698 documents. Removed the reference to the LDAP Attribute Syntaxes
699 document and added references to the [AuthMeth], [LDAPIANA], and
702 "Informative References" section: added for clarity.
704 Header and "Authors' Addresses" sections: added "editor" next to Mark
705 Smith's name. Updated affiliation and contact information.
707 Copyright: updated the year.
710 13. Appendix B: Changes Since Previous Document Revision
712 This appendix lists all changes relative to the previously published
713 revision, draft-ietf-ldapbis-url-06.txt. Note that when appropriate
714 these changes are also included in Appendix A, but are also included
715 here for the benefit of the people who have already reviewed
716 draft-ietf-ldapbis-url-06.txt. This section will be removed before
717 this document is published as an RFC.
725 Smith & Howes Intended Category: Standards Track [Page 13]
727 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
730 13.1. Editorial Changes
732 "Status of this Memo" section: replaced RFC 3668 (IPR) boilerplate
733 paragraph with the version that says "each author" instead of "I."
735 "URL Definition" section: replaced phrases such as "recognized by"
736 with "implemented by" when referring to LDAP URL extensions.
738 "URL Definition" section: added the following two sentences at the
739 end of the subsection on "Escaping Using the % Method":
740 Note that before the % method of escaping is applied, the
741 extensions component of the LDAP URL may contain one or more null
742 (zero) bytes. No other component may.
744 14. Intellectual Property Rights
746 The IETF takes no position regarding the validity or scope of any
747 Intellectual Property Rights or other rights that might be claimed to
748 pertain to the implementation or use of the technology described in
749 this document or the extent to which any license under such rights
750 might or might not be available; nor does it represent that it has
751 made any independent effort to identify any such rights. Information
752 on the procedures with respect to rights in RFC documents can be
753 found in BCP 78 and BCP 79.
755 Copies of IPR disclosures made to the IETF Secretariat and any
756 assurances of licenses to be made available, or the result of an
757 attempt made to obtain a general license or permission for the use of
758 such proprietary rights by implementers or users of this
759 specification can be obtained from the IETF on-line IPR repository at
760 http://www.ietf.org/ipr.
762 The IETF invites any interested party to bring to its attention any
763 copyrights, patents or patent applications, or other proprietary
764 rights that may cover technology that may be required to implement
765 this standard. Please address the information to the IETF at
770 Copyright (C) The Internet Society (2004). This document is subject
771 to the rights, licenses and restrictions contained in BCP 78, and
772 except as set forth therein, the authors retain all their rights.
774 This document and the information contained herein are provided on an
775 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
776 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
777 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
781 Smith & Howes Intended Category: Standards Track [Page 14]
783 INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
786 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
787 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
790 This Internet Draft expires on 24 April 2005.
837 Smith & Howes Intended Category: Standards Track [Page 15]