idnits 2.17.1 draft-ietf-ldapbis-url-06.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 660. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 666), 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 647), which is fine, but *also* found old RFC 2026, Section 10.4A text on line 447. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 660), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 453. ** 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, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 7) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 (14 July 2004) is 7227 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 498, but not defined -- Looks like a reference, but probably isn't: '1' on line 587 -- 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 (~~), 10 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: 14 January 2005 Opsware, Inc. 6 14 July 2004 8 LDAP: Uniform Resource Locator 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 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. Technical Changes...........................................14 75 13.2. Editorial Changes...........................................14 76 14. Intellectual Property Rights...................................14 77 15. Full Copyright.................................................15 79 1. Introduction 81 LDAP is the Lightweight Directory Access Protocol, defined in 82 [Protocol]. This document specifies the LDAP URL format for version 83 3 of LDAP and clarifies how LDAP URLs are resolved. This document 84 also defines an extension mechanism for LDAP URLs, so that future 85 documents can extend their functionality, for example, to provide 86 access to new LDAPv3 extensions as they are defined. Note: not all 87 of the parameters of the LDAP search operation described in 88 [Protocol] can be expressed using the format defined in this 89 document. 91 This document is an integral part of the LDAP Technical Specification 92 [Roadmap]. 94 This document replaces RFC 2255. See Appendix A for a list of changes 95 relative to RFC 2255. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in BCP 14 [RFC2119]. 101 2. URL Definition 103 An LDAP URL begins with the protocol prefix "ldap" and is defined by 104 the following grammar, following the ABNF notation defined in 105 [RFC2234]. 107 ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn 108 [QUESTION [attributes] [QUESTION [scope] 109 [QUESTION [filter] [QUESTION extensions]]]]] 110 scheme = "ldap" 111 hostport = 112 ; As updated by [RFC2732] to allow 113 ; IPv6 literal addresses 114 dn = 115 ; See the "Escaping Using the % Method" 116 ; section below. 117 attributes = attrdesc *(COMMA attrdesc) 118 attrdesc = 120 / ASTERISK 121 ; See the "Escaping Using the % Method" 122 ; section below. 123 scope = "base" / "one" / "sub" 124 filter = 125 ; See the "Escaping Using the % Method" 126 ; section below. 127 extensions = extension *(COMMA extension) 128 extension = [EXCLAMATION] extype [EQUALS exvalue] 129 extype = oid / oiddescr 130 exvalue = 131 ; See the "Escaping Using the % Method" 132 ; section below. 133 oid = 134 oiddescr = 136 EXCLAMATION = %x21 ; exclamation mark ("!") 137 ASTERISK = %x2A ; asterisk ("*") 138 SLASH = %x2F ; forward slash ("/") 139 COLON = %x3A ; colon (":") 140 QUESTION = %x3F ; question mark ("?") 142 The "ldap" prefix indicates an entry or entries accessible from the 143 LDAP server running on the given hostname at the given portnumber. 144 Note that the hostport may contain literal IPv6 addresses as 145 specified in [RFC2732]. 147 The dn is an LDAP Distinguished Name using the string format 148 described in [LDAPDN]. It identifies the base object of the LDAP 149 search or the target of a non-search operation. 151 The attributes construct is used to indicate which attributes should 152 be returned from the entry or entries. Individual attrdesc names are 153 as defined for AttributeDescription in [Protocol]. 155 The scope construct is used to specify the scope of the search to 156 perform in the given LDAP server. The allowable scopes are "base" 157 for a base object search, "one" for a one-level search, or "sub" for 158 a subtree search. 160 The filter is used to specify the search filter to apply to entries 161 within the specified scope during the search. It has the format 162 specified in [Filters]. 164 The extensions construct provides the LDAP URL with an extensibility 165 mechanism, allowing the capabilities of the URL to be extended in the 166 future. Extensions are a simple comma-separated list of type=value 167 pairs, where the =value portion MAY be omitted for options not 168 requiring it. Each type=value pair is a separate extension. These 169 LDAP URL extensions are not necessarily related to any of the LDAPv3 170 extension mechanisms. Extensions may be supported or unsupported by 171 the client resolving the URL. An extension prefixed with a '!' 172 character (ASCII 0x21) is critical. An extension not prefixed with a 173 '!' character is non-critical. 175 If an LDAP URL extension is recognized by an implementation (that is, 176 if the implementation understands it and is able to use it), the 177 implementation MUST make use of it. If an extension is not 178 recognized and is marked critical, the implementation MUST NOT 179 process the URL. If an extension is not recognized and it not marked 180 critical, the implementation MUST ignore the extension. 182 The extension type (extype) MAY be specified using the oid form 183 (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use 184 of the oiddesc form SHOULD be restricted to registered object 185 identifier descriptive names. See [LDAPIANA] for registration 186 details and usage guidelines for descriptive names. 188 No LDAP URL extensions are defined in this document. Other documents 189 or a future version of this document MAY define one or more 190 extensions. 192 2.1. Escaping Using the % Method 194 A generated LDAP URL MUST consist only of the restricted set of 195 characters included in the uric production that is defined in section 196 2 of [RFC2396]. Implementations SHOULD accept other valid UTF-8 197 strings [RFC3629] as input. An octet MUST be escaped using the % 198 method described in section 2.4 of [RFC2396] in any of these 199 situations: 201 The octet is not in the reserved set defined in section 2.2 of 202 [RFC2396] or in the unreserved set defined in section 2.3 of 203 [RFC2396]. 205 It is the single Reserved character '?' and occurs inside a dn, 206 filter, or other element of an LDAP URL. 208 It is a comma character ',' that occurs inside an extension value. 210 3. Defaults for Fields of the LDAP URL 212 Some fields of the LDAP URL are optional, as described above. In the 213 absence of any other specification, the following general defaults 214 SHOULD be used when a field is absent. Note: other documents MAY 215 specify different defaulting rules; for example, section 4.1.10 of 216 [Protocol] specifies a different rule for determining the correct DN 217 to use when it is absent in an LDAP URL that is returned as a 218 referral. 220 hostport 221 The default LDAP port is TCP port 389. If no hostport is given, 222 the client must have some apriori knowledge of an appropriate LDAP 223 server to contact. 225 dn 226 If no dn is given, the default is the zero-length DN, "". 228 attributes 229 If the attributes part is omitted, all user attributes of the 230 entry or entries should be requested (e.g., by setting the 231 attributes field AttributeDescriptionList in the LDAP search 232 request to a NULL list, or (in LDAPv3) by requesting the special 233 attribute name "*"). 235 scope 236 If scope is omitted, a scope of "base" is assumed. 238 filter 239 If filter is omitted, a filter of "(objectClass=*)" is assumed. 241 extensions 242 If extensions is omitted, no extensions are assumed. 244 4. Examples 246 The following are some example LDAP URLs using the format defined 247 above. The first example is an LDAP URL referring to the University 248 of Michigan entry, available from an LDAP server of the client's 249 choosing: 251 ldap:///o=University%20of%20Michigan,c=US 253 The next example is an LDAP URL referring to the University of 254 Michigan entry in a particular ldap server: 256 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US 258 Both of these URLs correspond to a base object search of the 259 "o=University of Michigan,c=US" entry using a filter of 260 "(objectclass=*)", requesting all attributes. 262 The next example is an LDAP URL referring to only the postalAddress 263 attribute of the University of Michigan entry: 265 ldap://ldap1.example.net/o=University%20of%20Michigan, 266 c=US?postalAddress 268 The corresponding LDAP search operation is the same as in the 269 previous example, except that only the postalAddress attribute is 270 requested. 272 The next example is an LDAP URL referring to the set of entries found 273 by querying the given LDAP server on port 6666 and doing a subtree 274 search of the University of Michigan for any entry with a common name 275 of "Babs Jensen", retrieving all attributes: 277 ldap://ldap1.example.net:6666/o=University%20of%20Michigan, 278 c=US??sub?(cn=Babs%20Jensen) 280 The next example is an LDAP URL referring to all children of the c=GB 281 entry: 283 ldap://ldap1.example.com/c=GB?objectClass?one 285 The objectClass attribute is requested to be returned along with the 286 entries, and the default filter of "(objectclass=*)" is used. 288 The next example is an LDAP URL to retrieve the mail attribute for 289 the LDAP entry named "o=Question?,c=US" is given below, illustrating 290 the use of the escaping mechanism on the reserved character '?'. 292 ldap://ldap2.example.com/o=Question%3f,c=US?mail 294 The next example (which is broken into two lines for readability) 295 illustrates the interaction between the LDAP string representation of 296 filters quoting mechanism and URL quoting mechanisms. 298 ldap://ldap3.example.com/o=Babsco,c=US 299 ???(four-octet=%5c00%5c00%5c00%5c04) 301 The filter in this example uses the LDAP escaping mechanism of \ to 302 encode three zero or null bytes in the value. In LDAP, the filter 303 would be written as (four-octet=\00\00\00\04). Because the \ 304 character must be escaped in a URL, the \'s are escaped as %5c in the 305 URL encoding. 307 The next example illustrates the interaction between the LDAP string 308 representation of DNs quoting mechanism and URL quoting mechanisms. 310 ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US 312 The DN encoded in the above URL is: 314 o=An Example\2c Inc.,c=US 316 That is, the left-most RDN value is: 318 An Example, Inc. 320 The following three URLs that are equivalent, assuming that the 321 defaulting rules specified in section 4 of this document are used: 323 ldap://ldap.example.net 324 ldap://ldap.example.net/ 325 ldap://ldap.example.net/? 327 These three URLs all point to the root DSE on the ldap.example.net 328 server. 330 The final two examples show use of a hypothetical, experimental bind 331 name extension (the value associated with the extension is an LDAP DN). 333 ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com 334 ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com 336 The two URLs are the same, except that the second one marks the 337 e-bindname extension as critical. Notice the use of the % encoding 338 method to encode the commas within the distinguished name value in 339 the e-bindname extension. 341 5. Security Considerations 343 General URL security considerations discussed in [RFC2396] are 344 relevant for LDAP URLs. 346 The use of security mechanisms when processing LDAP URLs requires 347 particular care, since clients may encounter many different servers 348 via URLs, and since URLs are likely to be processed automatically, 349 without user intervention. A client SHOULD have a user-configurable 350 policy about which servers to connect to using which security 351 mechanisms, and SHOULD NOT make connections that are inconsistent 352 with this policy. If a client chooses to reuse an existing 353 connection when resolving one or more LDAP URL, it MUST ensure that 354 the connection is compatible with the URL and that no security 355 policies are violated. 357 Sending authentication information, no matter the mechanism, may 358 violate a user's privacy requirements. In the absence of specific 359 policy permitting authentication information to be sent to a server, 360 a client should use an anonymous connection. (Note that clients 361 conforming to previous LDAP URL specifications, where all connections 362 are anonymous and unprotected, are consistent with this 363 specification; they simply have the default security policy.) Simply 364 opening a connection to another server may violate some users' 365 privacy requirements, so clients should provide the user with a way 366 to control URL processing. 368 Some authentication methods, in particular reusable passwords sent to 369 the server, may reveal easily-abused information to the remote server 370 or to eavesdroppers in transit, and should not be used in URL 371 processing unless explicitly permitted by policy. Confirmation by 372 the human user of the use of authentication information is 373 appropriate in many circumstances. Use of strong authentication 374 methods that do not reveal sensitive information is much preferred. 375 If the URL represents a referral for an update operation, strong 376 authentication methods SHOULD be used. Please refer to the Security 377 Considerations section of [AuthMeth] for more information. 379 The LDAP URL format allows the specification of an arbitrary LDAP 380 search operation to be performed when evaluating the LDAP URL. 381 Following an LDAP URL may cause unexpected results, for example, the 382 retrieval of large amounts of data, the initiation of a long-lived 383 search, etc. The security implications of resolving an LDAP URL are 384 the same as those of resolving an LDAP search query. 386 6. IANA Considerations 388 This document has no actions for IANA. 390 7. Normative References 392 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods", 393 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a 394 work in progress. 396 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 397 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work 398 in progress. 400 [Filters] Smith, M. and Howes, T., "LDAP: String Representation of 401 Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in 402 progress. 404 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", 405 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 407 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 408 Requirement Levels," RFC 2119, BCP 14, March 1997. 410 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 411 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 413 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 414 Specifications: ABNF", RFC 2234, November 1997. 416 [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 417 Resource Identifiers (URI): Generic Syntax", RFC 2396, 418 August 1998. 420 [RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Literal 421 IPv6 Addresses in URL's", RFC 2732, December 1999. 423 [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road 424 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 426 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 427 RFC 3629, November 2003. 429 8. Informative References 431 None. 433 9. Intellectual Property Rights 435 The IETF takes no position regarding the validity or scope of any 436 intellectual property or other rights that might be claimed to 437 pertain to the implementation or use of the technology described in 438 this document or the extent to which any license under such rights 439 might or might not be available; neither does it represent that it 440 has made any effort to identify any such rights. Information on the 441 IETF's procedures with respect to rights in standards-track and 442 standards-related documentation can be found in BCP-11. Copies of 443 claims of rights made available for publication and any assurances of 444 licenses to be made available, or the result of an attempt made to 445 obtain a general license or permission for the use of such 446 proprietary rights by implementors or users of this specification can 447 be obtained from the IETF Secretariat. 449 The IETF invites any interested party to bring to its attention any 450 copyrights, patents or patent applications, or other proprietary 451 rights which may cover technology that may be required to practice 452 this standard. Please address the information to the IETF Executive 453 Director. 455 10. Acknowledgements 457 The LDAP URL format was originally defined at the University of 458 Michigan. This material is based upon work supported by the National 459 Science Foundation under Grant No. NCR-9416667. The support of both 460 the University of Michigan and the National Science Foundation is 461 gratefully acknowledged. 463 This document is an update to RFC 2255 by Tim Howes and Mark Smith. 464 Changes included in this revised specification are based upon 465 discussions among the authors, discussions within the LDAP (v3) 466 Revision Working Group (ldapbis), and discussions within other IETF 467 Working Groups. The contributions of individuals in these working 468 groups is gratefully acknowledged. Several people in particular have 469 made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, 470 Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special 471 thanks for their contributions. 473 11. Authors' Addresses 475 Mark Smith, Editor 476 Pearl Crescent, LLC 477 447 Marlpool Dr. 478 Saline, MI 48176 479 USA 480 +1 734 944-2856 481 mcs@pearlcrescent.com 483 Tim Howes 484 Opsware, Inc. 485 599 N. Mathilda Ave. 486 Sunnyvale, CA 94085 487 USA 488 +1 408 744-7509 489 howes@opsware.com 491 12. Appendix A: Changes Since RFC 2255 493 12.1. Technical Changes 495 The following technical changes were made to the contents of the "URL 496 Definition" section: 498 Revised all of the ABNF to use common productions from [Models]. 500 Added note and references to [RFC2732] to allow literal IPv6 501 addresses inside the hostport portion of the URL. 503 Added missing ASTERISK as an alternative for the attrdesc part of the 504 URL. It is believed that existing implementations of RFC 2255 505 already support this. 507 Added angle brackets around free-form prose in the "dn", "hostport", 508 "attrdesc", "filter", and "exvalue" rules. 510 Changed the ABNF for ldapurl to group the dn component with the 511 preceding slash. 513 Changed the extype rule to be an LDAPOID from [Protocol] or an OID 514 description from [LDAPIANA]. 516 Changed the text about extension types so it references [LDAPIANA]. 517 Reordered rules to more closely follow the order the elements appear 518 in the URL. 520 "Bindname Extension": removed due to lack of known implementations. 522 12.2. Editorial Changes 524 Changed document title to include "LDAP:" prefix. 526 IESG Note: removed note about lack of satisfactory mandatory 527 authentication mechanisms. 529 "Status of this Memo" section: updated boilerplate to match current 530 I-D guidelines. 532 "Abstract" section: separated from introductory material. 534 "Table of Contents" and "IANA Considerations" sections: added. 536 "Introduction" section: new section; separated from the Abstract. 537 Changed the text indicate that RFC 2255 is replaced by this document 538 (instead of RFC 1959). Added text to indicate that LDAP URLs are 539 used for references and referrals. Fixed typo (replaced the nonsense 540 phrase "to perform to retrieve" with "used to retrieve"). Added a 541 note to let the reader know that not all of the parameters of the 542 LDAP search operation described in [Protocol] can be expressed using 543 this format. 545 "URL Definition" section: removed second copy of ldapurl grammar and 546 following two paragraphs (editorial error in RFC 2255). Fixed line 547 break within '!' sequence. Replaced "residing in the LDAP server" 548 with "accessible from the LDAP server" in the sentence immediately 549 following the ABNF. Reworded last paragraph to clarify which 550 characters must be URL escaped. Added text to indicate that LDAP 551 URLs are used for references and referrals. Added text that refers 552 to the ABNF from RFC 2234. Clarified and strengthened the 553 requirements with respect to processing of URLs that contain 554 recognized and unrecognized extensions (the approach now matches that 555 specified in [Protocol] for LDAP controls). 557 "Defaults for Fields of the LDAP URL" section: added; formed by 558 moving text about defaults out of the "URL Definition" section. 560 "URL Processing" section: clarified that connections MAY be reused 561 only if the open connection is compatible with the URL. Added text 562 to indicate that use of security services is encouraged and that they 563 SHOULD be used when updates are involved. Removed "dn" from 564 discussion of authentication methods. Added note that the client MAY 565 interrogate the server to determine the most appropriate method. 567 "Examples" section: Modified examples to use example.com and 568 example.net hostnames. Added missing '?' to the LDAP URL example 569 whose filter contains three null bytes. Removed space after one 570 comma within a DN. Revised the bindname example to use e-bindname. 571 Changed the name of an attribute used in one example from "int" to 572 "four-octet" to avoid potential confusion. Added an example that 573 demonstrates the interaction between DN escaping and URL escaping. 574 Added some examples to show URL equivalence with respect to the dn 575 portion of the URL. 577 "Security Considerations" section: Added a note about connection 578 reuse. Added a note about using strong authentication methods for 579 updates. Added a reference to [AuthMeth]. Added note that simply 580 opening a connection may violate some users' privacy requirements. 582 "Acknowledgements" section: added statement about this being an 583 update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and 584 Hallvard Furuseth. 586 "Normative References" section: renamed from "References" per new RFC 587 guidelines. Changed from [1] style to [Protocol] style throughout the 588 document. Added references to RFC 2234, RFC 2732, and RFC 3629. 589 Updated all RFC 1738 references to point to the appropriate sections 590 within RFC 2396. Updated the LDAP references to refer to LDAPBis WG 591 documents. Removed the reference to the LDAP Attribute Syntaxes 592 document and added references to the [AuthMeth], [LDAPIANA], and 593 [Roadmap] documents. 595 "Informative References" section: added for clarity. 597 Header and "Authors' Addresses" sections: added "editor" next to Mark 598 Smith's name. Updated affiliation and contact information. 600 Copyright: updated the year. 602 13. Appendix B: Changes Since Previous Document Revision 604 This appendix lists all changes relative to the previously published 605 revision, draft-ietf-ldapbis-url-05.txt. Note that when appropriate 606 these changes are also included in Appendix A, but are also included 607 here for the benefit of the people who have already reviewed 608 draft-ietf-ldapbis-url-05.txt. This section will be removed before 609 this document is published as an RFC. 611 13.1. Technical Changes 613 "URL Definition" section: changed the hex value for SLASH to 0x2F (it 614 was 0x5C which is "\" not "/"). Also, broke some long lines into two 615 lines to avoid exceeding the 72 column limit. 617 13.2. Editorial Changes 619 "Status of this Memo", "Intellectual Property Rights", and "Full 620 Copyright" sections: updated to use boilerplate from RFC 3667 and RFC 621 3668. 623 "Status of this Memo", "Abstract" and "Table of Contents" sections: 624 removed section numbers. 626 "Introduction" section: added missing RFC 2119 keywords. 628 "URL Definition" section: replaced "residing in the LDAP server" with 629 "accessible from the LDAP server" in the sentence immediately 630 following the ABNF. Also, added the explanatory phrase "(that is, if 631 the implementation understands it and is able to use it)" to the 632 sentence that begins "If an LDAP URL extension is recognized by an 633 implementation...." Also, replaced "ASCII 33" with ASCII 0x21 in the 634 text that refers to the "!" character. 636 "IANA Considerations" section: added. 638 14. Intellectual Property Rights 640 The IETF takes no position regarding the validity or scope of any 641 Intellectual Property Rights or other rights that might be claimed to 642 pertain to the implementation or use of the technology described in 643 this document or the extent to which any license under such rights 644 might or might not be available; nor does it represent that it has 645 made any independent effort to identify any such rights. Information 646 on the procedures with respect to rights in RFC documents can be 647 found in BCP 78 and BCP 79. 649 Copies of IPR disclosures made to the IETF Secretariat and any 650 assurances of licenses to be made available, or the result of an 651 attempt made to obtain a general license or permission for the use of 652 such proprietary rights by implementers or users of this 653 specification can be obtained from the IETF on-line IPR repository at 654 http://www.ietf.org/ipr. 656 The IETF invites any interested party to bring to its attention any 657 copyrights, patents or patent applications, or other proprietary 658 rights that may cover technology that may be required to implement 659 this standard. Please address the information to the IETF at 660 ietf-ipr@ietf.org. 662 15. Full Copyright 664 Copyright (C) The Internet Society (2004). This document is subject 665 to the rights, licenses and restrictions contained in BCP 78, and 666 except as set forth therein, the authors retain all their rights. 668 This document and the information contained herein are provided on an 669 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 670 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 671 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 672 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 673 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 674 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 676 This Internet Draft expires on 14 January 2005.