idnits 2.17.1 draft-ietf-ldapbis-url-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 688. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 694), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (16 November 2004) is 7100 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 614, but not defined -- Looks like a reference, but probably isn't: '1' on line 583 -- 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-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) -- 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-ietf-ldapbis-bcp64-xx - is the name correct? Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 20 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 Pearl Crescent, LLC 4 Obsoletes: RFC 2255 Tim Howes 5 Expires: 16 May 2005 Opsware, Inc. 7 16 November 2004 9 LDAP: Uniform Resource Locator 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she become 17 aware will be disclosed, in accordance with RFC 3668. 19 This document is intended to be published as a Standards Track RFC, 20 replacing RFC 2255. Distribution of this memo is unlimited. 21 Technical discussion of this document will take place on the IETF 22 LDAP (v3) Revision (ldapbis) Working Group mailing list 23 . Please send editorial comments directly 24 to the editor . 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than a "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Please see the Full Copyright section near the end of this document 44 for more information. 46 Abstract 48 This document describes a format for a Lightweight Directory Access 49 Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL 50 describes an LDAP search operation that is used to retrieve 51 information from an LDAP directory, or, in the context of an LDAP 52 referral or reference, an LDAP URL describes a service where an LDAP 53 operation may be progressed. 55 Table of Contents 57 Status of this Memo............................................1 58 Abstract.......................................................2 59 Table of Contents..............................................2 60 1. Introduction...................................................2 61 2. URL Definition.................................................3 62 2.1. Escaping Using the % Method.................................5 63 3. Defaults for Fields of the LDAP URL............................5 64 4. Examples.......................................................6 65 5. Security Considerations........................................8 66 6. IANA Considerations............................................9 67 7. Normative References...........................................9 68 8. Informative References.........................................10 69 9. Acknowledgements...............................................10 70 10. Authors' Addresses.............................................10 71 11. Appendix A: Changes Since RFC 2255.............................11 72 11.1. Technical Changes...........................................11 73 11.2. Editorial Changes...........................................11 74 12. Appendix B: Changes Since Previous Document Revision...........13 75 12.1. Technical Changes...........................................13 76 12.2. Editorial Changes...........................................14 77 Intellectual Property Rights...................................15 78 Full Copyright.................................................15 80 1. Introduction 82 LDAP is the Lightweight Directory Access Protocol [Roadmap]. This 83 document specifies the LDAP URL format for version 3 of LDAP and 84 clarifies how LDAP URLs are resolved. This document also defines an 85 extension mechanism for LDAP URLs. This mechanism may be used to 86 provide access to new LDAP extensions. 88 Note that not all of the parameters of the LDAP search operation 89 described in [Protocol] can be expressed using the format defined in 90 this document. Note also that URLs may be used to represent reference 91 knowledge, including for non-search operations. 93 This document is a integral part of the LDAP technical specification 94 [Roadmap] which obsoletes the previously defined LDAP technical 95 specification, RFC 3377, in its entirety. 97 This document replaces RFC 2255. See Appendix A for a list of changes 98 relative to RFC 2255. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in BCP 14 [RFC2119]. 104 2. URL Definition 106 An LDAP URL begins with the protocol prefix "ldap" and is defined by 107 the following grammar, following the ABNF notation defined in 108 [RFC2234]. 110 ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn 111 [QUESTION [attributes] [QUESTION [scope] 112 [QUESTION [filter] [QUESTION extensions]]]]] 113 ; is from Section 114 ; 3.2.2 of [RFC2396] as updated 115 ; by [RFC2732] to allow IPv6 116 ; literal addresses. 117 ; is from Section 3 of 118 ; [Filters], subject to the 119 ; provisions of the "Escaping 120 ; Using the % Method" section 121 ; below. 123 scheme = "ldap" 125 dn = distinguishedName ; From Section 3 of [LDAPDN]. 126 ; See the "Escaping Using the 127 ; % Method" section below. 129 attributes = attrdesc *(COMMA attrdesc) 130 attrdesc = selector *(COMMA selector) 131 selector = attributeSelector ; From Section 4.5.1 of 132 ; [Protocol]. See the "Escaping 133 ; Using the % Method" section 134 ; below. 136 scope = "base" / "one" / "sub" 137 extensions = extension *(COMMA extension) 138 extension = [EXCLAMATION] extype [EQUALS exvalue] 139 extype = oid ; From section 1.4 of [Models]. 141 exvalue = LDAPString ; From section 4.1.2 of 142 ; [Protocol]. See the "Escaping 143 ; Using the % Method" section 144 ; below. 146 EXCLAMATION = %x21 ; exclamation mark ("!") 147 SLASH = %x2F ; forward slash ("/") 148 COLON = %x3A ; colon (":") 149 QUESTION = %x3F ; question mark ("?") 151 The "ldap" prefix indicates an entry or entries accessible from the 152 LDAP server running on the given hostname at the given portnumber. 153 Note that the may contain literal IPv6 addresses as 154 specified in [RFC2732]. 156 The is an LDAP Distinguished Name using the string format 157 described in [LDAPDN]. It identifies the base object of the LDAP 158 search or the target of a non-search operation. 160 The construct is used to indicate which attributes 161 should be returned from the entry or entries. 163 The construct is used to specify the scope of the search to 164 perform in the given LDAP server. The allowable scopes are "base" 165 for a base object search, "one" for a one-level search, or "sub" for 166 a subtree search. 168 The is used to specify the search filter to apply to entries 169 within the specified scope during the search. It has the format 170 specified in [Filters]. 172 The construct provides the LDAP URL with an 173 extensibility mechanism, allowing the capabilities of the URL to be 174 extended in the future. Extensions are a simple comma-separated list 175 of type=value pairs, where the =value portion MAY be omitted for 176 options not requiring it. Each type=value pair is a separate 177 extension. These LDAP URL extensions are not necessarily related to 178 any of the LDAP extension mechanisms. Extensions may be supported or 179 unsupported by the client resolving the URL. An extension prefixed 180 with a '!' character (ASCII 0x21) is critical. An extension not 181 prefixed with a '!' character is non-critical. 183 If an LDAP URL extension is implemented (that is, if the 184 implementation understands it and is able to use it), the 185 implementation MUST make use of it. If an extension is not 186 implemented and is marked critical, the implementation MUST NOT 187 process the URL. If an extension is not implemented and it not 188 marked critical, the implementation MUST ignore the extension. 190 The extension type () MAY be specified using the numeric OID 191 form (e.g., 1.2.3.4) or the descriptor form 192 (e.g., myLDAPURLExtension). Use of the form SHOULD be 193 restricted to registered object identifier descriptive names. See 194 [LDAPIANA] for registration details and usage guidelines for 195 descriptive names. 197 No LDAP URL extensions are defined in this document. Other documents 198 or a future version of this document MAY define one or more 199 extensions. 201 2.1. Escaping Using the % Method 203 A generated LDAP URL MUST consist only of the restricted set of 204 characters included in the production that is defined in 205 section 2 of [RFC2396]. Implementations SHOULD accept other valid 206 UTF-8 strings [RFC3629] as input. An octet MUST be escaped using the 207 % method described in section 2.4 of [RFC2396] in any of these 208 situations: 210 The octet is not in the reserved set defined in section 2.2 of 211 [RFC2396] or in the unreserved set defined in section 2.3 of 212 [RFC2396]. 214 It is the single Reserved character '?' and occurs inside a , 215 , or other element of an LDAP URL. 217 It is a comma character ',' that occurs inside an . 219 Note that before the % method of escaping is applied, the extensions 220 component of the LDAP URL may contain one or more null (zero) bytes. 221 No other component may. 223 3. Defaults for Fields of the LDAP URL 225 Some fields of the LDAP URL are optional, as described above. In the 226 absence of any other specification, the following general defaults 227 SHOULD be used when a field is absent. Note that other documents MAY 228 specify different defaulting rules; for example, section 4.1.10 of 229 [Protocol] specifies a different rule for determining the correct DN 230 to use when it is absent in an LDAP URL that is returned as a 231 referral. 233 234 The default LDAP port is TCP port 389. If no is given, 235 the client must have some apriori knowledge of an appropriate LDAP 236 server to contact. 238 239 If no is given, the default is the zero-length DN, "". 241 242 If the part is omitted, all user attributes of the 243 entry or entries should be requested (e.g., by setting the 244 attributes field AttributeDescriptionList in the LDAP search 245 request to a NULL list, or by using the special 246 selector "*"). 248 249 If is omitted, a of "base" is assumed. 251 252 If is omitted, a filter of "(objectClass=*)" is assumed. 254 255 If is omitted, no extensions are assumed. 257 4. Examples 259 The following are some example LDAP URLs using the format defined 260 above. The first example is an LDAP URL referring to the University 261 of Michigan entry, available from an LDAP server of the client's 262 choosing: 264 ldap:///o=University%20of%20Michigan,c=US 266 The next example is an LDAP URL referring to the University of 267 Michigan entry in a particular ldap server: 269 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US 271 Both of these URLs correspond to a base object search of the 272 "o=University of Michigan,c=US" entry using a filter of 273 "(objectclass=*)", requesting all attributes. 275 The next example is an LDAP URL referring to only the postalAddress 276 attribute of the University of Michigan entry: 278 ldap://ldap1.example.net/o=University%20of%20Michigan, 279 c=US?postalAddress 281 The corresponding LDAP search operation is the same as in the 282 previous example, except that only the postalAddress attribute is 283 requested. 285 The next example is an LDAP URL referring to the set of entries found 286 by querying the given LDAP server on port 6666 and doing a subtree 287 search of the University of Michigan for any entry with a common name 288 of "Babs Jensen", retrieving all attributes: 290 ldap://ldap1.example.net:6666/o=University%20of%20Michigan, 291 c=US??sub?(cn=Babs%20Jensen) 293 The next example is an LDAP URL referring to all children of the c=GB 294 entry: 296 LDAP://ldap1.example.com/c=GB?objectClass?ONE 298 The objectClass attribute is requested to be returned along with the 299 entries, and the default filter of "(objectclass=*)" is used. 301 The next example is an LDAP URL to retrieve the mail attribute for 302 the LDAP entry named "o=Question?,c=US" is given below, illustrating 303 the use of the escaping mechanism on the reserved character '?'. 305 ldap://ldap2.example.com/o=Question%3f,c=US?mail 307 The next example (which is broken into two lines for readability) 308 illustrates the interaction between the LDAP string representation of 309 filters quoting mechanism and URL quoting mechanisms. 311 ldap://ldap3.example.com/o=Babsco,c=US 312 ???(four-octet=%5c00%5c00%5c00%5c04) 314 The filter in this example uses the LDAP escaping mechanism of \ to 315 encode three zero or null bytes in the value. In LDAP, the filter 316 would be written as (four-octet=\00\00\00\04). Because the \ 317 character must be escaped in a URL, the \'s are escaped as %5c (or 318 %5C) in the URL encoding. 320 The next example illustrates the interaction between the LDAP string 321 representation of DNs quoting mechanism and URL quoting mechanisms. 323 ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US 325 The DN encoded in the above URL is: 327 o=An Example\2C Inc.,c=US 329 That is, the left-most RDN value is: 331 An Example, Inc. 333 The following three URLs that are equivalent, assuming that the 334 defaulting rules specified in section 4 of this document are used: 336 ldap://ldap.example.net 337 ldap://ldap.example.net/ 338 ldap://ldap.example.net/? 340 These three URLs all point to the root DSE on the ldap.example.net 341 server. 343 The final two examples show use of a hypothetical, experimental bind 344 name extension (the value associated with the extension is an LDAP DN). 346 ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com 347 ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com 349 The two URLs are the same, except that the second one marks the 350 e-bindname extension as critical. Notice the use of the % encoding 351 method to encode the commas within the distinguished name value in 352 the e-bindname extension. 354 5. Security Considerations 356 General URL security considerations discussed in [RFC2396] are 357 relevant for LDAP URLs. 359 The use of security mechanisms when processing LDAP URLs requires 360 particular care, since clients may encounter many different servers 361 via URLs, and since URLs are likely to be processed automatically, 362 without user intervention. A client SHOULD have a user-configurable 363 policy that controls which servers the client will establish LDAP 364 sessions with using which security mechanisms, and SHOULD NOT 365 establish LDAP sessions that are inconsistent with this policy. If a 366 client chooses to reuse an existing LDAP session when resolving one 367 or more LDAP URLs, it MUST ensure that the session is compatible with 368 the URL and that no security policies are violated. 370 Sending authentication information, no matter the mechanism, may 371 violate a user's privacy requirements. In the absence of specific 372 policy permitting authentication information to be sent to a server, 373 a client should use an anonymous LDAP session. (Note that clients 374 conforming to previous LDAP URL specifications, where all LDAP 375 sessions are anonymous and unprotected, are consistent with this 376 specification; they simply have the default security policy.) Simply 377 opening a transport connection to another server may violate some 378 users' privacy requirements, so clients should provide the user with 379 a way to control URL processing. 381 Some authentication methods, in particular reusable passwords sent to 382 the server, may reveal easily-abused information to the remote server 383 or to eavesdroppers in transit, and should not be used in URL 384 processing unless explicitly permitted by policy. Confirmation by 385 the human user of the use of authentication information is 386 appropriate in many circumstances. Use of strong authentication 387 methods that do not reveal sensitive information is much preferred. 388 If the URL represents a referral for an update operation, strong 389 authentication methods SHOULD be used. Please refer to the Security 390 Considerations section of [AuthMeth] for more information. 392 The LDAP URL format allows the specification of an arbitrary LDAP 393 search operation to be performed when evaluating the LDAP URL. 394 Following an LDAP URL may cause unexpected results, for example, the 395 retrieval of large amounts of data, the initiation of a long-lived 396 search, etc. The security implications of resolving an LDAP URL are 397 the same as those of resolving an LDAP search query. 399 6. IANA Considerations 401 This document has no actions for IANA. 403 7. Normative References 405 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods", 406 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a 407 work in progress. 409 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 410 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work 411 in progress. 413 [Filters] Smith, M. and Howes, T., "LDAP: String Representation of 414 Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in 415 progress. 417 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 418 Requirement Levels," RFC 2119, BCP 14, March 1997. 420 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 421 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 423 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 424 Specifications: ABNF", RFC 2234, November 1997. 426 [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 427 Resource Identifiers (URI): Generic Syntax", RFC 2396, 428 August 1998. 430 [RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Literal 431 IPv6 Addresses in URL's", RFC 2732, December 1999. 433 [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road 434 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 436 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 437 RFC 3629, November 2003. 439 8. Informative References 441 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", 442 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. None. 444 9. Acknowledgements 446 The LDAP URL format was originally defined at the University of 447 Michigan. This material is based upon work supported by the National 448 Science Foundation under Grant No. NCR-9416667. The support of both 449 the University of Michigan and the National Science Foundation is 450 gratefully acknowledged. 452 This document is an update to RFC 2255 by Tim Howes and Mark Smith. 453 Changes included in this revised specification are based upon 454 discussions among the authors, discussions within the LDAP (v3) 455 Revision Working Group (ldapbis), and discussions within other IETF 456 Working Groups. The contributions of individuals in these working 457 groups is gratefully acknowledged. Several people in particular have 458 made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, 459 Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special 460 thanks for their contributions. 462 10. Authors' Addresses 464 Mark Smith, Editor 465 Pearl Crescent, LLC 466 447 Marlpool Dr. 467 Saline, MI 48176 468 USA 469 +1 734 944-2856 470 mcs@pearlcrescent.com 472 Tim Howes 473 Opsware, Inc. 475 599 N. Mathilda Ave. 476 Sunnyvale, CA 94085 477 USA 478 +1 408 744-7509 479 howes@opsware.com 481 11. Appendix A: Changes Since RFC 2255 483 11.1. Technical Changes 485 The following technical changes were made to the contents of the "URL 486 Definition" section: 488 Revised all of the ABNF to use common productions from [Models]. 490 Added note and references to [RFC2732] to allow literal IPv6 491 addresses inside the hostport portion of the URL. 493 Changed the definition of to refer to 494 from [Protocol]. This allows use of "*" in the part of 495 the URL. It is believed that existing implementations of RFC 2255 496 already support this. 498 Avoided use of (bracketed-string) productions in the 499 , , , and rules. 501 Changed the ABNF for to group the component with the 502 preceding . 504 Changed the rule to be an from [Models]. 506 Changed the text about extension types so it references [LDAPIANA]. 507 Reordered rules to more closely follow the order the elements appear 508 in the URL. 510 "Bindname Extension": removed due to lack of known implementations. 512 11.2. Editorial Changes 514 Changed document title to include "LDAP:" prefix. 516 IESG Note: removed note about lack of satisfactory mandatory 517 authentication mechanisms. 519 "Status of this Memo" section: updated boilerplate to match current 520 I-D guidelines. 522 "Abstract" section: separated from introductory material. 524 "Table of Contents" and "IANA Considerations" sections: added. 526 "Introduction" section: new section; separated from the Abstract. 527 Changed the text indicate that RFC 2255 is replaced by this document 528 (instead of RFC 1959). Added text to indicate that LDAP URLs are 529 used for references and referrals. Fixed typo (replaced the nonsense 530 phrase "to perform to retrieve" with "used to retrieve"). Added a 531 note to let the reader know that not all of the parameters of the 532 LDAP search operation described in [Protocol] can be expressed using 533 this format. 535 "URL Definition" section: removed second copy of grammar 536 and following two paragraphs (editorial error in RFC 2255). Fixed 537 line break within '!' sequence. Reformatted the ABNF to improve 538 readability by aligning comments and adding some blank lines. 539 Replaced "residing in the LDAP server" with "accessible from the LDAP 540 server" in the sentence immediately following the ABNF. Removed the 541 sentence "Individual attrdesc names are as defined for 542 AttributeDescription in [Protocol]." because [Protocol]'s 543 is now used directly in the ABNF. Reworded last 544 paragraph to clarify which characters must be URL escaped. Added 545 text to indicate that LDAP URLs are used for references and 546 referrals. Added text that refers to the ABNF from RFC 2234. 547 Clarified and strengthened the requirements with respect to 548 processing of URLs that contain implements and not implemented 549 extensions (the approach now closely matches that specified in 550 [Protocol] for LDAP controls). 552 "Defaults for Fields of the LDAP URL" section: added; formed by 553 moving text about defaults out of the "URL Definition" section. 554 Replaced direct reference to the attribute name "*" with a reference 555 to the special selector "*" defined in [Protocol]. 557 "URL Processing" section: removed. 559 "Examples" section: Modified examples to use example.com and 560 example.net hostnames. Added missing '?' to the LDAP URL example 561 whose filter contains three null bytes. Removed space after one 562 comma within a DN. Revised the bindname example to use e-bindname. 563 Changed the name of an attribute used in one example from "int" to 564 "four-octet" to avoid potential confusion. Added an example that 565 demonstrates the interaction between DN escaping and URL escaping. 566 Added some examples to show URL equivalence with respect to the 567 portion of the URL. Used uppercase in some examples to remind the 568 reader that some tokens are case-insensitive. 570 "Security Considerations" section: Added a note about connection 571 reuse. Added a note about using strong authentication methods for 572 updates. Added a reference to [AuthMeth]. Added note that simply 573 opening a connection may violate some users' privacy requirements. 574 Adopted the working group's revised LDAP terminology specification by 575 replacing the word "connection" with "LDAP session" or "LDAP 576 connection" as appropriate. 578 "Acknowledgements" section: added statement about this being an 579 update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and 580 Hallvard Furuseth. 582 "Normative References" section: renamed from "References" per new RFC 583 guidelines. Changed from [1] style to [Protocol] style throughout the 584 document. Added references to RFC 2234, RFC 2732, and RFC 3629. 585 Updated all RFC 1738 references to point to the appropriate sections 586 within RFC 2396. Updated the LDAP references to refer to LDAPBis WG 587 documents. Removed the reference to the LDAP Attribute Syntaxes 588 document and added references to the [AuthMeth], [LDAPIANA], and 589 [Roadmap] documents. 591 "Informative References" section: added. 593 Header and "Authors' Addresses" sections: added "editor" next to Mark 594 Smith's name. Updated affiliation and contact information. 596 Copyright: updated the year. 598 Throughout the document: surrounded the names of all ABNF productions 599 with "<" and ">" where they are used in descriptive text. 601 12. Appendix B: Changes Since Previous Document Revision 603 This appendix lists all changes relative to the previously published 604 revision, draft-ietf-ldapbis-url-07.txt. Note that when appropriate 605 these changes are also included in Appendix A, but are also included 606 here for the benefit of the people who have already reviewed 607 draft-ietf-ldapbis-url-07.txt. This section will be removed before 608 this document is published as an RFC. 610 12.1. Technical Changes 612 "URL Definition" section: avoid the use of 613 (bracketed-string) productions. Use from 614 [Protocol] and from [Models]; this allowed , , 615 and to be removed from this document. Include correct 616 section references for [Protocol] and [Filters]. 618 12.2. Editorial Changes 620 "Abstract" section: spelled out LDAP on first use. 622 "Introduction" section: referenced [Roadmap] upon first use of LDAP 623 and expanded the paragraph that begins "This document is an integral 624 part of the LDAP technical specification..." to match the text used 625 in [Protocol]. Also re-worded the text that describes the extension 626 mechanism. 628 "URL Definition" section: reformatted the ABNF to improve readability 629 by aligning comments and adding some blank lines. Removed the 630 sentence "Individual attrdesc names are as defined for 631 AttributeDescription in [Protocol]." because [Protocol]'s 632 is now used directly in the ABNF. Replaced one 633 occurrence of "extension value" with to improve clarity. 635 "Defaults for Fields of the LDAP URL" section: in the 636 paragraph, replaced this phrase: 638 or (in LDAPv3) by requesting the special attribute name "*" 640 with the following: 642 by using the special selector "*" 644 "Examples" section: used uppercase "LDAP" and "ONE" in an example to 645 remind the reader that these tokens are case-insensitive. Likewise, 646 used uppercase in some hex escaped strings (e.g., replace "%5c" with 647 "%5C"). 649 "Security Considerations" section: adopted the working group's 650 revised LDAP terminology specification by updating the 2nd and 3rd 651 paragraphs to replace the word "connection" with "LDAP session" or 652 "LDAP connection" as appropriate. 654 References: moved [LDAPIANA] to "Informative References." 656 Changed these two sections to unnumbered ones: "Intellectual Property 657 Rights" and "Full Copyright." Removed the extra "Intellectual 658 Property Rights" section. 660 Throughout the document: surrounded the names of all ABNF productions 661 with "<" and ">" where they are used in descriptive text. 663 Throughout the document: replaced "Note: ..." constructs with "Note 664 that ...." 666 Intellectual Property Rights 668 The IETF takes no position regarding the validity or scope of any 669 Intellectual Property Rights or other rights that might be claimed to 670 pertain to the implementation or use of the technology described in 671 this document or the extent to which any license under such rights 672 might or might not be available; nor does it represent that it has 673 made any independent effort to identify any such rights. Information 674 on the procedures with respect to rights in RFC documents can be 675 found in BCP 78 and BCP 79. 677 Copies of IPR disclosures made to the IETF Secretariat and any 678 assurances of licenses to be made available, or the result of an 679 attempt made to obtain a general license or permission for the use of 680 such proprietary rights by implementers or users of this 681 specification can be obtained from the IETF on-line IPR repository at 682 http://www.ietf.org/ipr. 684 The IETF invites any interested party to bring to its attention any 685 copyrights, patents or patent applications, or other proprietary 686 rights that may cover technology that may be required to implement 687 this standard. Please address the information to the IETF at 688 ietf-ipr@ietf.org. 690 Full Copyright 692 Copyright (C) The Internet Society (2004). This document is subject 693 to the rights, licenses and restrictions contained in BCP 78, and 694 except as set forth therein, the authors retain all their rights. 696 This document and the information contained herein are provided on an 697 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 698 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 699 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 700 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 701 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 702 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 704 This Internet Draft expires on 16 May 2005.