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