1 2 3 4 5 6 7 Network Working Group M. Smith, Ed. 8 Request for Comments: 4516 Pearl Crescent, LLC 9 Obsoletes: 2255 T. Howes 10 Category: Standards Track Opsware, Inc. 11 June 2006 12 13 14 Lightweight Directory Access Protocol (LDAP): 15 Uniform Resource Locator 16 17 Status of This Memo 18 19 This document specifies an Internet standards track protocol for the 20 Internet community, and requests discussion and suggestions for 21 improvements. Please refer to the current edition of the "Internet 22 Official Protocol Standards" (STD 1) for the standardization state 23 and status of this protocol. Distribution of this memo is unlimited. 24 25 Copyright Notice 26 27 Copyright (C) The Internet Society (2006). 28 29 Abstract 30 31 This document describes a format for a Lightweight Directory Access 32 Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL 33 describes an LDAP search operation that is used to retrieve 34 information from an LDAP directory, or, in the context of an LDAP 35 referral or reference, an LDAP URL describes a service where an LDAP 36 operation may be progressed. 37 38 Table of Contents 39 40 1. Introduction ....................................................2 41 2. URL Definition ..................................................2 42 2.1. Percent-Encoding ...........................................4 43 3. Defaults for Fields of the LDAP URL .............................5 44 4. Examples ........................................................6 45 5. Security Considerations .........................................8 46 6. Normative References ............................................9 47 7. Informative References .........................................10 48 8. Acknowledgements ...............................................10 49 Appendix A: Changes Since RFC 2255 ................................11 50 A.1. Technical Changes .........................................11 51 A.2. Editorial Changes .........................................11 52 53 54 55 56 57 58 Smith & Howes Standards Track [Page 1] 59 61 RFC 4516 LDAP: Uniform Resource Locator June 2006 62 63 64 1. Introduction 65 66 LDAP is the Lightweight Directory Access Protocol [RFC4510]. This 67 document specifies the LDAP URL format for version 3 of LDAP and 68 clarifies how LDAP URLs are resolved. This document also defines an 69 extension mechanism for LDAP URLs. This mechanism may be used to 70 provide access to new LDAP extensions. 71 72 Note that not all the parameters of the LDAP search operation 73 described in [RFC4511] can be expressed using the format defined in 74 this document. Note also that URLs may be used to represent 75 reference knowledge, including that for non-search operations. 76 77 This document is an integral part of the LDAP technical specification 78 [RFC4510], which obsoletes the previously defined LDAP technical 79 specification, RFC 3377, in its entirety. 80 81 This document replaces RFC 2255. See Appendix A for a list of 82 changes relative to RFC 2255. 83 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in BCP 14 [RFC2119]. 87 88 2. URL Definition 89 90 An LDAP URL begins with the protocol prefix "ldap" and is defined by 91 the following grammar, following the ABNF notation defined in 92 [RFC4234]. 93 94 ldapurl = scheme COLON SLASH SLASH [host [COLON port]] 95 [SLASH dn [QUESTION [attributes] 96 [QUESTION [scope] [QUESTION [filter] 97 [QUESTION extensions]]]]] 98 ; <host> and <port> are defined 99 ; in Sections 3.2.2 and 3.2.3 100 ; of [RFC3986]. 101 ; <filter> is from Section 3 of 102 ; [RFC4515], subject to the 103 ; provisions of the 104 ; "Percent-Encoding" section 105 ; below. 106 107 scheme = "ldap" 108 109 110 111 112 113 114 115 Smith & Howes Standards Track [Page 2] 116 118 RFC 4516 LDAP: Uniform Resource Locator June 2006 119 120 121 dn = distinguishedName ; From Section 3 of [RFC4514], 122 ; subject to the provisions of 123 ; the "Percent-Encoding" 124 ; section below. 125 126 attributes = attrdesc *(COMMA attrdesc) 127 attrdesc = selector *(COMMA selector) 128 selector = attributeSelector ; From Section 4.5.1 of 129 ; [RFC4511], subject to the 130 ; provisions of the 131 ; "Percent-Encoding" section 132 ; below. 133 134 scope = "base" / "one" / "sub" 135 extensions = extension *(COMMA extension) 136 extension = [EXCLAMATION] extype [EQUALS exvalue] 137 extype = oid ; From section 1.4 of [RFC4512]. 138 139 exvalue = LDAPString ; From section 4.1.2 of 140 ; [RFC4511], subject to the 141 ; provisions of the 142 ; "Percent-Encoding" section 143 ; below. 144 145 EXCLAMATION = %x21 ; exclamation mark ("!") 146 SLASH = %x2F ; forward slash ("/") 147 COLON = %x3A ; colon (":") 148 QUESTION = %x3F ; question mark ("?") 149 150 The "ldap" prefix indicates an entry or entries accessible from the 151 LDAP server running on the given hostname at the given portnumber. 152 Note that the <host> may contain literal IPv6 addresses as specified 153 in Section 3.2.2 of [RFC3986]. 154 155 The <dn> is an LDAP Distinguished Name using the string format 156 described in [RFC4514]. It identifies the base object of the LDAP 157 search or the target of a non-search operation. 158 159 The <attributes> construct is used to indicate which attributes 160 should be returned from the entry or entries. 161 162 The <scope> construct is used to specify the scope of the search to 163 perform in the given LDAP server. The allowable scopes are "base" 164 for a base object search, "one" for a one-level search, or "sub" for 165 a subtree search. 166 167 168 169 170 171 172 Smith & Howes Standards Track [Page 3] 173 175 RFC 4516 LDAP: Uniform Resource Locator June 2006 176 177 178 The <filter> is used to specify the search filter to apply to entries 179 within the specified scope during the search. It has the format 180 specified in [RFC4515]. 181 182 The <extensions> construct provides the LDAP URL with an 183 extensibility mechanism, allowing the capabilities of the URL to be 184 extended in the future. Extensions are a simple comma-separated list 185 of type=value pairs, where the =value portion MAY be omitted for 186 options not requiring it. Each type=value pair is a separate 187 extension. These LDAP URL extensions are not necessarily related to 188 any of the LDAP extension mechanisms. Extensions may be supported or 189 unsupported by the client resolving the URL. An extension prefixed 190 with a '!' character (ASCII 0x21) is critical. An extension not 191 prefixed with a '!' character is non-critical. 192 193 If an LDAP URL extension is implemented (that is, if the 194 implementation understands it and is able to use it), the 195 implementation MUST make use of it. If an extension is not 196 implemented and is marked critical, the implementation MUST NOT 197 process the URL. If an extension is not implemented and is not 198 marked critical, the implementation MUST ignore the extension. 199 200 The extension type (<extype>) MAY be specified using the numeric OID 201 <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form 202 (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be 203 restricted to registered object identifier descriptive names. See 204 [RFC4520] for registration details and usage guidelines for 205 descriptive names. 206 207 No LDAP URL extensions are defined in this document. Other documents 208 or a future version of this document MAY define one or more 209 extensions. 210 211 2.1. Percent-Encoding 212 213 A generated LDAP URL MUST consist only of the restricted set of 214 characters included in one of the following three productions defined 215 in [RFC3986]: 216 217 <reserved> 218 <unreserved> 219 <pct-encoded> 220 221 Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as 222 input. An octet MUST be encoded using the percent-encoding mechanism 223 described in section 2.1 of [RFC3986] in any of these situations: 224 225 226 227 228 229 Smith & Howes Standards Track [Page 4] 230 232 RFC 4516 LDAP: Uniform Resource Locator June 2006 233 234 235 The octet is not in the reserved set defined in section 2.2 of 236 [RFC3986] or in the unreserved set defined in section 2.3 of 237 [RFC3986]. 238 239 It is the single Reserved character '?' and occurs inside a <dn>, 240 <filter>, or other element of an LDAP URL. 241 242 It is a comma character ',' that occurs inside an <exvalue>. 243 244 Note that before the percent-encoding mechanism is applied, the 245 extensions component of the LDAP URL may contain one or more null 246 (zero) bytes. No other component may. 247 248 3. Defaults for Fields of the LDAP URL 249 250 Some fields of the LDAP URL are optional, as described above. In the 251 absence of any other specification, the following general defaults 252 SHOULD be used when a field is absent. Note that other documents MAY 253 specify different defaulting rules; for example, section 4.1.10 of 254 [RFC4511] specifies a different rule for determining the correct DN 255 to use when it is absent in an LDAP URL that is returned as a 256 referral. 257 258 <host> 259 If no <host> is given, the client must have some a priori 260 knowledge of an appropriate LDAP server to contact. 261 262 <port> 263 The default LDAP port is TCP port 389. 264 265 <dn> 266 If no <dn> is given, the default is the zero-length DN, "". 267 268 <attributes> 269 If the <attributes> part is omitted, all user attributes of the 270 entry or entries should be requested (e.g., by setting the 271 attributes field AttributeDescriptionList in the LDAP search 272 request to a NULL list, or by using the special <alluserattrs> 273 selector "*"). 274 275 <scope> 276 If <scope> is omitted, a <scope> of "base" is assumed. 277 278 <filter> 279 If <filter> is omitted, a filter of "(objectClass=*)" is assumed. 280 281 <extensions> 282 If <extensions> is omitted, no extensions are assumed. 283 284 285 286 Smith & Howes Standards Track [Page 5] 287 289 RFC 4516 LDAP: Uniform Resource Locator June 2006 290 291 292 4. Examples 293 294 The following are some example LDAP URLs that use the format defined 295 above. The first example is an LDAP URL referring to the University 296 of Michigan entry, available from an LDAP server of the client's 297 choosing: 298 299 ldap:///o=University%20of%20Michigan,c=US 300 301 The next example is an LDAP URL referring to the University of 302 Michigan entry in a particular ldap server: 303 304 ldap://ldap1.example.net/o=University%20of%20Michigan,c=US 305 306 Both of these URLs correspond to a base object search of the 307 "o=University of Michigan,c=US" entry using a filter of 308 "(objectclass=*)", requesting all attributes. 309 310 The next example is an LDAP URL referring to only the postalAddress 311 attribute of the University of Michigan entry: 312 313 ldap://ldap1.example.net/o=University%20of%20Michigan, 314 c=US?postalAddress 315 316 The corresponding LDAP search operation is the same as in the 317 previous example, except that only the postalAddress attribute is 318 requested. 319 320 The next example is an LDAP URL referring to the set of entries found 321 by querying the given LDAP server on port 6666 and doing a subtree 322 search of the University of Michigan for any entry with a common name 323 of "Babs Jensen", retrieving all attributes: 324 325 ldap://ldap1.example.net:6666/o=University%20of%20Michigan, 326 c=US??sub?(cn=Babs%20Jensen) 327 328 The next example is an LDAP URL referring to all children of the c=GB 329 entry: 330 331 LDAP://ldap1.example.com/c=GB?objectClass?ONE 332 333 The objectClass attribute is requested to be returned along with the 334 entries, and the default filter of "(objectclass=*)" is used. 335 336 The next example is an LDAP URL to retrieve the mail attribute for 337 the LDAP entry named "o=Question?,c=US", illustrating the use of the 338 percent-encoding mechanism on the reserved character '?'. 339 340 341 342 343 Smith & Howes Standards Track [Page 6] 344 346 RFC 4516 LDAP: Uniform Resource Locator June 2006 347 348 349 ldap://ldap2.example.com/o=Question%3f,c=US?mail 350 351 The next example (which is broken into two lines for readability) 352 illustrates the interaction between the LDAP string representation of 353 the filters-quoting mechanism and the URL-quoting mechanisms. 354 355 ldap://ldap3.example.com/o=Babsco,c=US 356 ???(four-octet=%5c00%5c00%5c00%5c04) 357 358 The filter in this example uses the LDAP escaping mechanism of \ to 359 encode three zero or null bytes in the value. In LDAP, the filter 360 would be written as (four-octet=\00\00\00\04). Because the \ 361 character must be escaped in a URL, the \s are percent-encoded as %5c 362 (or %5C) in the URL encoding. 363 364 The next example illustrates the interaction between the LDAP string 365 representation of the DNs-quoting mechanism and URL-quoting 366 mechanisms. 367 368 ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US 369 370 The DN encoded in the above URL is: 371 372 o=An Example\2C Inc.,c=US 373 374 That is, the left-most RDN value is: 375 376 An Example, Inc. 377 378 The following three URLs are equivalent, assuming that the defaulting 379 rules specified in Section 3 of this document are used: 380 381 ldap://ldap.example.net 382 ldap://ldap.example.net/ 383 ldap://ldap.example.net/? 384 385 These three URLs point to the root DSE on the ldap.example.net 386 server. 387 388 The final two examples show use of a hypothetical, experimental bind 389 name extension (the value associated with the extension is an LDAP 390 DN). 391 392 ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com 393 ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com 394 395 396 397 398 399 400 Smith & Howes Standards Track [Page 7] 401 403 RFC 4516 LDAP: Uniform Resource Locator June 2006 404 405 406 The two URLs are the same, except that the second one marks the 407 e-bindname extension as critical. Notice the use of the percent- 408 encoding mechanism to encode the commas within the distinguished name 409 value in the e-bindname extension. 410 411 5. Security Considerations 412 413 The general URL security considerations discussed in [RFC3986] are 414 relevant for LDAP URLs. 415 416 The use of security mechanisms when processing LDAP URLs requires 417 particular care, since clients may encounter many different servers 418 via URLs, and since URLs are likely to be processed automatically, 419 without user intervention. A client SHOULD have a user-configurable 420 policy that controls which servers the client will establish LDAP 421 sessions with and with which security mechanisms, and SHOULD NOT 422 establish LDAP sessions that are inconsistent with this policy. If a 423 client chooses to reuse an existing LDAP session when resolving one 424 or more LDAP URLs, it MUST ensure that the session is compatible with 425 the URL and that no security policies are violated. 426 427 Sending authentication information, no matter the mechanism, may 428 violate a user's privacy requirements. In the absence of specific 429 policy permitting authentication information to be sent to a server, 430 a client should use an anonymous LDAP session. (Note that clients 431 conforming to previous LDAP URL specifications, where all LDAP 432 sessions are anonymous and unprotected, are consistent with this 433 specification; they simply have the default security policy.) Simply 434 opening a transport connection to another server may violate some 435 users' privacy requirements, so clients should provide the user with 436 a way to control URL processing. 437 438 Some authentication methods, in particular, reusable passwords sent 439 to the server, may reveal easily-abused information to the remote 440 server or to eavesdroppers in transit and should not be used in URL 441 processing unless they are explicitly permitted by policy. 442 Confirmation by the human user of the use of authentication 443 information is appropriate in many circumstances. Use of strong 444 authentication methods that do not reveal sensitive information is 445 much preferred. If the URL represents a referral for an update 446 operation, strong authentication methods SHOULD be used. Please 447 refer to the Security Considerations section of [RFC4513] for more 448 information. 449 450 The LDAP URL format allows the specification of an arbitrary LDAP 451 search operation to be performed when evaluating the LDAP URL. 452 Following an LDAP URL may cause unexpected results, for example, the 453 retrieval of large amounts of data or the initiation of a long-lived 454 455 456 457 Smith & Howes Standards Track [Page 8] 458 460 RFC 4516 LDAP: Uniform Resource Locator June 2006 461 462 463 search. The security implications of resolving an LDAP URL are the 464 same as those of resolving an LDAP search query. 465 466 6. Normative References 467 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 471 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 472 10646", STD 63, RFC 3629, November 2003. 473 474 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 475 Resource Identifier (URI): Generic Syntax", STD 66, RFC 476 3986, January 2005. 477 478 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 479 Specifications: ABNF", RFC 4234, October 2005. 480 481 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 482 (LDAP): Technical Specification Road Map", RFC 4510, June 483 2006. 484 485 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 486 Protocol (LDAP): The Protocol", RFC 4511, June 2006. 487 488 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 489 (LDAP): Directory Information Models", RFC 4512, June 490 2006. 491 492 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 493 (LDAP): Authentication Methods and Security Mechanisms", 494 RFC 4513, June 2006. 495 496 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 497 (LDAP): String Representation of Distinguished Names", RFC 498 4514, June 2006. 499 500 [RFC4515] Smith, M. Ed. and T. Howes, "Lightweight Directory Access 501 Protocol (LDAP): String Representation of Search Filters", 502 RFC 4515, June 2006. 503 504 505 506 507 508 509 510 511 512 513 514 Smith & Howes Standards Track [Page 9] 515 517 RFC 4516 LDAP: Uniform Resource Locator June 2006 518 519 520 7. Informative References 521 522 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 523 Resource Identifiers (URI): Generic Syntax", RFC 2396, 524 August 1998. 525 526 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 527 Considerations for the Lightweight Directory Access 528 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 529 530 8. Acknowledgements 531 532 The LDAP URL format was originally defined at the University of 533 Michigan. This material is based upon work supported by the National 534 Science Foundation under Grant No. NCR-9416667. The support of both 535 the University of Michigan and the National Science Foundation is 536 gratefully acknowledged. 537 538 This document obsoletes RFC 2255 by Tim Howes and Mark Smith. 539 Changes included in this revised specification are based upon 540 discussions among the authors, discussions within the LDAP (v3) 541 Revision Working Group (ldapbis), and discussions within other IETF 542 Working Groups. The contributions of individuals in these working 543 groups is gratefully acknowledged. Several people in particular have 544 made valuable comments on this document: RL "Bob" Morgan, Mark Wahl, 545 Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special 546 thanks for their contributions. 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 Smith & Howes Standards Track [Page 10] 572 574 RFC 4516 LDAP: Uniform Resource Locator June 2006 575 576 577 Appendix A: Changes Since RFC 2255 578 579 A.1. Technical Changes 580 581 The following technical changes were made to the contents of the "URL 582 Definition" section: 583 584 Revised all of the ABNF to use common productions from [RFC4512]. 585 586 Replaced references to [RFC2396] with a reference to [RFC3986] (this 587 allows literal IPv6 addresses to be used inside the <host> portion of 588 the URL, and a note was added to remind the reader of this 589 enhancement). Referencing [RFC3986] required changes to the ABNF and 590 text so that productions that are no longer defined by [RFC3986] are 591 not used. For example, <hostport> is not defined by [RFC3986] so it 592 has been replaced with host [COLON port]. Note that [RFC3986] 593 includes new definitions for the "Reserved" and "Unreserved" sets of 594 characters, and the net result is that the following two additional 595 characters should be percent-encoded when they appear anywhere in the 596 data used to construct an LDAP URL: "[" and "]" (these two characters 597 were first added to the Reserved set by RFC 2732). 598 599 Changed the definition of <attrdesc> to refer to <attributeSelector> 600 from [RFC4511]. This allows the use of "*" in the <attrdesc> part of 601 the URL. It is believed that existing implementations of RFC 2255 602 already support this. 603 604 Avoided use of <prose-val> (bracketed-string) productions in the 605 <dn>, <host>, <attrdesc>, and <exvalue> rules. 606 607 Changed the ABNF for <ldapurl> to group the <dn> component with the 608 preceding <SLASH>. 609 610 Changed the <extype> rule to be an <oid> from [RFC4512]. 611 612 Changed the text about extension types so it references [RFC4520]. 613 Reordered rules to more closely follow the order in which the 614 elements appear in the URL. 615 616 "Bindname Extension": removed due to lack of known implementations. 617 618 A.2. Editorial Changes 619 620 Changed document title to include "LDAP:" prefix. 621 622 IESG Note: removed note about lack of satisfactory mandatory 623 authentication mechanisms. 624 625 626 627 628 Smith & Howes Standards Track [Page 11] 629 631 RFC 4516 LDAP: Uniform Resource Locator June 2006 632 633 634 "Status of this Memo" section: updated boilerplate to match current 635 I-D guidelines. 636 637 "Abstract" section: separated from introductory material. 638 639 "Table of Contents" and "Intellectual Property" sections: added. 640 641 "Introduction" section: new section; separated from the Abstract. 642 Changed the text indicate that RFC 2255 is replaced by this document 643 (instead of RFC 1959). Added text to indicate that LDAP URLs are 644 used for references and referrals. Fixed typo (replaced the nonsense 645 phrase "to perform to retrieve" with "used to retrieve"). Added a 646 note to let the reader know that not all of the parameters of the 647 LDAP search operation described in [RFC4511] can be expressed using 648 this format. 649 650 "URL Definition" section: removed second copy of <ldapurl> grammar 651 and following two paragraphs (editorial error in RFC 2255). Fixed 652 line break within '!' sequence. Reformatted the ABNF to improve 653 readability by aligning comments and adding some blank lines. 654 Replaced "residing in the LDAP server" with "accessible from the LDAP 655 server" in the sentence immediately following the ABNF. Removed the 656 sentence "Individual attrdesc names are as defined for 657 AttributeDescription in [RFC4511]." because [RFC4511]'s 658 <attributeSelector> is now used directly in the ABNF. Reworded last 659 paragraph to clarify which characters must be percent-encoded. Added 660 text to indicate that LDAP URLs are used for references and 661 referrals. Added text that refers to the ABNF from RFC 4234. 662 Clarified and strengthened the requirements with respect to 663 processing of URLs that contain implemented and not implemented 664 extensions (the approach now closely matches that specified in 665 [RFC4511] for LDAP controls). 666 667 "Defaults for Fields of the LDAP URL" section: added; formed by 668 moving text about defaults out of the "URL Definition" section. 669 Replaced direct reference to the attribute name "*" with a reference 670 to the special <alluserattrs> selector "*" defined in [RFC4511]. 671 672 "URL Processing" section: removed. 673 674 "Examples" section: Modified examples to use example.com and 675 example.net hostnames. Added missing '?' to the LDAP URL example 676 whose filter contains three null bytes. Removed space after one 677 comma within a DN. Revised the bindname example to use e-bindname. 678 Changed the name of an attribute used in one example from "int" to 679 "four-octet" to avoid potential confusion. Added an example that 680 demonstrates the interaction between DN escaping and URL percent- 681 encoding. Added some examples to show URL equivalence with respect 682 683 684 685 Smith & Howes Standards Track [Page 12] 686 688 RFC 4516 LDAP: Uniform Resource Locator June 2006 689 690 691 to the <dn> portion of the URL. Used uppercase in some examples to 692 remind the reader that some tokens are case-insensitive. 693 694 "Security Considerations" section: Added a note about connection 695 reuse. Added a note about using strong authentication methods for 696 updates. Added a reference to [RFC4513]. Added note that simply 697 opening a connection may violate some users' privacy requirements. 698 Adopted the working group's revised LDAP terminology specification by 699 replacing the word "connection" with "LDAP session" or "LDAP 700 connection" as appropriate. 701 702 "Acknowledgements" section: added statement that this document 703 obsoletes RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and 704 Hallvard Furuseth. 705 706 "Normative References" section: renamed from "References" per new RFC 707 guidelines. Changed from [1] style to [RFC4511] style throughout the 708 document. Added references to RFC 4234 and RFC 3629. Updated all 709 RFC 1738 references to point to the appropriate sections within 710 [RFC3986]. Updated the LDAP references to refer to LDAPBis WG 711 documents. Removed the reference to the LDAP Attribute Syntaxes 712 document and added references to the [RFC4513], [RFC4520], and 713 [RFC4510] documents. 714 715 "Informative References" section: added. 716 717 Header and "Authors' Addresses" sections: added "editor" next to Mark 718 Smith's name. Updated affiliation and contact information. 719 720 Copyright: updated the year. 721 722 Throughout the document: surrounded the names of all ABNF productions 723 with "<" and ">" where they are used in descriptive text. 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 Smith & Howes Standards Track [Page 13] 743 745 RFC 4516 LDAP: Uniform Resource Locator June 2006 746 747 748 Authors' Addresses 749 750 Mark Smith, Editor 751 Pearl Crescent, LLC 752 447 Marlpool Dr. 753 Saline, MI 48176 754 USA 755 756 Phone: +1 734 944-2856 757 EMail: mcs (a] pearlcrescent.com 758 759 760 Tim Howes 761 Opsware, Inc. 762 599 N. Mathilda Ave. 763 Sunnyvale, CA 94085 764 USA 765 766 Phone: +1 408 744-7509 767 EMail: howes (a] opsware.com 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 Smith & Howes Standards Track [Page 14] 800 802 RFC 4516 LDAP: Uniform Resource Locator June 2006 803 804 805 Full Copyright Statement 806 807 Copyright (C) The Internet Society (2006). 808 809 This document is subject to the rights, licenses and restrictions 810 contained in BCP 78, and except as set forth therein, the authors 811 retain all their rights. 812 813 This document and the information contained herein are provided on an 814 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 815 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 816 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 817 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 818 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 819 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 820 821 Intellectual Property 822 823 The IETF takes no position regarding the validity or scope of any 824 Intellectual Property Rights or other rights that might be claimed to 825 pertain to the implementation or use of the technology described in 826 this document or the extent to which any license under such rights 827 might or might not be available; nor does it represent that it has 828 made any independent effort to identify any such rights. Information 829 on the procedures with respect to rights in RFC documents can be 830 found in BCP 78 and BCP 79. 831 832 Copies of IPR disclosures made to the IETF Secretariat and any 833 assurances of licenses to be made available, or the result of an 834 attempt made to obtain a general license or permission for the use of 835 such proprietary rights by implementers or users of this 836 specification can be obtained from the IETF on-line IPR repository at 837 http://www.ietf.org/ipr. 838 839 The IETF invites any interested party to bring to its attention any 840 copyrights, patents or patent applications, or other proprietary 841 rights that may cover technology that may be required to implement 842 this standard. Please address the information to the IETF at 843 ietf-ipr (a] ietf.org. 844 845 Acknowledgement 846 847 Funding for the RFC Editor function is provided by the IETF 848 Administrative Support Activity (IASA). 849 850 851 852 853 854 855 856 Smith & Howes Standards Track [Page 15] 857 859
Indexes created Tue Sep 15 00:24:42 UTC 2026