idnits 2.17.1 draft-ietf-ldapbis-url-09.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 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 677. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 683), 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 (4 January 2005) is 7051 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 523, but not defined == Missing Reference: 'RFC2396' is mentioned on line 631, but not defined ** Obsolete undefined reference: RFC 2396 (Obsoleted by RFC 3986) -- Looks like a reference, but probably isn't: '1' on line 602 == Missing Reference: 'RFC2732' is mentioned on line 632, but not defined ** Obsolete undefined 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-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) -- No information found for draft-fielding-uri-rfc2396bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC2396bis' -- 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 (~~), 8 warnings (==), 22 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: 4 July 2005 Opsware, Inc. 7 4 January 2005 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. Percent-Encoding............................................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.............................................11 71 11. Appendix A: Changes Since RFC 2255.............................11 72 11.1. Technical Changes...........................................11 73 11.2. Editorial Changes...........................................12 74 12. Appendix B: Changes Since Previous Document Revision...........14 75 12.1. Technical Changes...........................................14 76 12.2. Editorial Changes...........................................14 77 Intellectual Property Rights...................................14 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 [host [COLON port]] 111 [SLASH dn [QUESTION [attributes] 112 [QUESTION [scope] [QUESTION [filter] 113 [QUESTION extensions]]]]] 114 ; and are defined 115 ; in Sections 3.2.2 and 3.2.3 116 ; of [RFC2396bis]. 117 ; is from Section 3 of 118 ; [Filters], subject to the 119 ; provisions of the 120 ; "Percent-Encoding" section 121 ; below. 123 scheme = "ldap" 125 dn = distinguishedName ; From Section 3 of [LDAPDN], 126 ; subject to the provisions of 127 ; the "Percent-Encoding" 128 ; section below. 130 attributes = attrdesc *(COMMA attrdesc) 131 attrdesc = selector *(COMMA selector) 132 selector = attributeSelector ; From Section 4.5.1 of 133 ; [Protocol], subject to the 134 ; provisions of the 135 ; "Percent-Encoding" section 136 ; below. 138 scope = "base" / "one" / "sub" 139 extensions = extension *(COMMA extension) 140 extension = [EXCLAMATION] extype [EQUALS exvalue] 141 extype = oid ; From section 1.4 of [Models]. 143 exvalue = LDAPString ; From section 4.1.2 of 144 ; [Protocol], subject to the 145 ; provisions of the 146 ; "Percent-Encoding" section 147 ; below. 149 EXCLAMATION = %x21 ; exclamation mark ("!") 150 SLASH = %x2F ; forward slash ("/") 151 COLON = %x3A ; colon (":") 152 QUESTION = %x3F ; question mark ("?") 154 The "ldap" prefix indicates an entry or entries accessible from the 155 LDAP server running on the given hostname at the given portnumber. 156 Note that the may contain literal IPv6 addresses as specified 157 in Section 3.2.2 of [RFC2396bis]. 159 The is an LDAP Distinguished Name using the string format 160 described in [LDAPDN]. It identifies the base object of the LDAP 161 search or the target of a non-search operation. 163 The construct is used to indicate which attributes 164 should be returned from the entry or entries. 166 The construct is used to specify the scope of the search to 167 perform in the given LDAP server. The allowable scopes are "base" 168 for a base object search, "one" for a one-level search, or "sub" for 169 a subtree search. 171 The is used to specify the search filter to apply to entries 172 within the specified scope during the search. It has the format 173 specified in [Filters]. 175 The construct provides the LDAP URL with an 176 extensibility mechanism, allowing the capabilities of the URL to be 177 extended in the future. Extensions are a simple comma-separated list 178 of type=value pairs, where the =value portion MAY be omitted for 179 options not requiring it. Each type=value pair is a separate 180 extension. These LDAP URL extensions are not necessarily related to 181 any of the LDAP extension mechanisms. Extensions may be supported or 182 unsupported by the client resolving the URL. An extension prefixed 183 with a '!' character (ASCII 0x21) is critical. An extension not 184 prefixed with a '!' character is non-critical. 186 If an LDAP URL extension is implemented (that is, if the 187 implementation understands it and is able to use it), the 188 implementation MUST make use of it. If an extension is not 189 implemented and is marked critical, the implementation MUST NOT 190 process the URL. If an extension is not implemented and it not 191 marked critical, the implementation MUST ignore the extension. 193 The extension type () MAY be specified using the numeric OID 194 form (e.g., 1.2.3.4) or the descriptor form 195 (e.g., myLDAPURLExtension). Use of the form SHOULD be 196 restricted to registered object identifier descriptive names. See 197 [LDAPIANA] for registration details and usage guidelines for 198 descriptive names. 200 No LDAP URL extensions are defined in this document. Other documents 201 or a future version of this document MAY define one or more 202 extensions. 204 2.1. Percent-Encoding 206 A generated LDAP URL MUST consist only of the restricted set of 207 characters included in one of the following three productions defined 208 in [RFC2396bis]: 210 211 212 214 Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as 215 input. An octet MUST be encoded using the percent-encoding mechanism 216 described in section 2.1 of [RFC2396bis] in any of these situations: 218 The octet is not in the reserved set defined in section 2.2 of 219 [RFC2396bis] or in the unreserved set defined in section 2.3 of 220 [RFC2396bis]. 222 It is the single Reserved character '?' and occurs inside a , 223 , or other element of an LDAP URL. 225 It is a comma character ',' that occurs inside an . 227 Note that before the percent-encoding mechanism is applied, the 228 extensions component of the LDAP URL may contain one or more null 229 (zero) bytes. No other component may. 231 3. Defaults for Fields of the LDAP URL 233 Some fields of the LDAP URL are optional, as described above. In the 234 absence of any other specification, the following general defaults 235 SHOULD be used when a field is absent. Note that other documents MAY 236 specify different defaulting rules; for example, section 4.1.10 of 237 [Protocol] specifies a different rule for determining the correct DN 238 to use when it is absent in an LDAP URL that is returned as a 239 referral. 241 242 If no is given, the client must have some apriori knowledge 243 of an appropriate LDAP server to contact. 245 246 The default LDAP port is TCP port 389. 248 249 If no is given, the default is the zero-length DN, "". 251 252 If the part is omitted, all user attributes of the 253 entry or entries should be requested (e.g., by setting the 254 attributes field AttributeDescriptionList in the LDAP search 255 request to a NULL list, or by using the special 256 selector "*"). 258 259 If is omitted, a of "base" is assumed. 261 262 If is omitted, a filter of "(objectClass=*)" is assumed. 264 265 If is omitted, no extensions are assumed. 267 4. Examples 269 The following are some example LDAP URLs using the format defined 270 above. The first example is an LDAP URL referring to the University 271 of Michigan entry, available from an LDAP server of the client's 272 choosing: 274 ldap:///o=University%20of%20Michigan,c=US 276 The next example is an LDAP URL referring to the University of 277 Michigan entry in a particular ldap server: 279 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US 281 Both of these URLs correspond to a base object search of the 282 "o=University of Michigan,c=US" entry using a filter of 283 "(objectclass=*)", requesting all attributes. 285 The next example is an LDAP URL referring to only the postalAddress 286 attribute of the University of Michigan entry: 288 ldap://ldap1.example.net/o=University%20of%20Michigan, 289 c=US?postalAddress 291 The corresponding LDAP search operation is the same as in the 292 previous example, except that only the postalAddress attribute is 293 requested. 295 The next example is an LDAP URL referring to the set of entries found 296 by querying the given LDAP server on port 6666 and doing a subtree 297 search of the University of Michigan for any entry with a common name 298 of "Babs Jensen", retrieving all attributes: 300 ldap://ldap1.example.net:6666/o=University%20of%20Michigan, 301 c=US??sub?(cn=Babs%20Jensen) 303 The next example is an LDAP URL referring to all children of the c=GB 304 entry: 306 LDAP://ldap1.example.com/c=GB?objectClass?ONE 308 The objectClass attribute is requested to be returned along with the 309 entries, and the default filter of "(objectclass=*)" is used. 311 The next example is an LDAP URL to retrieve the mail attribute for 312 the LDAP entry named "o=Question?,c=US" is given below, illustrating 313 the use of the percent-encoding mechanism on the reserved character 314 '?'. 316 ldap://ldap2.example.com/o=Question%3f,c=US?mail 318 The next example (which is broken into two lines for readability) 319 illustrates the interaction between the LDAP string representation of 320 filters quoting mechanism and URL quoting mechanisms. 322 ldap://ldap3.example.com/o=Babsco,c=US 323 ???(four-octet=%5c00%5c00%5c00%5c04) 325 The filter in this example uses the LDAP escaping mechanism of \ to 326 encode three zero or null bytes in the value. In LDAP, the filter 327 would be written as (four-octet=\00\00\00\04). Because the \ 328 character must be escaped in a URL, the \'s are percent-encoded as 329 %5c (or %5C) in the URL encoding. 331 The next example illustrates the interaction between the LDAP string 332 representation of DNs quoting mechanism and URL quoting mechanisms. 334 ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US 336 The DN encoded in the above URL is: 338 o=An Example\2C Inc.,c=US 340 That is, the left-most RDN value is: 342 An Example, Inc. 344 The following three URLs that are equivalent, assuming that the 345 defaulting rules specified in section 4 of this document are used: 347 ldap://ldap.example.net 348 ldap://ldap.example.net/ 349 ldap://ldap.example.net/? 351 These three URLs all point to the root DSE on the ldap.example.net 352 server. 354 The final two examples show use of a hypothetical, experimental bind 355 name extension (the value associated with the extension is an LDAP DN). 357 ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com 358 ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com 360 The two URLs are the same, except that the second one marks the 361 e-bindname extension as critical. Notice the use of the 362 percent-encoding mechanism to encode the commas within the 363 distinguished name value in the e-bindname extension. 365 5. Security Considerations 367 General URL security considerations discussed in [RFC2396bis] are 368 relevant for LDAP URLs. 370 The use of security mechanisms when processing LDAP URLs requires 371 particular care, since clients may encounter many different servers 372 via URLs, and since URLs are likely to be processed automatically, 373 without user intervention. A client SHOULD have a user-configurable 374 policy that controls which servers the client will establish LDAP 375 sessions with using which security mechanisms, and SHOULD NOT 376 establish LDAP sessions that are inconsistent with this policy. If a 377 client chooses to reuse an existing LDAP session when resolving one 378 or more LDAP URLs, it MUST ensure that the session is compatible with 379 the URL and that no security policies are violated. 381 Sending authentication information, no matter the mechanism, may 382 violate a user's privacy requirements. In the absence of specific 383 policy permitting authentication information to be sent to a server, 384 a client should use an anonymous LDAP session. (Note that clients 385 conforming to previous LDAP URL specifications, where all LDAP 386 sessions are anonymous and unprotected, are consistent with this 387 specification; they simply have the default security policy.) Simply 388 opening a transport connection to another server may violate some 389 users' privacy requirements, so clients should provide the user with 390 a way to control URL processing. 392 Some authentication methods, in particular reusable passwords sent to 393 the server, may reveal easily-abused information to the remote server 394 or to eavesdroppers in transit, and should not be used in URL 395 processing unless explicitly permitted by policy. Confirmation by 396 the human user of the use of authentication information is 397 appropriate in many circumstances. Use of strong authentication 398 methods that do not reveal sensitive information is much preferred. 399 If the URL represents a referral for an update operation, strong 400 authentication methods SHOULD be used. Please refer to the Security 401 Considerations section of [AuthMeth] for more information. 403 The LDAP URL format allows the specification of an arbitrary LDAP 404 search operation to be performed when evaluating the LDAP URL. 405 Following an LDAP URL may cause unexpected results, for example, the 406 retrieval of large amounts of data, the initiation of a long-lived 407 search, etc. The security implications of resolving an LDAP URL are 408 the same as those of resolving an LDAP search query. 410 6. IANA Considerations 412 This document has no actions for IANA. 414 7. Normative References 416 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods", 417 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a 418 work in progress. 420 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 421 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work 422 in progress. 424 [Filters] Smith, M. and Howes, T., "LDAP: String Representation of 425 Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in 426 progress. 428 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 429 Requirement Levels," RFC 2119, BCP 14, March 1997. 431 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 432 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 434 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 435 Specifications: ABNF", RFC 2234, November 1997. 437 [RFC2396bis] 438 Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform 439 Resource Identifiers (URI): Generic Syntax", 440 draft-fielding-uri-rfc2396bis-xx.txt, a work in progress. 442 [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road 443 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 445 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 446 RFC 3629, November 2003. 448 8. Informative References 450 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", 451 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. None. 453 9. Acknowledgements 455 The LDAP URL format was originally defined at the University of 456 Michigan. This material is based upon work supported by the National 457 Science Foundation under Grant No. NCR-9416667. The support of both 458 the University of Michigan and the National Science Foundation is 459 gratefully acknowledged. 461 This document is an update to RFC 2255 by Tim Howes and Mark Smith. 462 Changes included in this revised specification are based upon 463 discussions among the authors, discussions within the LDAP (v3) 464 Revision Working Group (ldapbis), and discussions within other IETF 465 Working Groups. The contributions of individuals in these working 466 groups is gratefully acknowledged. Several people in particular have 467 made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, 468 Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special 469 thanks for their contributions. 471 10. Authors' Addresses 473 Mark Smith, Editor 474 Pearl Crescent, LLC 475 447 Marlpool Dr. 476 Saline, MI 48176 477 USA 478 +1 734 944-2856 479 mcs@pearlcrescent.com 481 Tim Howes 482 Opsware, Inc. 483 599 N. Mathilda Ave. 484 Sunnyvale, CA 94085 485 USA 486 +1 408 744-7509 487 howes@opsware.com 489 11. Appendix A: Changes Since RFC 2255 491 11.1. Technical Changes 493 The following technical changes were made to the contents of the "URL 494 Definition" section: 496 Revised all of the ABNF to use common productions from [Models]. 498 Replaced references to [RFC2396] with a reference to [RFC2396bis] 499 (this allows literal IPv6 addresses to be used inside the 500 portion of the URL, and a note was added to remind the reader of this 501 enhancement). Referencing [RFC2396bis] required changes to the ABNF 502 and text so that productions that are no longer defined by 503 [RFC2396bis] are not used. For example, is not defined by 504 [RFC2396bis] so it has been replaced with host [COLON port]. Note: 505 [RFC2396bis] includes new definitions for the "Reserved" and 506 "Unreserved" sets of characters, and the net result is that the 507 following two additional characters should be percent-encoded when 508 they appear anywhere in the data used to construct an LDAP URL: "[" 509 and "]" (these two characters were first added to the Reserved set by 510 RFC 2732). 512 Changed the definition of to refer to 513 from [Protocol]. This allows use of "*" in the part of 514 the URL. It is believed that existing implementations of RFC 2255 515 already support this. 517 Avoided use of (bracketed-string) productions in the 518 , , , and rules. 520 Changed the ABNF for to group the component with the 521 preceding . 523 Changed the rule to be an from [Models]. 525 Changed the text about extension types so it references [LDAPIANA]. 526 Reordered rules to more closely follow the order the elements appear 527 in the URL. 529 "Bindname Extension": removed due to lack of known implementations. 531 11.2. Editorial Changes 533 Changed document title to include "LDAP:" prefix. 535 IESG Note: removed note about lack of satisfactory mandatory 536 authentication mechanisms. 538 "Status of this Memo" section: updated boilerplate to match current 539 I-D guidelines. 541 "Abstract" section: separated from introductory material. 543 "Table of Contents" and "IANA Considerations" sections: added. 545 "Introduction" section: new section; separated from the Abstract. 546 Changed the text indicate that RFC 2255 is replaced by this document 547 (instead of RFC 1959). Added text to indicate that LDAP URLs are 548 used for references and referrals. Fixed typo (replaced the nonsense 549 phrase "to perform to retrieve" with "used to retrieve"). Added a 550 note to let the reader know that not all of the parameters of the 551 LDAP search operation described in [Protocol] can be expressed using 552 this format. 554 "URL Definition" section: removed second copy of grammar 555 and following two paragraphs (editorial error in RFC 2255). Fixed 556 line break within '!' sequence. Reformatted the ABNF to improve 557 readability by aligning comments and adding some blank lines. 558 Replaced "residing in the LDAP server" with "accessible from the LDAP 559 server" in the sentence immediately following the ABNF. Removed the 560 sentence "Individual attrdesc names are as defined for 561 AttributeDescription in [Protocol]." because [Protocol]'s 562 is now used directly in the ABNF. Reworded last 563 paragraph to clarify which characters must be percent-encoded. Added 564 text to indicate that LDAP URLs are used for references and 565 referrals. Added text that refers to the ABNF from RFC 2234. 566 Clarified and strengthened the requirements with respect to 567 processing of URLs that contain implements and not implemented 568 extensions (the approach now closely matches that specified in 569 [Protocol] for LDAP controls). 571 "Defaults for Fields of the LDAP URL" section: added; formed by 572 moving text about defaults out of the "URL Definition" section. 573 Replaced direct reference to the attribute name "*" with a reference 574 to the special selector "*" defined in [Protocol]. 576 "URL Processing" section: removed. 578 "Examples" section: Modified examples to use example.com and 579 example.net hostnames. Added missing '?' to the LDAP URL example 580 whose filter contains three null bytes. Removed space after one 581 comma within a DN. Revised the bindname example to use e-bindname. 582 Changed the name of an attribute used in one example from "int" to 583 "four-octet" to avoid potential confusion. Added an example that 584 demonstrates the interaction between DN escaping and URL 585 percent-encoding. Added some examples to show URL equivalence with 586 respect to the portion of the URL. Used uppercase in some 587 examples to remind the reader that some tokens are case-insensitive. 589 "Security Considerations" section: Added a note about connection 590 reuse. Added a note about using strong authentication methods for 591 updates. Added a reference to [AuthMeth]. Added note that simply 592 opening a connection may violate some users' privacy requirements. 593 Adopted the working group's revised LDAP terminology specification by 594 replacing the word "connection" with "LDAP session" or "LDAP 595 connection" as appropriate. 597 "Acknowledgements" section: added statement about this being an 598 update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and 599 Hallvard Furuseth. 601 "Normative References" section: renamed from "References" per new RFC 602 guidelines. Changed from [1] style to [Protocol] style throughout the 603 document. Added references to RFC 2234 and RFC 3629. Updated all 604 RFC 1738 references to point to the appropriate sections within 605 [RFC2396bis]. Updated the LDAP references to refer to LDAPBis WG 606 documents. Removed the reference to the LDAP Attribute Syntaxes 607 document and added references to the [AuthMeth], [LDAPIANA], and 608 [Roadmap] documents. 610 "Informative References" section: added. 612 Header and "Authors' Addresses" sections: added "editor" next to Mark 613 Smith's name. Updated affiliation and contact information. 615 Copyright: updated the year. 617 Throughout the document: surrounded the names of all ABNF productions 618 with "<" and ">" where they are used in descriptive text. 620 12. Appendix B: Changes Since Previous Document Revision 622 This appendix lists all changes relative to the previously published 623 revision, draft-ietf-ldapbis-url-08.txt. Note that when appropriate 624 these changes are also included in Appendix A, but are also included 625 here for the benefit of the people who have already reviewed 626 draft-ietf-ldapbis-url-08.txt. This section will be removed before 627 this document is published as an RFC. 629 12.1. Technical Changes 631 Throughout the document: Replaced references to [RFC2396] and 632 [RFC2732] with references to [RFC2396bis]. This required changes to 633 the ABNF and text so that productions that are no longer defined by 634 [RFC2396bis] are not used. For example, is not defined by 635 [RFC2396bis] so it has been replaced with host [COLON port]. Note: 636 [RFC2396bis] includes new definitions for the "Reserved" and 637 "Unreserved" sets of characters, and the net result is that the 638 following two additional characters should be percent-encoded when 639 they appear anywhere in the data used to construct an LDAP URL: "[" 640 and "]" (these two characters were first added to the Reserved set by 641 RFC 2732). 643 12.2. Editorial Changes 645 Throughout the document: Replaced phrases like "Escaping using the % 646 method" with "Percent-encoding" to be consistent with the terminology 647 used in [RFC2396bis]. 649 "URL Definition" section: For consistency, replaced all occurrences 650 of the phrase 'see the "Percent-Encoding" section below' with 651 'subject to the provisions of the "Percent-Encoding" section below.' 653 Updated the copyright year to 2005. 655 Intellectual Property Rights 657 The IETF takes no position regarding the validity or scope of any 658 Intellectual Property Rights or other rights that might be claimed to 659 pertain to the implementation or use of the technology described in 660 this document or the extent to which any license under such rights 661 might or might not be available; nor does it represent that it has 662 made any independent effort to identify any such rights. Information 663 on the procedures with respect to rights in RFC documents can be 664 found in BCP 78 and BCP 79. 666 Copies of IPR disclosures made to the IETF Secretariat and any 667 assurances of licenses to be made available, or the result of an 668 attempt made to obtain a general license or permission for the use of 669 such proprietary rights by implementers or users of this 670 specification can be obtained from the IETF on-line IPR repository at 671 http://www.ietf.org/ipr. 673 The IETF invites any interested party to bring to its attention any 674 copyrights, patents or patent applications, or other proprietary 675 rights that may cover technology that may be required to implement 676 this standard. Please address the information to the IETF at 677 ietf-ipr@ietf.org. 679 Full Copyright 681 Copyright (C) The Internet Society (2005). This document is subject 682 to the rights, licenses and restrictions contained in BCP 78, and 683 except as set forth therein, the authors retain all their rights. 685 This document and the information contained herein are provided on an 686 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 687 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 688 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 689 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 690 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 693 This Internet Draft expires on 4 July 2005.