idnits 2.17.1 draft-ietf-ldapbis-url-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([RFC2119], [RFC2251], [RFC2252], [RFC2253]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 abstract seems to indicate that this document obsoletes RFC2251, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC2252, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC2253, but the header doesn't have an 'Obsoletes:' line to match this. 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. (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 (21 February 2001) is 8464 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: 'RFC 2251' is mentioned on line 154, but not defined ** Obsolete undefined reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Looks like a reference, but probably isn't: '1' on line 557 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 2254 (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2829 (Obsoleted by RFC 4510, RFC 4513) Summary: 18 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Mark Smith, Editor 3 Request for Comments: DRAFT Netscape Communications Corp. 4 Obsoletes: RFC 2255 Tim Howes 5 Loudcloud, Inc. 7 21 February 2001 9 The LDAP URL Format 10 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Discussion of this document should take place on the LDAP (v3) 32 Revison (ldapbis) Working Group mailing list . After appropriate review and discussion, this 34 document will be submitted as a Standards Track replacement for RFC 35 2255. 37 Copyright Notice 39 Copyright (C) The Internet Society (2001). All Rights Reserved. 41 2. Abstract 43 LDAP is the Lightweight Directory Access Protocol, defined in 44 [RFC2251], [RFC2253], and [RFC2252]. This document describes a 45 format for an LDAP Uniform Resource Locator. The format describes an 46 LDAP search operation used to retrieve information from an LDAP 47 directory, or, in the context of an LDAPv3 referral or reference, the 48 format describes a service where an LDAP operation may be progressed. 49 Note: not all of the parameters of the LDAP search operation 50 described in [RFC2251] can be expressed using the format defined in 51 this document. 53 This document specifies the LDAP URL format for version 3 of LDAP and 54 clarifies how LDAP URLs are resolved. This document also defines an 55 extension mechanism for LDAP URLs, so that future documents can 56 extend their functionality, for example, to provide access to new 57 LDAPv3 extensions as they are defined. 59 This document replaces RFC 2255. See Appendix A for a list of changes 60 relative to RFC 2255. 62 The key words "MUST", "MAY", and "SHOULD" used in this document are 63 to be interpreted as described in [RFC2119]. 65 3. URL Definition 67 An LDAP URL begins with the protocol prefix "ldap" and is defined by 68 the following grammar, following the ABNF notation defined in 69 [RFC2234]. 71 ldapurl = scheme "://" [hostport] ["/" 72 [dn ["?" [attributes] ["?" [scope] 73 ["?" [filter] ["?" extensions]]]]]] 74 scheme = "ldap" 75 hostport = 76 dn = 77 attributes = attrdesc *("," attrdesc) 78 attrdesc = / "*" 79 scope = "base" / "one" / "sub" 80 filter = 81 extensions = extension *("," extension) 82 extension = ["!"] extype ["=" exvalue] 83 extype = token / xtoken 84 exvalue = 85 token = 86 xtoken = "x-" token 88 The "ldap" prefix indicates an entry or entries residing in the LDAP 89 server running on the given hostname at the given portnumber. 91 The dn is an LDAP Distinguished Name using the string format 92 described in [RFC2253]. It identifies the base object of the LDAP 93 search or the target of a non-search operation. 95 The attributes construct is used to indicate which attributes should 96 be returned from the entry or entries. Individual attrdesc names are 97 as defined for AttributeDescription in [RFC2251]. 99 The scope construct is used to specify the scope of the search to 100 perform in the given LDAP server. The allowable scopes are "base" 101 for a base object search, "one" for a one-level search, or "sub" for 102 a subtree search. 104 The filter is used to specify the search filter to apply to entries 105 within the specified scope during the search. It has the format 106 specified in [RFC2254]. 108 The extensions construct provides the LDAP URL with an extensibility 109 mechanism, allowing the capabilities of the URL to be extended in the 110 future. Extensions are a simple comma-separated list of type=value 111 pairs, where the =value portion MAY be omitted for options not 112 requiring it. Each type=value pair is a separate extension. These 113 LDAP URL extensions are not necessarily related to any of the LDAPv3 114 extension mechanisms. Extensions may be supported or unsupported by 115 the client resolving the URL. An extension prefixed with a '!' 116 character (ASCII 33) is critical. An extension not prefixed with a 117 '!' character is non-critical. 119 If an extension is supported by the client, the client MUST obey the 120 extension if the extension is critical. The client SHOULD obey 121 supported extensions that are non-critical. 123 If an extension is unsupported by the client, the client MUST NOT 124 process the URL if the extension is critical. If an unsupported 125 extension is non-critical, the client MUST ignore the extension. 127 If a critical extension cannot be processed successfully by the 128 client, the client MUST NOT process the URL. If a non-critical 129 extension cannot be processed successfully by the client, the client 130 SHOULD ignore the extension. 132 Extension types prefixed by "X-" or "x-" are reserved for use in 133 bilateral agreements between communicating parties. Other extension 134 types MUST be defined in this document, or in other standards-track 135 documents. 137 One LDAP URL extension is defined in this document (see the section 138 "The Bindname Extension" below). Other documents or a future version 139 of this document MAY define other extensions. 141 Note that characters that are not safe (e.g., spaces) (as defined in 142 section 2.1 of RFC 2396 [RFC2396]), and the single Reserved character 143 '?' occurring inside a dn, filter, or other element of an LDAP URL 144 MUST be escaped using the % method described in section 2.4 of RFC 145 2396 [RFC2396]. If a comma character ',' occurs inside an extension 146 value, the character MUST also be escaped using the % method. 148 4. Defaults for Fields of the LDAP URL 150 Some fields of the LDAP URL are optional, as described above. In the 151 absence of any other specification, the following general defaults 152 SHOULD be used when a field is absent. Note: other documents MAY 153 specify different defaulting rules; for example, section 4.1.11 of 154 [RFC 2251] specifies a different rule for determining the correct DN 155 to use when it is absent in an LDAP URL that is returned as a 156 referral. 158 hostport 159 The default LDAP port is TCP port 389. If no hostport is given, 160 the client must have some apriori knowledge of an appropriate LDAP 161 server to contact. 163 dn 164 If no dn is given, the default is the zero-length DN, "". 166 attributes 167 If the attributes part is omitted, all user attributes of the 168 entry or entries should be requested (e.g., by setting the 169 attributes field AttributeDescriptionList in the LDAP search 170 request to a NULL list, or (in LDAPv3) by requesting the special 171 attribute name "*"). 173 scope 174 If scope is omitted, a scope of "base" is assumed. 176 filter 177 If filter is omitted, a filter of "(objectClass=*)" is assumed. 179 extensions 180 If extensions is omitted, no extensions are assumed. 182 5. The Bindname Extension 184 This section defines an LDAP URL extension for representing the 185 distinguished name for a client to use when authenticating to an LDAP 186 directory during resolution of an LDAP URL. Clients MAY implement 187 this extension. 189 The extension type is "bindname". The extension value is the 190 distinguished name of the directory entry to authenticate as, in the 191 same form as described for dn in the grammar above. The dn may be the 192 NULL string to specify unauthenticated access. The extension may be 193 either critical (prefixed with a '!' character) or non-critical (not 194 prefixed with a '!' character). 196 If the bindname extension is critical, the client resolving the URL 197 MUST authenticate to the directory using the given distinguished name 198 and an appropriate authentication method. Note that for a NULL 199 distinguished name, no bind MAY be required to obtain anonymous 200 access to the directory. If the extension is non-critical, the client 201 MAY bind to the directory using the given distinguished name. 203 6. URL Processing 205 This section describes how an LDAP URL SHOULD be resolved by a 206 client. 208 First, the client obtains a connection to the LDAP server referenced 209 in the URL, or an LDAP server of the client's choice if no LDAP 210 server is explicitly referenced. This connection MAY be opened 211 specifically for the purpose of resolving the URL or the client MAY 212 reuse an already open connection if the open connection is compatible 213 with the URL. The connection MAY provide confidentiality, integrity, 214 or other services, e.g., using TLS. Use of security services is at 215 the client's discretion if not specified in the URL but is encouraged 216 if the request or any potential responses contains sensitive 217 information. If the URL represents a referral for an update 218 operation, security services SHOULD be used. 220 Next, the client authenticates itself to the LDAP server. This step 221 is optional, unless the URL contains a critical bindname extension 222 with a non-NULL value. If a bindname extension is given, the client 223 proceeds according to the section above. 225 If a bindname extension is not specified, the client MAY bind to the 226 directory using an appropriate authentication method of its own 227 choosing (including NULL authentication). The client may interrogate 228 the server to determine the most appropriate method. 230 Next, the client performs the LDAP search operation specified in the 231 URL. Additional fields in the LDAP protocol search request, such as 232 sizelimit, timelimit, deref, and anything else not specified or 233 defaulted in the URL specification, MAY be set at the client's 234 discretion. 236 Once the search has completed, the client MAY close the connection to 237 the LDAP server, or the client MAY keep the connection open for 238 future use. 240 7. Examples 242 The following are some example LDAP URLs using the format defined 243 above. The first example is an LDAP URL referring to the University 244 of Michigan entry, available from an LDAP server of the client's 245 choosing: 247 ldap:///o=University%20of%20Michigan,c=US 249 The next example is an LDAP URL referring to the University of 250 Michigan entry in a particular ldap server: 252 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US 254 Both of these URLs correspond to a base object search of the 255 "o=University of Michigan,c=US" entry using a filter of 256 "(objectclass=*)", requesting all attributes. 258 The next example is an LDAP URL referring to only the postalAddress 259 attribute of the University of Michigan entry: 261 ldap://ldap1.example.net/o=University%20of%20Michigan, 262 c=US?postalAddress 264 The corresponding LDAP search operation is the same as in the 265 previous example, except that only the postalAddress attribute is 266 requested. 268 The next example is an LDAP URL referring to the set of entries found 269 by querying the given LDAP server on port 6666 and doing a subtree 270 search of the University of Michigan for any entry with a common name 271 of "Babs Jensen", retrieving all attributes: 273 ldap://ldap1.example.net:6666/o=University%20of%20Michigan, 274 c=US??sub?(cn=Babs%20Jensen) 276 The next example is an LDAP URL referring to all children of the c=GB 277 entry: 279 ldap://ldap1.example.com/c=GB?objectClass?one 281 The objectClass attribute is requested to be returned along with the 282 entries, and the default filter of "(objectclass=*)" is used. 284 The next example is an LDAP URL to retrieve the mail attribute for 285 the LDAP entry named "o=Question?,c=US" is given below, illustrating 286 the use of the escaping mechanism on the reserved character '?'. 288 ldap://ldap2.example.com/o=Question%3f,c=US?mail 290 The next example illustrates the interaction between LDAP and URL 291 quoting mechanisms. 293 ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04) 295 The filter in this example uses the LDAP escaping mechanism of \ to 296 encode three zero or null bytes in the value. In LDAP, the filter 297 would be written as (int=\00\00\00\04). Because the \ character must 298 be escaped in a URL, the \'s are escaped as %5c in the URL encoding. 300 The final example shows the use of the bindname extension to specify 301 the dn a client should use for authentication when resolving the URL. 303 ldap:///??sub??bindname=cn=Manager%2co=Foo 304 ldap:///??sub??!bindname=cn=Manager%2co=Foo 306 The two URLs are the same, except that the second one marks the 307 bindname extension as critical. Notice the use of the % encoding 308 method to encode the comma in the distinguished name value in the 309 bindname extension. 311 8. Security Considerations 313 General URL security considerations discussed in RFC 2396 [RFC2396] 314 are relevant for LDAP URLs. 316 The use of security mechanisms when processing LDAP URLs requires 317 particular care, since clients may encounter many different servers 318 via URLs, and since URLs are likely to be processed automatically, 319 without user intervention. A client SHOULD have a user-configurable 320 policy about which servers to connect to using which security 321 mechanisms, and SHOULD NOT make connections that are inconsistent 322 with this policy. If a client chooses to reuse an existing 323 connection when resolving one or more LDAP URL, it MUST ensure that 324 the connection is compatible with the URL and that no security 325 policies are violated. 327 Sending authentication information, no matter the mechanism, may 328 violate a user's privacy requirements. In the absence of specific 329 policy permitting authentication information to be sent to a server, 330 a client should use an anonymous connection. (Note that clients 331 conforming to previous LDAP URL specifications, where all connections 332 are anonymous and unprotected, are consistent with this 333 specification; they simply have the default security policy.) Simply 334 opening a connection to another server may violate some users' 335 privacy requirements, so clients should provide the user with a way 336 to control URL processing. 338 Some authentication methods, in particular reusable passwords sent to 339 the server, may reveal easily-abused information to the remote server 340 or to eavesdroppers in transit, and should not be used in URL 341 processing unless explicitly permitted by policy. Confirmation by 342 the human user of the use of authentication information is 343 appropriate in many circumstances. Use of strong authentication 344 methods that do not reveal sensitive information is much preferred. 345 If the URL represents a referral for an update operation, strong 346 authentication methods SHOULD be used. Please refer to the Security 347 Considerations section of [RFC2829] for more information. 349 The LDAP URL format allows the specification of an arbitrary LDAP 350 search operation to be performed when evaluating the LDAP URL. 351 Following an LDAP URL may cause unexpected results, for example, the 352 retrieval of large amounts of data, the initiation of a long-lived 353 search, etc. The security implications of resolving an LDAP URL are 354 the same as those of resolving an LDAP search query. 356 9. Acknowledgements 358 The LDAP URL format was originally defined at the University of 359 Michigan. This material is based upon work supported by the National 360 Science Foundation under Grant No. NCR-9416667. The support of both 361 the University of Michigan and the National Science Foundation is 362 gratefully acknowledged. 364 This document is an update to RFC 2255 by Tim Howes and Mark Smith. 365 Changes included in this revised specification are based upon 366 discussions among the authors, discussions within the LDAP (v3) 367 Revision Working Group (ldapbis), and discussions within other IETF 368 Working Groups. The contributions of individuals in these working 369 groups is gratefully acknowledged. Several people in particular have 370 made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, 371 Kurt Zeilenga, and Jim Sermersheim deserve special thanks for their 372 contributions. 374 10. References 376 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 377 Requirement Levels," RFC 2119, March 1997. 379 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 380 Specifications: ABNF", RFC 2234, November 1997. 382 [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory 383 Access Protocol (v3)", RFC 2251, December 1997. 385 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 386 "Lightweight Directory Access Protocol (v3): Attribute Syntax 387 Definitions", RFC 2252, December 1997. 389 [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory 390 Access Protocol (v3): UTF-8 String Representation of Distinguished 391 Names", RFC 2253, December 1997. 393 [RFC2254] Howes, T., "A String Representation of LDAP Search 394 Filters", RFC 2254, December 1997. 396 [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 397 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 399 [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, 400 "Authentication Methods for LDAP", RFC 2829, May 2000. 402 11. Authors' Address 404 Mark Smith, Editor 405 Netscape Communications Corp. 406 Mailstop USCA17-201 407 4170 Network Circle 408 Santa Clara, CA 95054 409 USA 410 +1 650 937-3477 411 mcs@netscape.com 413 Tim Howes 414 Loudcloud, Inc. 415 599 N. Mathilda Ave. 416 Sunnyvale, CA 94086 417 USA 418 +1 408 744-7509 419 howes@loudcloud.com 421 12. Full Copyright Statement 423 Copyright (C) The Internet Society (2001). All Rights Reserved. 425 This document and translations of it may be copied and furnished to 426 others, and derivative works that comment on or otherwise explain it 427 or assist in its implementation may be prepared, copied, published 428 and distributed, in whole or in part, without restriction of any 429 kind, provided that the above copyright notice and this paragraph are 430 included on all such copies and derivative works. However, this 431 document itself may not be modified in any way, such as by removing 432 the copyright notice or references to the Internet Society or other 433 Internet organizations, except as needed for the purpose of 434 developing Internet standards in which case the procedures for 435 copyrights defined in the Internet Standards process must be 436 followed, or as required to translate it into languages other than 437 English. 439 The limited permissions granted above are perpetual and will not be 440 revoked by the Internet Society or its successors or assigns. 442 This document and the information contained herein is provided on an 443 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 444 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 445 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 446 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 447 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 449 13. Appendix A: Changes Since RFC 2255 451 13.1. Technical Changes 453 "URL Definition" section: added missing "*" as an alternative for the 454 attrdesc part of the URL. It is believed that existing 455 implementations of RFC 2255 already support this. Added angle 456 brackets around free-form prose in the "dn", "hostport", "attrdesc", 457 "filter", "exvalue", and "token" rules. Simplified the "xtoken" rule 458 by removing the "X-" option (case insensitivity is taken care of by 459 the ABNF). Reordered rules to more closely follow the order the 460 elements appear in the URL. 462 13.2. Editorial Changes 464 "Abstract" section: changed the text indicate that RFC 2255 is 465 replaced by this document (instead of RFC 1959). Added text to 466 indicate that LDAP URLs are used for references and referrals. Fixed 467 typo (replaced the nonsense phrase "to perform to retrieve" with 468 "used to retrieve"). Added a note to let the reader know that not 469 all of the parameters of the LDAP search operation described in 470 [RFC2251] can be expressed using this format. 472 IESG Note: removed note about lack of satisfactory mandatory 473 authentication mechanisms. 475 "URL Definition" section: removed second copy of ldapurl grammar and 476 following two paragraphs (editorial error in RFC 2255). Fixed line 477 break within '!' sequence. Reworded last paragraph to clarify which 478 characters must be URL escaped. Added text to indicate that LDAP 479 URLs are used for references and referrals. Added text that refers 480 to the ABNF from RFC 2234. 482 "Defaults for Fields of the LDAP URL" section: added; formed by 483 moving text about defaults out of the "URL Definition" section. 485 "URL Processing" section: clarified that connections MAY be reused 486 only if the open connection is compatible with the URL. Added text 487 to indicate that use of security services is encouraged and that they 488 SHOULD be used when updates are involved. Removed "dn" from 489 discussion of authentication methods. Added note that the client MAY 490 interrogate the server to determine the most appropriate method. 492 "Examples" section: Modified examples to use example.com and 493 example.net hostnames. Added missing '?' to the LDAP URL example 494 whose filter contains three null bytes. Removed space after one 495 comma within a DN. 497 "Security Considerations" section: Added a note about connection 498 reuse. Added a note about using strong authentication methods for 499 updates. Added a reference to RFC 2829. Added note that simply 500 opening a connection may violate some users' privacy requirements. 502 "Acknowledgements" section: added statement about this being an 503 update to RFC 2255. Added added Kurt Zeilenga and Jim Sermersheim. 505 "References" section: changed from [1] style to [RFC2251] style 506 throughout the document. Added references to RFCs 2234 and 2829. 507 Updated RFC 1738 references to the appropriate sections within RFC 508 2396. 510 Header and "Authors' Addresses" sections: added "editor" next to Mark 511 Smith's name. Updated affiliation and contact information. 513 Copyright: updated the year. 515 "Appendix C: Loose Ends" section: added. 517 "Table of Contents" section: added. 519 14. Appendix B: Changes Since Previous Document Revision 521 This appendix lists all changes relative to the last published 522 revision, draft-smith-ldapv3-url-update-01.txt. Note that these 523 changes are also included in Appendix A, but are included here for 524 those who have already reviewed draft-smith-ldapv3-url-update-01.txt. 526 14.1. Technical Changes 528 "URL Definition" section: added angle brackets around free-form prose 529 in the "dn", "hostport", "attrdesc", "filter", "exvalue", and "token" 530 rules. Simplified the "xtoken" rule by removing the "X-" option 531 (case insensitivity is taken care of by the ABNF). Reordered rules 532 to more closely follow the order the elements appear in the URL. 534 14.2. Editorial Changes 536 Header: changed document from an individual submission to an ldapbis 537 working group submission. Discussion referred to the ietf- 538 ldapbis@openldap.org mailing list. 540 Header and "Authors' Addresses" sections: added "editor" next to Mark 541 Smith's name. 543 "Abstract" section: fixed typo (replaced the nonsense phrase "to 544 perform to retrieve" with "used to retrieve"). Added a note to let 545 the reader know that not all of the parameters of the LDAP search 546 operation described in [RFC2251] can be expressed using this format. 548 "URL Definition" section: added text that refers to the ABNF from RFC 549 2234. 551 "Defaults for Fields of the LDAP URL" section: added a note to 552 clarify that other specifications MAY specify different defaulting 553 rules. 555 Copyright: changed the year to 2001. 557 References: changed from [1] style to [RFC2251] style throughout the 558 document. Added a reference to RFC 2234. Updated RFC 1738 559 references to the appropriate sections within RFC 2396. 561 "Acknowledgements" section: added statement about this being an 562 update to RFC 2255. Added Jim Sermersheim. 564 "Loose Ends" section: removed item about referencing RFC 2396 instead 565 of 1738 (done). Removed "Search URLs vs. Referral URLs" item (the 566 editor believe this has been resolved)." Added item about potentially 567 supporting userinfo in LDAP URLs. Added item about not supporting 568 all parameters of the LDAPv3 search operation. 570 15. Appendix C: Loose Ends 572 Other Extensions: Suggestions for TLS and SASL URL extensions have 573 been made, but more discussion is needed about whether they are 574 needed, how they will be specified, and whether they should be added 575 to this document. 577 We need to consider whether it makes sense to support constructs like 578 @: within the hostport field. We do not want 579 to preclude this in the future, but we may keep the details out of 580 this document. Note this specification uses the "hostport" construct 581 from RFC 2396, but not the "server" construct (which is the one that 582 contains "userinfo"): 584 server = [ [ userinfo "@" ] hostport ] 585 hostport = host [ ":" port ] 587 Therefore, it may be necessary to replace "hostport" with "server" in 588 this specification. 590 Some parameters of the LDAPv3 search operation defined in section 591 4.5.1 of RFC 2251 are not supported by the LDAP URL format, e.g., 592 derefAliases, sizeLimit, timeLimit, typesOnly, controls. Some 593 ldapbis working group participants would like to see them supported, 594 while others see this as "out of scope" for ldapbis. Support for 595 these options could be added using the extension mechanism. 597 This Internet Draft expires on 21 August 2001. 599 1. Status of this Memo............................................1 600 2. Abstract.......................................................1 601 3. URL Definition.................................................2 602 4. Defaults for Fields of the LDAP URL............................4 603 5. The Bindname Extension.........................................4 604 6. URL Processing.................................................5 605 7. Examples.......................................................6 606 8. Security Considerations........................................7 607 9. Acknowledgements...............................................8 608 10. References.....................................................8 609 11. Authors' Address...............................................9 610 12. Full Copyright Statement.......................................9 611 13. Appendix A: Changes Since RFC 2255.............................10 612 13.1. Technical Changes...........................................10 613 13.2. Editorial Changes...........................................10 614 14. Appendix B: Changes Since Previous Document Revision...........12 615 14.1. Technical Changes...........................................12 616 14.2. Editorial Changes...........................................12 617 15. Appendix C: Loose Ends.........................................13