idnits 2.17.1 draft-ietf-ldapbis-url-04.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2255, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 October 2003) is 7489 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Models' is mentioned on line 511, but not defined -- Looks like a reference, but probably isn't: '1' on line 595 == Missing Reference: 'LDAPIANA' is mentioned on line 636, but not defined -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPDN' -- No information found for draft-ietf-ldapbis-filter-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Filters' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3383 (Obsoleted by RFC 4520) -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AuthMeth' -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-yergeau-rfc2279bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UTF-8' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Mark Smith, Editor 3 Request for Comments: DRAFT Netscape Communications Corp. 4 Obsoletes: RFC 2255 Tim Howes 5 Expires: 25 April 2004 Opsware, Inc. 7 25 October 2003 9 LDAP: Uniform Resource Locator 10 12 1. Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Discussion of this document should take place on the LDAP (v3) 34 Revision (ldapbis) Working Group mailing list . 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 2. Abstract 41 This document describes a format for an LDAP Uniform Resource Locator 42 (URL). An LDAP URL describes an LDAP search operation that is used 43 to retrieve information from an LDAP directory, or, in the context of 44 an LDAPv3 referral or reference, an LDAP URL describes a service 45 where an LDAP operation may be progressed. 47 3. Table of Contents 49 1. Status of this Memo............................................1 50 2. Abstract.......................................................1 51 3. Table of Contents..............................................2 52 4. Introduction...................................................2 53 5. URL Definition.................................................2 54 5.1. Escaping Using the Method.................................4 55 6. Defaults for Fields of the LDAP URL............................5 56 7. Examples.......................................................6 57 8. Security Considerations........................................8 58 9. Normative References...........................................8 59 10. Informative References.........................................9 60 11. Intellectual Property Rights...................................9 61 12. Acknowledgements...............................................10 62 13. Authors' Address...............................................10 63 14. Full Copyright Statement.......................................11 64 15. Appendix A: Changes Since RFC 2255.............................11 65 15.1. Technical Changes...........................................11 66 15.2. Editorial Changes...........................................12 67 16. Appendix B: Changes Since Previous Document Revision...........13 68 16.1. Technical Changes...........................................14 69 16.2. Editorial Changes...........................................14 71 4. Introduction 73 LDAP is the Lightweight Directory Access Protocol, defined in 74 [Protocol]. This document specifies the LDAP URL format for version 75 3 of LDAP and clarifies how LDAP URLs are resolved. This document 76 also defines an extension mechanism for LDAP URLs, so that future 77 documents can extend their functionality, for example, to provide 78 access to new LDAPv3 extensions as they are defined. Note: not all 79 of the parameters of the LDAP search operation described in 80 [Protocol] can be expressed using the format defined in this 81 document. 83 This document is an integral part of the LDAP Technical Specification 84 [Roadmap]. 86 This document replaces RFC 2255. See Appendix A for a list of changes 87 relative to RFC 2255. 89 The key words "MUST", "MAY", and "SHOULD" used in this document are 90 to be interpreted as described in [RFC2119]. 92 5. URL Definition 94 An LDAP URL begins with the protocol prefix "ldap" and is defined by 95 the following grammar, following the ABNF notation defined in 96 [RFC2234]. 98 ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn 99 [QUESTION [attributes] [QUESTION [scope] 100 [QUESTION [filter] [QUESTION extensions]]]]] 101 scheme = "ldap" 102 hostport = 103 ; as updated by [RFC2732] to allow IPv6 literal addresses 104 dn = 105 ; see the "Escaping Using the % Method" section below. 106 attributes = attrdesc *(COMMA attrdesc) 107 attrdesc = 108 / ASTERISK 109 ; see the "Escaping Using the % Method" section below. 110 scope = "base" / "one" / "sub" 111 filter = 112 ; see the "Escaping Using the % Method" section below. 113 extensions = extension *(COMMA extension) 114 extension = [EXCLAMATION] extype [EQUALS exvalue] 115 extype = oid / oiddescr 116 exvalue = 117 ; see the "Escaping Using the % Method" section below. 118 oid = 119 oiddescr = 121 EXCLAMATION = %x21 ; exclamation mark ("!") 122 ASTERISK = %x2A ; asterisk ("*") 123 COLON = %x3A ; colon (":") 124 QUESTION = %x3F ; question mark ("?") 125 SLASH = %x5C; forward slash ("/") 127 The "ldap" prefix indicates an entry or entries residing in the LDAP 128 server running on the given hostname at the given portnumber. Note 129 that the hostport may contain literal IPv6 addresses as specified in 130 [RFC2732]. 132 The dn is an LDAP Distinguished Name using the string format 133 described in [LDAPDN]. It identifies the base object of the LDAP 134 search or the target of a non-search operation. 136 The attributes construct is used to indicate which attributes should 137 be returned from the entry or entries. Individual attrdesc names are 138 as defined for AttributeDescription in [Protocol]. 140 The scope construct is used to specify the scope of the search to 141 perform in the given LDAP server. The allowable scopes are "base" 142 for a base object search, "one" for a one-level search, or "sub" for 143 a subtree search. 145 The filter is used to specify the search filter to apply to entries 146 within the specified scope during the search. It has the format 147 specified in [Filters]. 149 The extensions construct provides the LDAP URL with an extensibility 150 mechanism, allowing the capabilities of the URL to be extended in the 151 future. Extensions are a simple comma-separated list of type=value 152 pairs, where the =value portion MAY be omitted for options not 153 requiring it. Each type=value pair is a separate extension. These 154 LDAP URL extensions are not necessarily related to any of the LDAPv3 155 extension mechanisms. Extensions may be supported or unsupported by 156 the client resolving the URL. An extension prefixed with a '!' 157 character (ASCII 33) is critical. An extension not prefixed with a 158 '!' character is non-critical. 160 If an extension is supported by the client, the client MUST obey the 161 extension if the extension is critical. The client SHOULD obey 162 supported extensions that are non-critical. 164 If an extension is unsupported by the client, the client MUST NOT 165 process the URL if the extension is critical. If an unsupported 166 extension is non-critical, the client MUST ignore the extension. 168 If a critical extension cannot be processed successfully by the 169 client, the client MUST NOT process the URL. If a non-critical 170 extension cannot be processed successfully by the client, the client 171 SHOULD ignore the extension. 173 The extension type (extype) MAY be specified using the oid form 174 (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use 175 of the oiddesc form SHOULD be restricted to registered object 176 identifier descriptive names. See [RFC3383] for registration details 177 and usage guidelines for descriptive names. 179 No LDAP URL extensions are defined in this document. Other documents 180 or a future version of this document MAY define one or more 181 extensions. 183 5.1. Escaping Using the % Method 185 A generated LDAP URL MUST consist only of the restricted set of 186 characters included in the uric production that is defined in section 187 2 of [RFC2396]. Implementations SHOULD accept other valid UTF-8 188 strings [UTF-8] as input. An octet MUST be escaped using the % 189 method described in section 2.4 of [RFC2396] in any of these 190 situations: 192 The octet is not in the reserved set defined in section 2.2 of 193 [RFC2396] or in the unreserved set defined in section 2.3 of 194 [RFC2396]. 196 It is the single Reserved character '?' and occurs inside a dn, 197 filter, or other element of an LDAP URL. 199 It is a comma character ',' that occurs inside an extension value. 201 6. Defaults for Fields of the LDAP URL 203 Some fields of the LDAP URL are optional, as described above. In the 204 absence of any other specification, the following general defaults 205 SHOULD be used when a field is absent. Note: other documents MAY 206 specify different defaulting rules; for example, section 4.1.11 of 207 [Protocol] specifies a different rule for determining the correct DN 208 to use when it is absent in an LDAP URL that is returned as a 209 referral. 211 hostport 212 The default LDAP port is TCP port 389. If no hostport is given, 213 the client must have some apriori knowledge of an appropriate LDAP 214 server to contact. 216 dn 217 If no dn is given, the default is the zero-length DN, "". 219 attributes 220 If the attributes part is omitted, all user attributes of the 221 entry or entries should be requested (e.g., by setting the 222 attributes field AttributeDescriptionList in the LDAP search 223 request to a NULL list, or (in LDAPv3) by requesting the special 224 attribute name "*"). 226 scope 227 If scope is omitted, a scope of "base" is assumed. 229 filter 230 If filter is omitted, a filter of "(objectClass=*)" is assumed. 232 extensions 233 If extensions is omitted, no extensions are assumed. 235 7. Examples 237 The following are some example LDAP URLs using the format defined 238 above. The first example is an LDAP URL referring to the University 239 of Michigan entry, available from an LDAP server of the client's 240 choosing: 242 ldap:///o=University%20of%20Michigan,c=US 244 The next example is an LDAP URL referring to the University of 245 Michigan entry in a particular ldap server: 247 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US 249 Both of these URLs correspond to a base object search of the 250 "o=University of Michigan,c=US" entry using a filter of 251 "(objectclass=*)", requesting all attributes. 253 The next example is an LDAP URL referring to only the postalAddress 254 attribute of the University of Michigan entry: 256 ldap://ldap1.example.net/o=University%20of%20Michigan, 257 c=US?postalAddress 259 The corresponding LDAP search operation is the same as in the 260 previous example, except that only the postalAddress attribute is 261 requested. 263 The next example is an LDAP URL referring to the set of entries found 264 by querying the given LDAP server on port 6666 and doing a subtree 265 search of the University of Michigan for any entry with a common name 266 of "Babs Jensen", retrieving all attributes: 268 ldap://ldap1.example.net:6666/o=University%20of%20Michigan, 269 c=US??sub?(cn=Babs%20Jensen) 271 The next example is an LDAP URL referring to all children of the c=GB 272 entry: 274 ldap://ldap1.example.com/c=GB?objectClass?one 276 The objectClass attribute is requested to be returned along with the 277 entries, and the default filter of "(objectclass=*)" is used. 279 The next example is an LDAP URL to retrieve the mail attribute for 280 the LDAP entry named "o=Question?,c=US" is given below, illustrating 281 the use of the escaping mechanism on the reserved character '?'. 283 ldap://ldap2.example.com/o=Question%3f,c=US?mail 285 The next example illustrates the interaction between the LDAP string 286 representation of filters quoting mechanism and URL quoting 287 mechanisms. 289 ldap://ldap3.example.com/o=Babsco,c=US???(four-octet=%5c00%5c00%5c00%5c04) 290 IP The filter in this example uses the LDAP escaping mechanism of \ 291 to encode three zero or null bytes in the value. In LDAP, the filter 292 would be written as (four-octet=\00\00\00\04). Because the \ 293 character must be escaped in a URL, the \'s are escaped as %5c in the 294 URL encoding. 296 The next example illustrates the interaction between the LDAP string 297 representation of DNs quoting mechanism and URL quoting mechanisms. 299 ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US 301 The DN encoded in the above URL is: 303 o=An Example\2c Inc.,c=US 305 That is, the left-most RDN value is: 307 An Example, Inc. 309 The following three URLs that are equivalent, assuming that the 310 defaulting rules specified in section 4 of this document are used: 312 ldap://ldap.example.net 313 ldap://ldap.example.net/ 314 ldap://ldap.example.net/? 316 These three URLs all point to the root DSE on the ldap.example.net 317 server. 319 The final two examples show use of a hypothetical, experimental bind 320 name extension (the value associated with the extension is an LDAP DN). 322 ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com 323 ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com 325 The two URLs are the same, except that the second one marks the e- 326 bindname extension as critical. Notice the use of the % encoding 327 method to encode the commas within the distinguished name value in 328 the e-bindname extension. 330 8. Security Considerations 332 General URL security considerations discussed in [RFC2396] are 333 relevant for LDAP URLs. 335 The use of security mechanisms when processing LDAP URLs requires 336 particular care, since clients may encounter many different servers 337 via URLs, and since URLs are likely to be processed automatically, 338 without user intervention. A client SHOULD have a user-configurable 339 policy about which servers to connect to using which security 340 mechanisms, and SHOULD NOT make connections that are inconsistent 341 with this policy. If a client chooses to reuse an existing 342 connection when resolving one or more LDAP URL, it MUST ensure that 343 the connection is compatible with the URL and that no security 344 policies are violated. 346 Sending authentication information, no matter the mechanism, may 347 violate a user's privacy requirements. In the absence of specific 348 policy permitting authentication information to be sent to a server, 349 a client should use an anonymous connection. (Note that clients 350 conforming to previous LDAP URL specifications, where all connections 351 are anonymous and unprotected, are consistent with this 352 specification; they simply have the default security policy.) Simply 353 opening a connection to another server may violate some users' 354 privacy requirements, so clients should provide the user with a way 355 to control URL processing. 357 Some authentication methods, in particular reusable passwords sent to 358 the server, may reveal easily-abused information to the remote server 359 or to eavesdroppers in transit, and should not be used in URL 360 processing unless explicitly permitted by policy. Confirmation by 361 the human user of the use of authentication information is 362 appropriate in many circumstances. Use of strong authentication 363 methods that do not reveal sensitive information is much preferred. 364 If the URL represents a referral for an update operation, strong 365 authentication methods SHOULD be used. Please refer to the Security 366 Considerations section of [AuthMeth] for more information. 368 The LDAP URL format allows the specification of an arbitrary LDAP 369 search operation to be performed when evaluating the LDAP URL. 370 Following an LDAP URL may cause unexpected results, for example, the 371 retrieval of large amounts of data, the initiation of a long-lived 372 search, etc. The security implications of resolving an LDAP URL are 373 the same as those of resolving an LDAP search query. 375 9. Normative References 377 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 378 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in 379 progress. 381 [Filters] Smith, M. and Howes, T., "LDAP: String Representation of 382 Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in 383 progress. 385 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 386 Requirement Levels," RFC 2119, BCP 14, March 1997. 388 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft- 389 ietf-ldapbis-protocol-xx.txt, a work in progress. 391 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 392 Specifications: ABNF", RFC 2234, November 1997. 394 [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 395 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 397 [RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for 398 Literal IPv6 Addresses in URL's", RFC 2732, December 1999. 400 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 401 Considerations for the Lightweight Directory Access Protocol 402 (LDAP)", RFC 3383, September 2002. 404 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods", 405 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a work in 406 progress. 408 [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road 409 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 411 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 412 draft-yergeau-rfc2279bis-xx.txt, a work in progress. 414 10. Informative References 416 None. 418 11. Intellectual Property Rights 420 The IETF takes no position regarding the validity or scope of any 421 intellectual property or other rights that might be claimed to 422 pertain to the implementation or use of the technology described in 423 this document or the extent to which any license under such rights 424 might or might not be available; neither does it represent that it 425 has made any effort to identify any such rights. Information on the 426 IETF's procedures with respect to rights in standards-track and 427 standards-related documentation can be found in BCP-11. Copies of 428 claims of rights made available for publication and any assurances of 429 licenses to be made available, or the result of an attempt made to 430 obtain a general license or permission for the use of such 431 proprietary rights by implementors or users of this specification can 432 be obtained from the IETF Secretariat. 434 The IETF invites any interested party to bring to its attention any 435 copyrights, patents or patent applications, or other proprietary 436 rights which may cover technology that may be required to practice 437 this standard. Please address the information to the IETF Executive 438 Director. 440 12. Acknowledgements 442 The LDAP URL format was originally defined at the University of 443 Michigan. This material is based upon work supported by the National 444 Science Foundation under Grant No. NCR-9416667. The support of both 445 the University of Michigan and the National Science Foundation is 446 gratefully acknowledged. 448 This document is an update to RFC 2255 by Tim Howes and Mark Smith. 449 Changes included in this revised specification are based upon 450 discussions among the authors, discussions within the LDAP (v3) 451 Revision Working Group (ldapbis), and discussions within other IETF 452 Working Groups. The contributions of individuals in these working 453 groups is gratefully acknowledged. Several people in particular have 454 made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, 455 Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special 456 thanks for their contributions. 458 13. Authors' Address 460 Mark Smith, Editor 461 Netscape Communications Corp. 462 360 W. Caribbean Drive 463 Sunnyvale, CA 94089 464 USA 465 +1 650 937-3477 466 MarkCSmithWork@aol.com 468 Tim Howes 469 Opsware, Inc. 470 599 N. Mathilda Ave. 471 Sunnyvale, CA 94085 472 USA 473 +1 408 744-7509 474 howes@opsware.com 476 14. Full Copyright Statement 478 Copyright (C) The Internet Society (2003). All Rights Reserved. 480 This document and translations of it may be copied and furnished to 481 others, and derivative works that comment on or otherwise explain it 482 or assist in its implementation may be prepared, copied, published 483 and distributed, in whole or in part, without restriction of any 484 kind, provided that the above copyright notice and this paragraph are 485 included on all such copies and derivative works. However, this 486 document itself may not be modified in any way, such as by removing 487 the copyright notice or references to the Internet Society or other 488 Internet organizations, except as needed for the purpose of 489 developing Internet standards in which case the procedures for 490 copyrights defined in the Internet Standards process must be 491 followed, or as required to translate it into languages other than 492 English. 494 The limited permissions granted above are perpetual and will not be 495 revoked by the Internet Society or its successors or assigns. 497 This document and the information contained herein is provided on an 498 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 499 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 500 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 501 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 502 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 504 15. Appendix A: Changes Since RFC 2255 506 15.1. Technical Changes 508 The following technical changes were made to the contents of the "URL 509 Definition" section: 511 Revised all of the ABNF to use common productions from [Models]. 513 Added note and references to [RFC2732] to allow literal IPv6 514 addresses inside the hostport portion of the URL. 516 Added missing ASTERISK as an alternative for the attrdesc part of the 517 URL. It is believed that existing implementations of RFC 2255 518 already support this. 520 Added angle brackets around free-form prose in the "dn", "hostport", 521 "attrdesc", "filter", and "exvalue" rules. 523 Changed the ABNF for ldapurl to group the dn component with the 524 preceding slash. 526 Changed the extype rule to be an LDAPOID from [Protocol] or an OID 527 description from [RFC3383]. 529 Changed the text about extension types so it references [RFC3383]. 530 Reordered rules to more closely follow the order the elements appear 531 in the URL. 533 "Bindname Extension": removed due to lack of known implementations. 535 15.2. Editorial Changes 537 Changed document title to include "LDAP:" prefix. 539 IESG Note: removed note about lack of satisfactory mandatory 540 authentication mechanisms. 542 "Status of this Memo" section: updated boilerplate to match current 543 I-D guidelines. 545 "Abstract" section: separated from introductory material. 547 "Table of Contents" section: added. 549 "Introduction" section: new section; separated from the Abstract. 550 Changed the text indicate that RFC 2255 is replaced by this document 551 (instead of RFC 1959). Added text to indicate that LDAP URLs are 552 used for references and referrals. Fixed typo (replaced the nonsense 553 phrase "to perform to retrieve" with "used to retrieve"). Added a 554 note to let the reader know that not all of the parameters of the 555 LDAP search operation described in [Protocol] can be expressed using 556 this format. 558 "URL Definition" section: removed second copy of ldapurl grammar and 559 following two paragraphs (editorial error in RFC 2255). Fixed line 560 break within '!' sequence. Reworded last paragraph to clarify which 561 characters must be URL escaped. Added text to indicate that LDAP 562 URLs are used for references and referrals. Added text that refers 563 to the ABNF from RFC 2234. 565 "Defaults for Fields of the LDAP URL" section: added; formed by 566 moving text about defaults out of the "URL Definition" section. 568 "URL Processing" section: clarified that connections MAY be reused 569 only if the open connection is compatible with the URL. Added text 570 to indicate that use of security services is encouraged and that they 571 SHOULD be used when updates are involved. Removed "dn" from 572 discussion of authentication methods. Added note that the client MAY 573 interrogate the server to determine the most appropriate method. 575 "Examples" section: Modified examples to use example.com and 576 example.net hostnames. Added missing '?' to the LDAP URL example 577 whose filter contains three null bytes. Removed space after one 578 comma within a DN. Revised the bindname example to use e-bindname. 579 Changed the name of an attribute used in one example from "int" to 580 "four-octet" to avoid potential confusion. Added an example that 581 demonstrates the interaction between DN escaping and URL escaping. 582 Added some examples to show URL equivalence with respect to the dn 583 portion of the URL. 585 "Security Considerations" section: Added a note about connection 586 reuse. Added a note about using strong authentication methods for 587 updates. Added a reference to RFC 2829. Added note that simply 588 opening a connection may violate some users' privacy requirements. 590 "Acknowledgements" section: added statement about this being an 591 update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and 592 Hallvard Furuseth. 594 "Normative References" section: renamed from "References" per new RFC 595 guidelines. Changed from [1] style to [Protocol] style throughout the 596 document. Added references to RFCs 2234, 2829, and 3383. Updated 597 RFC 1738 references to the appropriate sections within RFC 2396. 598 Updated the references to refer to LDAPBis WG documents. Removed the 599 reference to the LDAP Attribute Syntaxes document and added a 600 reference to the Roadmap document. 602 "Informative References" section: added for clarity. 604 Header and "Authors' Address" sections: added "editor" next to Mark 605 Smith's name. Updated affiliation and contact information. 607 Copyright: updated the year. 609 16. Appendix B: Changes Since Previous Document Revision 611 This appendix lists all changes relative to the previously published 612 revision, draft-ietf-ldapbis-url-03.txt. Note that when appropriate 613 these changes are also included in Appendix A, but are also included 614 here for the benefit of the people who have already reviewed draft- 615 ietf-ldapbis-url-03.txt. This section will be removed before this 616 document is published as an RFC. 618 16.1. Technical Changes 620 None. 622 16.2. Editorial Changes 624 "URL Definition" section: added comments in the ABNF to point the 625 reader to the "Escaping Using the % Method" section, which was 626 changed into a section of its own to highlight the importance of 627 escaping the URL components correctly. 629 "Examples" section: changed the name of an attribute used in one 630 example from "int" to "four-octet" to avoid potential confusion. 632 Replaced all occurrences of "asterix" with the correctly spelled 633 "asterisk." 635 "Normative References" section: changed UTF-8 reference to point to 636 the UTF-8 Internet Draft; replace [LDAPIANA] Internet Draft reference 637 with a reference to RFC 3383. 639 "Intellectual Property Rights" section: added. 641 Author's Addresses section: New email address for Mark Smith. 643 "Full Copyright Statement" section: updated text to match latest IETF 644 guidelines. 646 This Internet Draft expires on 25 April 2004.