idnits 2.17.1 draft-ietf-ldapbis-url-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 650. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 656), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** Found boilerplate matching RFC 3979, Section 5, paragraph 1 (on line 637), which is fine, but *also* found old RFC 2026, Section 10.4A text on line 450. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 650), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 456. ** 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: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 1 boilerplate, a section with a similar start was also found: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == 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 (24 October 2004) is 7124 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 501, but not defined -- Looks like a reference, but probably isn't: '1' on line 590 -- 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-bcp64-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPIANA' -- 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' Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Mark Smith, Editor 2 Request for Comments: DRAFT Pearl Crescent, LLC 3 Obsoletes: RFC 2255 Tim Howes 4 Expires: 24 April 2005 Opsware, Inc. 6 24 October 2004 8 LDAP: Uniform Resource Locator 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she become 16 aware will be disclosed, in accordance with RFC 3668. 18 This document is intended to be published as a Standards Track RFC, 19 replacing RFC 2255. Distribution of this memo is unlimited. 20 Technical discussion of this document will take place on the IETF 21 LDAP (v3) Revision (ldapbis) Working Group mailing list 22 . Please send editorial comments directly 23 to the editor . 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than a "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Please see the Full Copyright section near the end of this document 43 for more information. 45 Abstract 47 This document describes a format for an LDAP Uniform Resource Locator 48 (URL). An LDAP URL describes an LDAP search operation that is used 49 to retrieve information from an LDAP directory, or, in the context of 50 an LDAPv3 referral or reference, an LDAP URL describes a service 51 where an LDAP operation may be progressed. 53 Table of Contents 55 Status of this Memo............................................1 56 Abstract.......................................................2 57 Table of Contents..............................................2 58 1. Introduction...................................................2 59 2. URL Definition.................................................3 60 2.1. Escaping Using the % Method.................................5 61 3. Defaults for Fields of the LDAP URL............................5 62 4. Examples.......................................................6 63 5. Security Considerations........................................8 64 6. IANA Considerations............................................9 65 7. Normative References...........................................9 66 8. Informative References.........................................10 67 9. Intellectual Property Rights...................................10 68 10. Acknowledgements...............................................10 69 11. Authors' Addresses.............................................11 70 12. Appendix A: Changes Since RFC 2255.............................11 71 12.1. Technical Changes...........................................11 72 12.2. Editorial Changes...........................................12 73 13. Appendix B: Changes Since Previous Document Revision...........13 74 13.1. Editorial Changes...........................................14 75 14. Intellectual Property Rights...................................14 76 15. Full Copyright.................................................14 78 1. Introduction 80 LDAP is the Lightweight Directory Access Protocol, defined in 81 [Protocol]. This document specifies the LDAP URL format for version 82 3 of LDAP and clarifies how LDAP URLs are resolved. This document 83 also defines an extension mechanism for LDAP URLs, so that future 84 documents can extend their functionality, for example, to provide 85 access to new LDAPv3 extensions as they are defined. Note: not all 86 of the parameters of the LDAP search operation described in 87 [Protocol] can be expressed using the format defined in this 88 document. 90 This document is an integral part of the LDAP Technical Specification 91 [Roadmap]. 93 This document replaces RFC 2255. See Appendix A for a list of changes 94 relative to RFC 2255. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in BCP 14 [RFC2119]. 100 2. URL Definition 102 An LDAP URL begins with the protocol prefix "ldap" and is defined by 103 the following grammar, following the ABNF notation defined in 104 [RFC2234]. 106 ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn 107 [QUESTION [attributes] [QUESTION [scope] 108 [QUESTION [filter] [QUESTION extensions]]]]] 109 scheme = "ldap" 110 hostport = 111 ; As updated by [RFC2732] to allow 112 ; IPv6 literal addresses 113 dn = 114 ; See the "Escaping Using the % Method" 115 ; section below. 116 attributes = attrdesc *(COMMA attrdesc) 117 attrdesc = 119 / ASTERISK 120 ; See the "Escaping Using the % Method" 121 ; section below. 122 scope = "base" / "one" / "sub" 123 filter = 124 ; See the "Escaping Using the % Method" 125 ; section below. 126 extensions = extension *(COMMA extension) 127 extension = [EXCLAMATION] extype [EQUALS exvalue] 128 extype = oid / oiddescr 129 exvalue = 130 ; See the "Escaping Using the % Method" 131 ; section below. 132 oid = 133 oiddescr = 135 EXCLAMATION = %x21 ; exclamation mark ("!") 136 ASTERISK = %x2A ; asterisk ("*") 137 SLASH = %x2F ; forward slash ("/") 138 COLON = %x3A ; colon (":") 139 QUESTION = %x3F ; question mark ("?") 141 The "ldap" prefix indicates an entry or entries accessible from the 142 LDAP server running on the given hostname at the given portnumber. 143 Note that the hostport may contain literal IPv6 addresses as 144 specified in [RFC2732]. 146 The dn is an LDAP Distinguished Name using the string format 147 described in [LDAPDN]. It identifies the base object of the LDAP 148 search or the target of a non-search operation. 150 The attributes construct is used to indicate which attributes should 151 be returned from the entry or entries. Individual attrdesc names are 152 as defined for AttributeDescription in [Protocol]. 154 The scope construct is used to specify the scope of the search to 155 perform in the given LDAP server. The allowable scopes are "base" 156 for a base object search, "one" for a one-level search, or "sub" for 157 a subtree search. 159 The filter is used to specify the search filter to apply to entries 160 within the specified scope during the search. It has the format 161 specified in [Filters]. 163 The extensions construct provides the LDAP URL with an extensibility 164 mechanism, allowing the capabilities of the URL to be extended in the 165 future. Extensions are a simple comma-separated list of type=value 166 pairs, where the =value portion MAY be omitted for options not 167 requiring it. Each type=value pair is a separate extension. These 168 LDAP URL extensions are not necessarily related to any of the LDAPv3 169 extension mechanisms. Extensions may be supported or unsupported by 170 the client resolving the URL. An extension prefixed with a '!' 171 character (ASCII 0x21) is critical. An extension not prefixed with a 172 '!' character is non-critical. 174 If an LDAP URL extension is implemented (that is, if the 175 implementation understands it and is able to use it), the 176 implementation MUST make use of it. If an extension is not 177 implemented and is marked critical, the implementation MUST NOT 178 process the URL. If an extension is not implemented and it not 179 marked critical, the implementation MUST ignore the extension. 181 The extension type (extype) MAY be specified using the oid form 182 (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use 183 of the oiddesc form SHOULD be restricted to registered object 184 identifier descriptive names. See [LDAPIANA] for registration 185 details and usage guidelines for descriptive names. 187 No LDAP URL extensions are defined in this document. Other documents 188 or a future version of this document MAY define one or more 189 extensions. 191 2.1. Escaping Using the % Method 193 A generated LDAP URL MUST consist only of the restricted set of 194 characters included in the uric production that is defined in section 195 2 of [RFC2396]. Implementations SHOULD accept other valid UTF-8 196 strings [RFC3629] as input. An octet MUST be escaped using the % 197 method described in section 2.4 of [RFC2396] in any of these 198 situations: 200 The octet is not in the reserved set defined in section 2.2 of 201 [RFC2396] or in the unreserved set defined in section 2.3 of 202 [RFC2396]. 204 It is the single Reserved character '?' and occurs inside a dn, 205 filter, or other element of an LDAP URL. 207 It is a comma character ',' that occurs inside an extension value. 209 Note that before the % method of escaping is applied, the extensions 210 component of the LDAP URL may contain one or more null (zero) bytes. 211 No other component may. 213 3. Defaults for Fields of the LDAP URL 215 Some fields of the LDAP URL are optional, as described above. In the 216 absence of any other specification, the following general defaults 217 SHOULD be used when a field is absent. Note: other documents MAY 218 specify different defaulting rules; for example, section 4.1.10 of 219 [Protocol] specifies a different rule for determining the correct DN 220 to use when it is absent in an LDAP URL that is returned as a 221 referral. 223 hostport 224 The default LDAP port is TCP port 389. If no hostport is given, 225 the client must have some apriori knowledge of an appropriate LDAP 226 server to contact. 228 dn 229 If no dn is given, the default is the zero-length DN, "". 231 attributes 232 If the attributes part is omitted, all user attributes of the 233 entry or entries should be requested (e.g., by setting the 234 attributes field AttributeDescriptionList in the LDAP search 235 request to a NULL list, or (in LDAPv3) by requesting the special 236 attribute name "*"). 238 scope 239 If scope is omitted, a scope of "base" is assumed. 241 filter 242 If filter is omitted, a filter of "(objectClass=*)" is assumed. 244 extensions 245 If extensions is omitted, no extensions are assumed. 247 4. Examples 249 The following are some example LDAP URLs using the format defined 250 above. The first example is an LDAP URL referring to the University 251 of Michigan entry, available from an LDAP server of the client's 252 choosing: 254 ldap:///o=University%20of%20Michigan,c=US 256 The next example is an LDAP URL referring to the University of 257 Michigan entry in a particular ldap server: 259 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US 261 Both of these URLs correspond to a base object search of the 262 "o=University of Michigan,c=US" entry using a filter of 263 "(objectclass=*)", requesting all attributes. 265 The next example is an LDAP URL referring to only the postalAddress 266 attribute of the University of Michigan entry: 268 ldap://ldap1.example.net/o=University%20of%20Michigan, 269 c=US?postalAddress 271 The corresponding LDAP search operation is the same as in the 272 previous example, except that only the postalAddress attribute is 273 requested. 275 The next example is an LDAP URL referring to the set of entries found 276 by querying the given LDAP server on port 6666 and doing a subtree 277 search of the University of Michigan for any entry with a common name 278 of "Babs Jensen", retrieving all attributes: 280 ldap://ldap1.example.net:6666/o=University%20of%20Michigan, 281 c=US??sub?(cn=Babs%20Jensen) 283 The next example is an LDAP URL referring to all children of the c=GB 284 entry: 286 ldap://ldap1.example.com/c=GB?objectClass?one 288 The objectClass attribute is requested to be returned along with the 289 entries, and the default filter of "(objectclass=*)" is used. 291 The next example is an LDAP URL to retrieve the mail attribute for 292 the LDAP entry named "o=Question?,c=US" is given below, illustrating 293 the use of the escaping mechanism on the reserved character '?'. 295 ldap://ldap2.example.com/o=Question%3f,c=US?mail 297 The next example (which is broken into two lines for readability) 298 illustrates the interaction between the LDAP string representation of 299 filters quoting mechanism and URL quoting mechanisms. 301 ldap://ldap3.example.com/o=Babsco,c=US 302 ???(four-octet=%5c00%5c00%5c00%5c04) 304 The filter in this example uses the LDAP escaping mechanism of \ to 305 encode three zero or null bytes in the value. In LDAP, the filter 306 would be written as (four-octet=\00\00\00\04). Because the \ 307 character must be escaped in a URL, the \'s are escaped as %5c in the 308 URL encoding. 310 The next example illustrates the interaction between the LDAP string 311 representation of DNs quoting mechanism and URL quoting mechanisms. 313 ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US 315 The DN encoded in the above URL is: 317 o=An Example\2c Inc.,c=US 319 That is, the left-most RDN value is: 321 An Example, Inc. 323 The following three URLs that are equivalent, assuming that the 324 defaulting rules specified in section 4 of this document are used: 326 ldap://ldap.example.net 327 ldap://ldap.example.net/ 328 ldap://ldap.example.net/? 330 These three URLs all point to the root DSE on the ldap.example.net 331 server. 333 The final two examples show use of a hypothetical, experimental bind 334 name extension (the value associated with the extension is an LDAP DN). 336 ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com 337 ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com 339 The two URLs are the same, except that the second one marks the 340 e-bindname extension as critical. Notice the use of the % encoding 341 method to encode the commas within the distinguished name value in 342 the e-bindname extension. 344 5. Security Considerations 346 General URL security considerations discussed in [RFC2396] are 347 relevant for LDAP URLs. 349 The use of security mechanisms when processing LDAP URLs requires 350 particular care, since clients may encounter many different servers 351 via URLs, and since URLs are likely to be processed automatically, 352 without user intervention. A client SHOULD have a user-configurable 353 policy about which servers to connect to using which security 354 mechanisms, and SHOULD NOT make connections that are inconsistent 355 with this policy. If a client chooses to reuse an existing 356 connection when resolving one or more LDAP URL, it MUST ensure that 357 the connection is compatible with the URL and that no security 358 policies are violated. 360 Sending authentication information, no matter the mechanism, may 361 violate a user's privacy requirements. In the absence of specific 362 policy permitting authentication information to be sent to a server, 363 a client should use an anonymous connection. (Note that clients 364 conforming to previous LDAP URL specifications, where all connections 365 are anonymous and unprotected, are consistent with this 366 specification; they simply have the default security policy.) Simply 367 opening a connection to another server may violate some users' 368 privacy requirements, so clients should provide the user with a way 369 to control URL processing. 371 Some authentication methods, in particular reusable passwords sent to 372 the server, may reveal easily-abused information to the remote server 373 or to eavesdroppers in transit, and should not be used in URL 374 processing unless explicitly permitted by policy. Confirmation by 375 the human user of the use of authentication information is 376 appropriate in many circumstances. Use of strong authentication 377 methods that do not reveal sensitive information is much preferred. 378 If the URL represents a referral for an update operation, strong 379 authentication methods SHOULD be used. Please refer to the Security 380 Considerations section of [AuthMeth] for more information. 382 The LDAP URL format allows the specification of an arbitrary LDAP 383 search operation to be performed when evaluating the LDAP URL. 384 Following an LDAP URL may cause unexpected results, for example, the 385 retrieval of large amounts of data, the initiation of a long-lived 386 search, etc. The security implications of resolving an LDAP URL are 387 the same as those of resolving an LDAP search query. 389 6. IANA Considerations 391 This document has no actions for IANA. 393 7. Normative References 395 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods", 396 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a 397 work in progress. 399 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 400 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work 401 in progress. 403 [Filters] Smith, M. and Howes, T., "LDAP: String Representation of 404 Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in 405 progress. 407 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", 408 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 410 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 411 Requirement Levels," RFC 2119, BCP 14, March 1997. 413 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 414 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 416 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 417 Specifications: ABNF", RFC 2234, November 1997. 419 [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 420 Resource Identifiers (URI): Generic Syntax", RFC 2396, 421 August 1998. 423 [RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Literal 424 IPv6 Addresses in URL's", RFC 2732, December 1999. 426 [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road 427 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 429 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 430 RFC 3629, November 2003. 432 8. Informative References 434 None. 436 9. Intellectual Property Rights 438 The IETF takes no position regarding the validity or scope of any 439 intellectual property or other rights that might be claimed to 440 pertain to the implementation or use of the technology described in 441 this document or the extent to which any license under such rights 442 might or might not be available; neither does it represent that it 443 has made any effort to identify any such rights. Information on the 444 IETF's procedures with respect to rights in standards-track and 445 standards-related documentation can be found in BCP-11. Copies of 446 claims of rights made available for publication and any assurances of 447 licenses to be made available, or the result of an attempt made to 448 obtain a general license or permission for the use of such 449 proprietary rights by implementors or users of this specification can 450 be obtained from the IETF Secretariat. 452 The IETF invites any interested party to bring to its attention any 453 copyrights, patents or patent applications, or other proprietary 454 rights which may cover technology that may be required to practice 455 this standard. Please address the information to the IETF Executive 456 Director. 458 10. Acknowledgements 460 The LDAP URL format was originally defined at the University of 461 Michigan. This material is based upon work supported by the National 462 Science Foundation under Grant No. NCR-9416667. The support of both 463 the University of Michigan and the National Science Foundation is 464 gratefully acknowledged. 466 This document is an update to RFC 2255 by Tim Howes and Mark Smith. 467 Changes included in this revised specification are based upon 468 discussions among the authors, discussions within the LDAP (v3) 469 Revision Working Group (ldapbis), and discussions within other IETF 470 Working Groups. The contributions of individuals in these working 471 groups is gratefully acknowledged. Several people in particular have 472 made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, 473 Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special 474 thanks for their contributions. 476 11. Authors' Addresses 478 Mark Smith, Editor 479 Pearl Crescent, LLC 480 447 Marlpool Dr. 481 Saline, MI 48176 482 USA 483 +1 734 944-2856 484 mcs@pearlcrescent.com 486 Tim Howes 487 Opsware, Inc. 488 599 N. Mathilda Ave. 489 Sunnyvale, CA 94085 490 USA 491 +1 408 744-7509 492 howes@opsware.com 494 12. Appendix A: Changes Since RFC 2255 496 12.1. Technical Changes 498 The following technical changes were made to the contents of the "URL 499 Definition" section: 501 Revised all of the ABNF to use common productions from [Models]. 503 Added note and references to [RFC2732] to allow literal IPv6 504 addresses inside the hostport portion of the URL. 506 Added missing ASTERISK as an alternative for the attrdesc part of the 507 URL. It is believed that existing implementations of RFC 2255 508 already support this. 510 Added angle brackets around free-form prose in the "dn", "hostport", 511 "attrdesc", "filter", and "exvalue" rules. 513 Changed the ABNF for ldapurl to group the dn component with the 514 preceding slash. 516 Changed the extype rule to be an LDAPOID from [Protocol] or an OID 517 description from [LDAPIANA]. 519 Changed the text about extension types so it references [LDAPIANA]. 520 Reordered rules to more closely follow the order the elements appear 521 in the URL. 523 "Bindname Extension": removed due to lack of known implementations. 525 12.2. Editorial Changes 527 Changed document title to include "LDAP:" prefix. 529 IESG Note: removed note about lack of satisfactory mandatory 530 authentication mechanisms. 532 "Status of this Memo" section: updated boilerplate to match current 533 I-D guidelines. 535 "Abstract" section: separated from introductory material. 537 "Table of Contents" and "IANA Considerations" sections: added. 539 "Introduction" section: new section; separated from the Abstract. 540 Changed the text indicate that RFC 2255 is replaced by this document 541 (instead of RFC 1959). Added text to indicate that LDAP URLs are 542 used for references and referrals. Fixed typo (replaced the nonsense 543 phrase "to perform to retrieve" with "used to retrieve"). Added a 544 note to let the reader know that not all of the parameters of the 545 LDAP search operation described in [Protocol] can be expressed using 546 this format. 548 "URL Definition" section: removed second copy of ldapurl grammar and 549 following two paragraphs (editorial error in RFC 2255). Fixed line 550 break within '!' sequence. Replaced "residing in the LDAP server" 551 with "accessible from the LDAP server" in the sentence immediately 552 following the ABNF. Reworded last paragraph to clarify which 553 characters must be URL escaped. Added text to indicate that LDAP 554 URLs are used for references and referrals. Added text that refers 555 to the ABNF from RFC 2234. Clarified and strengthened the 556 requirements with respect to processing of URLs that contain 557 implements and not implemented extensions (the approach now closely 558 matches that specified in [Protocol] for LDAP controls). 560 "Defaults for Fields of the LDAP URL" section: added; formed by 561 moving text about defaults out of the "URL Definition" section. 563 "URL Processing" section: clarified that connections MAY be reused 564 only if the open connection is compatible with the URL. Added text 565 to indicate that use of security services is encouraged and that they 566 SHOULD be used when updates are involved. Removed "dn" from 567 discussion of authentication methods. Added note that the client MAY 568 interrogate the server to determine the most appropriate method. 570 "Examples" section: Modified examples to use example.com and 571 example.net hostnames. Added missing '?' to the LDAP URL example 572 whose filter contains three null bytes. Removed space after one 573 comma within a DN. Revised the bindname example to use e-bindname. 574 Changed the name of an attribute used in one example from "int" to 575 "four-octet" to avoid potential confusion. Added an example that 576 demonstrates the interaction between DN escaping and URL escaping. 577 Added some examples to show URL equivalence with respect to the dn 578 portion of the URL. 580 "Security Considerations" section: Added a note about connection 581 reuse. Added a note about using strong authentication methods for 582 updates. Added a reference to [AuthMeth]. Added note that simply 583 opening a connection may violate some users' privacy requirements. 585 "Acknowledgements" section: added statement about this being an 586 update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and 587 Hallvard Furuseth. 589 "Normative References" section: renamed from "References" per new RFC 590 guidelines. Changed from [1] style to [Protocol] style throughout the 591 document. Added references to RFC 2234, RFC 2732, and RFC 3629. 592 Updated all RFC 1738 references to point to the appropriate sections 593 within RFC 2396. Updated the LDAP references to refer to LDAPBis WG 594 documents. Removed the reference to the LDAP Attribute Syntaxes 595 document and added references to the [AuthMeth], [LDAPIANA], and 596 [Roadmap] documents. 598 "Informative References" section: added for clarity. 600 Header and "Authors' Addresses" sections: added "editor" next to Mark 601 Smith's name. Updated affiliation and contact information. 603 Copyright: updated the year. 605 13. Appendix B: Changes Since Previous Document Revision 607 This appendix lists all changes relative to the previously published 608 revision, draft-ietf-ldapbis-url-06.txt. Note that when appropriate 609 these changes are also included in Appendix A, but are also included 610 here for the benefit of the people who have already reviewed 611 draft-ietf-ldapbis-url-06.txt. This section will be removed before 612 this document is published as an RFC. 614 13.1. Editorial Changes 616 "Status of this Memo" section: replaced RFC 3668 (IPR) boilerplate 617 paragraph with the version that says "each author" instead of "I." 619 "URL Definition" section: replaced phrases such as "recognized by" 620 with "implemented by" when referring to LDAP URL extensions. 622 "URL Definition" section: added the following two sentences at the 623 end of the subsection on "Escaping Using the % Method": 624 Note that before the % method of escaping is applied, the 625 extensions component of the LDAP URL may contain one or more null 626 (zero) bytes. No other component may. 628 14. Intellectual Property Rights 630 The IETF takes no position regarding the validity or scope of any 631 Intellectual Property Rights or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; nor does it represent that it has 635 made any independent effort to identify any such rights. Information 636 on the procedures with respect to rights in RFC documents can be 637 found in BCP 78 and BCP 79. 639 Copies of IPR disclosures made to the IETF Secretariat and any 640 assurances of licenses to be made available, or the result of an 641 attempt made to obtain a general license or permission for the use of 642 such proprietary rights by implementers or users of this 643 specification can be obtained from the IETF on-line IPR repository at 644 http://www.ietf.org/ipr. 646 The IETF invites any interested party to bring to its attention any 647 copyrights, patents or patent applications, or other proprietary 648 rights that may cover technology that may be required to implement 649 this standard. Please address the information to the IETF at 650 ietf-ipr@ietf.org. 652 15. Full Copyright 654 Copyright (C) The Internet Society (2004). This document is subject 655 to the rights, licenses and restrictions contained in BCP 78, and 656 except as set forth therein, the authors retain all their rights. 658 This document and the information contained herein are provided on an 659 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 660 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 661 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 662 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 663 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 664 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 666 This Internet Draft expires on 24 April 2005.