idnits 2.17.1 draft-ietf-ldapbis-url-03.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 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 146: '...e =value portion MAY be omitted for op...' RFC 2119 keyword, line 154: '...y the client, the client MUST obey the...' RFC 2119 keyword, line 155: '...on is critical. The client SHOULD obey...' RFC 2119 keyword, line 158: '...ted by the client, the client MUST NOT...' RFC 2119 keyword, line 160: '...ical, the client MUST ignore the exten...' (16 more instances...) == 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 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 (28 February 2003) is 7728 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: 'RFC2119' is mentioned on line 395, but not defined == Missing Reference: 'Models' is mentioned on line 585, but not defined -- Looks like a reference, but probably isn't: '1' on line 559 == Unused Reference: 'RFC2279' is defined on line 404, but no explicit reference was found in the text -- 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-iana-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPIANA' -- 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 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) -- 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' Summary: 11 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: 28 August 2003 Opsware, Inc. 7 28 February 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 6. Defaults for Fields of the LDAP URL............................5 55 7. Examples.......................................................5 56 8. Security Considerations........................................7 57 9. Acknowledgements...............................................8 58 10. Normative References...........................................9 59 11. Informative References.........................................9 60 12. Authors' Address...............................................9 61 13. Full Copyright Statement.......................................10 62 14. Appendix A: Changes Since RFC 2255.............................10 63 14.1. Technical Changes...........................................10 64 14.2. Editorial Changes...........................................11 65 15. Appendix B: Changes Since Previous Document Revision...........13 66 15.1. Technical Changes...........................................13 67 15.2. Editorial Changes...........................................13 69 4. Introduction 71 LDAP is the Lightweight Directory Access Protocol, defined in 72 [Protocol]. This document specifies the LDAP URL format for version 73 3 of LDAP and clarifies how LDAP URLs are resolved. This document 74 also defines an extension mechanism for LDAP URLs, so that future 75 documents can extend their functionality, for example, to provide 76 access to new LDAPv3 extensions as they are defined. Note: not all 77 of the parameters of the LDAP search operation described in 78 [Protocol] can be expressed using the format defined in this 79 document. 81 This document is an integral part of the LDAP Technical Specification 82 [Roadmap]. 84 This document replaces RFC 2255. See Appendix A for a list of changes 85 relative to RFC 2255. 87 The key words "MUST", "MAY", and "SHOULD" used in this document are 88 to be interpreted as described in [RFC2119]. 90 5. URL Definition 92 An LDAP URL begins with the protocol prefix "ldap" and is defined by 93 the following grammar, following the ABNF notation defined in 94 [RFC2234]. 96 ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn 97 [QUESTION [attributes] [QUESTION [scope] 98 [QUESTION [filter] [QUESTION extensions]]]]] 99 scheme = "ldap" 100 hostport = 101 ; as updated by [RFC2732] to allow IPv6 literal addresses 102 dn = 103 attributes = attrdesc *(COMMA attrdesc) 104 attrdesc = 105 / ASTERIX 106 scope = "base" / "one" / "sub" 107 filter = 108 extensions = extension *(COMMA extension) 109 extension = [EXCLAMATION] extype [EQUALS exvalue] 110 extype = oid / oiddescr 111 exvalue = 112 oid = 113 oiddescr = 115 EXCLAMATION = %x21 ; exclamation mark ("!") 116 ASTERIX = %x2A ; asterix ("*") 117 COLON = %x3A ; colon (":") 118 QUESTION = %x3F ; question mark ("?") 119 SLASH = %x5C; forward slash ("/") 121 The "ldap" prefix indicates an entry or entries residing in the LDAP 122 server running on the given hostname at the given portnumber. Note 123 that the hostport may contain literal IPv6 addresses as specified in 124 [RFC2732]. 126 The dn is an LDAP Distinguished Name using the string format 127 described in [LDAPDN]. It identifies the base object of the LDAP 128 search or the target of a non-search operation. 130 The attributes construct is used to indicate which attributes should 131 be returned from the entry or entries. Individual attrdesc names are 132 as defined for AttributeDescription in [Protocol]. 134 The scope construct is used to specify the scope of the search to 135 perform in the given LDAP server. The allowable scopes are "base" 136 for a base object search, "one" for a one-level search, or "sub" for 137 a subtree search. 139 The filter is used to specify the search filter to apply to entries 140 within the specified scope during the search. It has the format 141 specified in [Filters]. 143 The extensions construct provides the LDAP URL with an extensibility 144 mechanism, allowing the capabilities of the URL to be extended in the 145 future. Extensions are a simple comma-separated list of type=value 146 pairs, where the =value portion MAY be omitted for options not 147 requiring it. Each type=value pair is a separate extension. These 148 LDAP URL extensions are not necessarily related to any of the LDAPv3 149 extension mechanisms. Extensions may be supported or unsupported by 150 the client resolving the URL. An extension prefixed with a '!' 151 character (ASCII 33) is critical. An extension not prefixed with a 152 '!' character is non-critical. 154 If an extension is supported by the client, the client MUST obey the 155 extension if the extension is critical. The client SHOULD obey 156 supported extensions that are non-critical. 158 If an extension is unsupported by the client, the client MUST NOT 159 process the URL if the extension is critical. If an unsupported 160 extension is non-critical, the client MUST ignore the extension. 162 If a critical extension cannot be processed successfully by the 163 client, the client MUST NOT process the URL. If a non-critical 164 extension cannot be processed successfully by the client, the client 165 SHOULD ignore the extension. 167 The extension type (extype) MAY be specified using the oid form 168 (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use 169 of the oiddesc form SHOULD be restricted to registered object 170 identifier descriptive names. See [LDAPIANA] for registration 171 details and usage guidelines for descriptive names. 173 No LDAP URL extensions are defined in this document. Other documents 174 or a future version of this document MAY define one or more 175 extensions. 177 A generated LDAP URL MUST consist only of the restricted set of 178 characters included in the uric production that is defined in section 179 2 of [RFC2396]. Implementations SHOULD accept other valid UTF-8 180 strings as input. An octet MUST be escaped using the % method 181 described in section 2.4 of [RFC2396] in any of these situations: 183 The octet is not in the reserved set defined in section 2.2 of 184 [RFC2396] or in the unreserved set defined in section 2.3 of 185 [RFC2396]. 187 It is the single Reserved character '?' and occurs inside a dn, 188 filter, or other element of an LDAP URL. 190 It is a comma character ',' that occurs inside an extension value. 192 6. Defaults for Fields of the LDAP URL 194 Some fields of the LDAP URL are optional, as described above. In the 195 absence of any other specification, the following general defaults 196 SHOULD be used when a field is absent. Note: other documents MAY 197 specify different defaulting rules; for example, section 4.1.11 of 198 [Protocol] specifies a different rule for determining the correct DN 199 to use when it is absent in an LDAP URL that is returned as a 200 referral. 202 hostport 203 The default LDAP port is TCP port 389. If no hostport is given, 204 the client must have some apriori knowledge of an appropriate LDAP 205 server to contact. 207 dn 208 If no dn is given, the default is the zero-length DN, "". 210 attributes 211 If the attributes part is omitted, all user attributes of the 212 entry or entries should be requested (e.g., by setting the 213 attributes field AttributeDescriptionList in the LDAP search 214 request to a NULL list, or (in LDAPv3) by requesting the special 215 attribute name "*"). 217 scope 218 If scope is omitted, a scope of "base" is assumed. 220 filter 221 If filter is omitted, a filter of "(objectClass=*)" is assumed. 223 extensions 224 If extensions is omitted, no extensions are assumed. 226 7. Examples 228 The following are some example LDAP URLs using the format defined 229 above. The first example is an LDAP URL referring to the University 230 of Michigan entry, available from an LDAP server of the client's 231 choosing: 233 ldap:///o=University%20of%20Michigan,c=US 235 The next example is an LDAP URL referring to the University of 236 Michigan entry in a particular ldap server: 238 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US 240 Both of these URLs correspond to a base object search of the 241 "o=University of Michigan,c=US" entry using a filter of 242 "(objectclass=*)", requesting all attributes. 244 The next example is an LDAP URL referring to only the postalAddress 245 attribute of the University of Michigan entry: 247 ldap://ldap1.example.net/o=University%20of%20Michigan, 248 c=US?postalAddress 250 The corresponding LDAP search operation is the same as in the 251 previous example, except that only the postalAddress attribute is 252 requested. 254 The next example is an LDAP URL referring to the set of entries found 255 by querying the given LDAP server on port 6666 and doing a subtree 256 search of the University of Michigan for any entry with a common name 257 of "Babs Jensen", retrieving all attributes: 259 ldap://ldap1.example.net:6666/o=University%20of%20Michigan, 260 c=US??sub?(cn=Babs%20Jensen) 262 The next example is an LDAP URL referring to all children of the c=GB 263 entry: 265 ldap://ldap1.example.com/c=GB?objectClass?one 267 The objectClass attribute is requested to be returned along with the 268 entries, and the default filter of "(objectclass=*)" is used. 270 The next example is an LDAP URL to retrieve the mail attribute for 271 the LDAP entry named "o=Question?,c=US" is given below, illustrating 272 the use of the escaping mechanism on the reserved character '?'. 274 ldap://ldap2.example.com/o=Question%3f,c=US?mail 276 The next example illustrates the interaction between the LDAP string 277 representation of filters quoting mechanism and URL quoting 278 mechanisms. 280 ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04) 282 The filter in this example uses the LDAP escaping mechanism of \ to 283 encode three zero or null bytes in the value. In LDAP, the filter 284 would be written as (int=\00\00\00\04). Because the \ character must 285 be escaped in a URL, the \'s are escaped as %5c in the URL encoding. 287 The next example illustrates the interaction between the LDAP string 288 representation of DNs quoting mechanism and URL quoting mechanisms. 290 ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US 292 The DN encoded in the above URL is: 294 o=An Example\2c Inc.,c=US 296 That is, the left-most RDN value is: 298 An Example, Inc. 300 The following three URLs that are equivalent, assuming that the 301 defaulting rules specified in section 4 of this document are used: 303 ldap://ldap.example.net 304 ldap://ldap.example.net/ 305 ldap://ldap.example.net/? 307 These three URLs all point to the root DSE on the ldap.example.net 308 server. 310 The final two examples show use of a hypothetical, experimental bind 311 name extension (the value associated with the extension is an LDAP DN). 313 ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com 314 ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com 316 The two URLs are the same, except that the second one marks the e- 317 bindname extension as critical. Notice the use of the % encoding 318 method to encode the commas within the distinguished name value in 319 the e-bindname extension. 321 8. Security Considerations 323 General URL security considerations discussed in [RFC2396] are 324 relevant for LDAP URLs. 326 The use of security mechanisms when processing LDAP URLs requires 327 particular care, since clients may encounter many different servers 328 via URLs, and since URLs are likely to be processed automatically, 329 without user intervention. A client SHOULD have a user-configurable 330 policy about which servers to connect to using which security 331 mechanisms, and SHOULD NOT make connections that are inconsistent 332 with this policy. If a client chooses to reuse an existing 333 connection when resolving one or more LDAP URL, it MUST ensure that 334 the connection is compatible with the URL and that no security 335 policies are violated. 337 Sending authentication information, no matter the mechanism, may 338 violate a user's privacy requirements. In the absence of specific 339 policy permitting authentication information to be sent to a server, 340 a client should use an anonymous connection. (Note that clients 341 conforming to previous LDAP URL specifications, where all connections 342 are anonymous and unprotected, are consistent with this 343 specification; they simply have the default security policy.) Simply 344 opening a connection to another server may violate some users' 345 privacy requirements, so clients should provide the user with a way 346 to control URL processing. 348 Some authentication methods, in particular reusable passwords sent to 349 the server, may reveal easily-abused information to the remote server 350 or to eavesdroppers in transit, and should not be used in URL 351 processing unless explicitly permitted by policy. Confirmation by 352 the human user of the use of authentication information is 353 appropriate in many circumstances. Use of strong authentication 354 methods that do not reveal sensitive information is much preferred. 355 If the URL represents a referral for an update operation, strong 356 authentication methods SHOULD be used. Please refer to the Security 357 Considerations section of [AuthMeth] for more information. 359 The LDAP URL format allows the specification of an arbitrary LDAP 360 search operation to be performed when evaluating the LDAP URL. 361 Following an LDAP URL may cause unexpected results, for example, the 362 retrieval of large amounts of data, the initiation of a long-lived 363 search, etc. The security implications of resolving an LDAP URL are 364 the same as those of resolving an LDAP search query. 366 9. Acknowledgements 368 The LDAP URL format was originally defined at the University of 369 Michigan. This material is based upon work supported by the National 370 Science Foundation under Grant No. NCR-9416667. The support of both 371 the University of Michigan and the National Science Foundation is 372 gratefully acknowledged. 374 This document is an update to RFC 2255 by Tim Howes and Mark Smith. 375 Changes included in this revised specification are based upon 376 discussions among the authors, discussions within the LDAP (v3) 377 Revision Working Group (ldapbis), and discussions within other IETF 378 Working Groups. The contributions of individuals in these working 379 groups is gratefully acknowledged. Several people in particular have 380 made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, 381 Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special 382 thanks for their contributions. 384 10. Normative References 386 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 387 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in 388 progress. 390 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf- 391 ldapbis-iana-xx.txt, a work in progress. 393 [Filters] Smith, M. and Howes, T., "LDAP: String Representation of 394 Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in 395 progress. [RFC2119] Bradner, S., "Key Words for use in RFCs to 396 Indicate Requirement Levels," RFC 2119, BCP 14, March 1997. 398 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft- 399 ietf-ldapbis-protocol-xx.txt, a work in progress. 401 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 402 Specifications: ABNF", RFC 2234, November 1997. 404 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 405 RFC 2279, January 1998. 407 [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 408 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 410 [RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for 411 Literal IPv6 Addresses in URL's", RFC 2732, December 1999. 413 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods", 414 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a work in 415 progress. 417 [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road 418 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 420 11. Informative References 422 None. 424 12. Authors' Address 426 Mark Smith, Editor 427 Netscape Communications Corp. 428 360 W. Caribbean Drive 429 Sunnyvale, CA 94089 430 USA 431 +1 650 937-3477 432 mcs@netscape.com 434 Tim Howes 435 Opsware, Inc. 436 599 N. Mathilda Ave. 437 Sunnyvale, CA 94085 438 USA 439 +1 408 744-7509 440 howes@opsware.com 442 13. Full Copyright Statement 444 Copyright (C) The Internet Society (2003). All Rights Reserved. 446 This document and translations of it may be copied and furnished to 447 others, and derivative works that comment on or otherwise explain it 448 or assist in its implementation may be prepared, copied, published 449 and distributed, in whole or in part, without restriction of any 450 kind, provided that the above copyright notice and this paragraph are 451 included on all such copies and derivative works. However, this 452 document itself may not be modified in any way, such as by removing 453 the copyright notice or references to the Internet Society or other 454 Internet organizations, except as needed for the purpose of 455 developing Internet standards in which case the procedures for 456 copyrights defined in the Internet Standards process must be 457 followed, or as required to translate it into languages other than 458 English. 460 The limited permissions granted above are perpetual and will not be 461 revoked by the Internet Society or its successors or assigns. 463 This document and the information contained herein is provided on an 464 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 465 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 466 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 467 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 468 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 470 14. Appendix A: Changes Since RFC 2255 472 14.1. Technical Changes 474 The following technical changes were made to the contents of the "URL 475 Definition" section: 477 Revised all of the ABNF to use common productions from [Models]. 479 Added note and references to [RFC2732] to allow literal IPv6 480 addresses inside the hostport portion of the URL. 482 Added missing ASTERIX as an alternative for the attrdesc part of the 483 URL. It is believed that existing implementations of RFC 2255 484 already support this. 486 Added angle brackets around free-form prose in the "dn", "hostport", 487 "attrdesc", "filter", and "exvalue" rules. 489 Changed the ABNF for ldapurl to group the dn component with the 490 preceding slash. 492 Changed the extype rule to be an LDAPOID from [Protocol] or an OID 493 description from [LDAPIANA]. 495 Changed the text about extension types so it references [LDAPIANA]. 496 Reordered rules to more closely follow the order the elements appear 497 in the URL. 499 "Bindname Extension": removed due to lack of known implementations. 501 14.2. Editorial Changes 503 Changed document title to include "LDAP:" prefix. 505 IESG Note: removed note about lack of satisfactory mandatory 506 authentication mechanisms. 508 "Status of this Memo" section: updated boilerplate to match current 509 I-D guidelines. 511 "Abstract" section: separated from introductory material. 513 "Table of Contents" section: added. 515 "Introduction" section: new section; separated from the Abstract. 516 Changed the text indicate that RFC 2255 is replaced by this document 517 (instead of RFC 1959). Added text to indicate that LDAP URLs are 518 used for references and referrals. Fixed typo (replaced the nonsense 519 phrase "to perform to retrieve" with "used to retrieve"). Added a 520 note to let the reader know that not all of the parameters of the 521 LDAP search operation described in [Protocol] can be expressed using 522 this format. 524 "URL Definition" section: removed second copy of ldapurl grammar and 525 following two paragraphs (editorial error in RFC 2255). Fixed line 526 break within '!' sequence. Reworded last paragraph to clarify which 527 characters must be URL escaped. Added text to indicate that LDAP 528 URLs are used for references and referrals. Added text that refers 529 to the ABNF from RFC 2234. 531 "Defaults for Fields of the LDAP URL" section: added; formed by 532 moving text about defaults out of the "URL Definition" section. 534 "URL Processing" section: clarified that connections MAY be reused 535 only if the open connection is compatible with the URL. Added text 536 to indicate that use of security services is encouraged and that they 537 SHOULD be used when updates are involved. Removed "dn" from 538 discussion of authentication methods. Added note that the client MAY 539 interrogate the server to determine the most appropriate method. 541 "Examples" section: Modified examples to use example.com and 542 example.net hostnames. Added missing '?' to the LDAP URL example 543 whose filter contains three null bytes. Removed space after one 544 comma within a DN. Revised the bindname example to use e-bindname. 545 Added an example that demonstrates the interaction between DN 546 escaping and URL escaping. Added some examples to show URL 547 equivalence with respect to the dn portion of the URL. 549 "Security Considerations" section: Added a note about connection 550 reuse. Added a note about using strong authentication methods for 551 updates. Added a reference to RFC 2829. Added note that simply 552 opening a connection may violate some users' privacy requirements. 554 "Acknowledgements" section: added statement about this being an 555 update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and 556 Hallvard Furuseth. 558 "Normative References" section: renamed from "References" per new RFC 559 guidelines. Changed from [1] style to [Protocol] style throughout the 560 document. Added references to RFCs 2234 and 2829. Updated RFC 1738 561 references to the appropriate sections within RFC 2396. Updated the 562 references to refer to LDAPBis WG documents. Removed the reference to 563 the LDAP Attribute Syntaxes document and added references to the LDAP 564 IANA and Roadmap documents. 566 "Informative References" section: added for clarity. 568 Header and "Authors' Address" sections: added "editor" next to Mark 569 Smith's name. Updated affiliation and contact information. 571 Copyright: updated the year. 573 15. Appendix B: Changes Since Previous Document Revision 575 This appendix lists all changes relative to the last published 576 revision, draft-ietf-ldapbis-url-02.txt. Note that when appropriate 577 these changes are also included in Appendix A, but are also included 578 here for the benefit of the people who have already reviewed draft- 579 ietf-ldapbis-url-02.txt. This section will be removed before this 580 document is published as an RFC. 582 15.1. Technical Changes 584 "URL Definition" section: revised all of the ABNF to use common 585 productions from [Models] and added note and references to [RFC2732] 586 to allow literal IPv6 addresses inside the hostport portion of the 587 URL. 589 15.2. Editorial Changes 591 "Status of this Memo" section: updated boilerplate to match current 592 I-D guidelines. 594 "URL Definition" section: replaced misleading phrase "MAY define 595 other extensions" with "MAY define one or more extensions" (this 596 document no longer defines any extensions). Rewrote the last 597 paragraph of this section to more clearly describe the escaping rules 598 and to reference [RFC2396] accurately. 600 "Examples" section: added an example that demonstrates the 601 interaction between DN escaping and URL escaping and clarified the 602 text that introduces the LDAP filter escaping interaction example. 604 "Acknowledgements" section: added Hallvard Furuseth. 606 "Normative References" section: added a reference to [RFC2732]. 608 "Informative References" section: added for clarity. 610 Copyright: updated the year to 2003. 612 "Authors' Address" section: updated Tim's contact information. 614 Appendix A: added an older editorial change that was accidently 615 overlooked (Changed document title to include "LDAP:" prefix). 617 This Internet Draft expires on 28 August 2003.