1 2 3 4 5 6 7Network Working Group K. Zeilenga 8Request for Comments: 4521 OpenLDAP Foundation 9BCP: 118 June 2006 10Category: Best Current Practice 11 12 13 Considerations for 14 Lightweight Directory Access Protocol (LDAP) Extensions 15 16Status of This Memo 17 18 This document specifies an Internet Best Current Practices for the 19 Internet Community, and requests discussion and suggestions for 20 improvements. Distribution of this memo is unlimited. 21 22Copyright Notice 23 24 Copyright (C) The Internet Society (2006). 25 26Abstract 27 28 The Lightweight Directory Access Protocol (LDAP) is extensible. It 29 provides mechanisms for adding new operations, extending existing 30 operations, and expanding user and system schemas. This document 31 discusses considerations for designers of LDAP extensions. 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58Zeilenga Best Current Practice [Page 1] 59 60RFC 4521 LDAP Extensions June 2006 61 62 63Table of Contents 64 65 1. Introduction ....................................................3 66 1.1. Terminology ................................................3 67 2. General Considerations ..........................................4 68 2.1. Scope of Extension .........................................4 69 2.2. Interaction between extensions .............................4 70 2.3. Discovery Mechanism ........................................4 71 2.4. Internationalization Considerations ........................5 72 2.5. Use of the Basic Encoding Rules ............................5 73 2.6. Use of Formal Languages ....................................5 74 2.7. Examples ...................................................5 75 2.8. Registration of Protocol Values ............................5 76 3. LDAP Operation Extensions .......................................6 77 3.1. Controls ...................................................6 78 3.1.1. Extending Bind Operation with Controls ..............6 79 3.1.2. Extending the Start TLS Operation with Controls .....7 80 3.1.3. Extending the Search Operation with Controls ........7 81 3.1.4. Extending the Update Operations with Controls .......8 82 3.1.5. Extending the Responseless Operations with Controls..8 83 3.2. Extended Operations ........................................8 84 3.3. Intermediate Responses .....................................8 85 3.4. Unsolicited Notifications ..................................9 86 4. Extending the LDAP ASN.1 Definition .............................9 87 4.1. Result Codes ...............................................9 88 4.2. LDAP Message Types .........................................9 89 4.3. Authentication Methods ....................................10 90 4.4. General ASN.1 Extensibility ...............................10 91 5. Schema Extensions ..............................................10 92 5.1. LDAP Syntaxes .............................................11 93 5.2. Matching Rules ............................................11 94 5.3. Attribute Types ...........................................12 95 5.4. Object Classes ............................................12 96 6. Other Extension Mechanisms .....................................12 97 6.1. Attribute Description Options .............................12 98 6.2. Authorization Identities ..................................12 99 6.3. LDAP URL Extensions .......................................12 100 7. Security Considerations ........................................12 101 8. Acknowledgements ...............................................13 102 9. References .....................................................13 103 9.1. Normative References ......................................13 104 9.2. Informative References ....................................15 105 106 107 108 109 110 111 112 113 114Zeilenga Best Current Practice [Page 2] 115 116RFC 4521 LDAP Extensions June 2006 117 118 1191. Introduction 120 121 The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an 122 extensible protocol. 123 124 LDAP allows for new operations to be added and for existing 125 operations to be enhanced [RFC4511]. 126 127 LDAP allows additional schema to be defined [RFC4512][RFC4517]. This 128 can include additional object classes, attribute types, matching 129 rules, additional syntaxes, and other elements of schema. LDAP 130 provides an ability to extend attribute types with options [RFC4512]. 131 132 LDAP supports a Simple Authentication and Security Layer (SASL) 133 authentication method [RFC4511][RFC4513]. SASL [RFC4422] is 134 extensible. LDAP may be extended to support additional 135 authentication methods [RFC4511]. 136 137 LDAP supports establishment of Transport Layer Security (TLS) 138 [RFC4511][RFC4513]. TLS [RFC4346] is extensible. 139 140 LDAP has an extensible Uniform Resource Locator (URL) format 141 [RFC4516]. 142 143 Lastly, LDAP allows for certain extensions to the protocol's Abstract 144 Syntax Notation - One (ASN.1) [X.680] definition to be made. This 145 facilitates a wide range of protocol enhancements, for example, new 146 result codes needed to support extensions to be added through 147 extension of the protocol's ASN.1 definition. 148 149 This document describes practices that engineers should consider when 150 designing extensions to LDAP. 151 1521.1. Terminology 153 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in BCP 14 [RFC2119]. In 157 this document, "the specification", as used by BCP 14, RFC 2119, 158 refers to the engineering of LDAP extensions. 159 160 The term "Request Control" refers to a control attached to a client- 161 generated message sent to a server. The term "Response Control" 162 refers to a control attached to a server-generated message sent to a 163 client. 164 165 166 167 168 169 170Zeilenga Best Current Practice [Page 3] 171 172RFC 4521 LDAP Extensions June 2006 173 174 175 DIT stands for Directory Information Tree. 176 DSA stands for Directory System Agent, a server. 177 DSE stands for DSA-Specific Entry. 178 DUA stands for Directory User Agent, a client. 179 DN stands for Distinguished Name. 180 1812. General Considerations 182 1832.1. Scope of Extension 184 185 Mutually agreeing peers may, within the confines of an extension, 186 agree to significant changes in protocol semantics. However, 187 designers MUST consider the impact of an extension upon protocol 188 peers that have not agreed to implement or otherwise recognize and 189 support the extension. Extensions MUST be "truly optional" 190 [RFC2119]. 191 1922.2. Interaction between extensions 193 194 Designers SHOULD consider how extensions they engineer interact with 195 other extensions. 196 197 Designers SHOULD consider the extensibility of extensions they 198 specify. Extensions to LDAP SHOULD themselves be extensible. 199 200 Except where it is stated otherwise, extensibility is implied. 201 2022.3. Discovery Mechanism 203 204 Extensions SHOULD provide adequate discovery mechanisms. 205 206 As LDAP design is based upon the client-request/server-response 207 paradigm, the general discovery approach is for the client to 208 discover the capabilities of the server before utilizing a particular 209 extension. Commonly, this discovery involves querying the root DSE 210 and/or other DSEs for operational information associated with the 211 extension. LDAP provides no mechanism for a server to discover the 212 capabilities of a client. 213 214 The 'supportedControl' attribute [RFC4512] is used to advertise 215 supported controls. The 'supportedExtension' attribute [RFC4512] is 216 used to advertise supported extended operations. The 217 'supportedFeatures' attribute [RFC4512] is used to advertise 218 features. Other root DSE attributes MAY be defined to advertise 219 other capabilities. 220 221 222 223 224 225 226Zeilenga Best Current Practice [Page 4] 227 228RFC 4521 LDAP Extensions June 2006 229 230 2312.4. Internationalization Considerations 232 233 LDAP is designed to support the full Unicode [Unicode] repertory of 234 characters. Extensions SHOULD avoid unnecessarily restricting 235 applications to subsets of Unicode (e.g., Basic Multilingual Plane, 236 ISO 8859-1, ASCII, Printable String). 237 238 LDAP Language Tag options [RFC3866] provide a mechanism for tagging 239 text (and other) values with language information. Extensions that 240 define attribute types SHOULD allow use of language tags with these 241 attributes. 242 2432.5. Use of the Basic Encoding Rules 244 245 Numerous elements of LDAP are described using ASN.1 [X.680] and are 246 encoded using a particular subset [Protocol, Section 5.2] of the 247 Basic Encoding Rules (BER) [X.690]. To allow reuse of 248 parsers/generators used in implementing the LDAP "core" technical 249 specification [RFC4510], it is RECOMMENDED that extension elements 250 (e.g., extension specific contents of controlValue, requestValue, 251 responseValue fields) described by ASN.1 and encoded using BER be 252 subjected to the restrictions of [Protocol, Section 5.2]. 253 2542.6. Use of Formal Languages 255 256 Formal languages SHOULD be used in specifications in accordance with 257 IESG guidelines [FORMAL]. 258 2592.7. Examples 260 261 Example DN strings SHOULD conform to the syntax defined in [RFC4518]. 262 Example LDAP filter strings SHOULD conform to the syntax defined in 263 [RFC4515]. Example LDAP URLs SHOULD conform to the syntax defined in 264 [RFC4516]. Entries SHOULD be represented using LDIF [RFC2849]. 265 2662.8. Registration of Protocol Values 267 268 Designers SHALL register protocol values of their LDAP extensions in 269 accordance with BCP 64, RFC 4520 [RFC4520]. Specifications that 270 create new extensible protocol elements SHALL extend existing 271 registries or establish new registries for values of these elements 272 in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434 273 [RFC2434]. 274 275 276 277 278 279 280 281 282Zeilenga Best Current Practice [Page 5] 283 284RFC 4521 LDAP Extensions June 2006 285 286 2873. LDAP Operation Extensions 288 289 Extensions SHOULD use controls in defining extensions that complement 290 existing operations. Where the extension to be defined does not 291 complement an existing operation, designers SHOULD consider defining 292 an extended operation instead. 293 294 For example, a subtree delete operation could be designed as either 295 an extension of the delete operation or as a new operation. As the 296 feature complements the existing delete operation, use of the control 297 mechanism to extend the delete operation is likely more appropriate. 298 299 As a counter (and contrived) example, a locate services operation (an 300 operation that would return for a DN a set of LDAP URLs to services 301 that may hold the entry named by this DN) could be designed as either 302 a search operation or a new operation. As the feature doesn't 303 complement the search operation (e.g., the operation is not contrived 304 to search for entries held in the Directory Information Tree), it is 305 likely more appropriate to define a new operation using the extended 306 operation mechanism. 307 3083.1. Controls 309 310 Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for 311 extending existing operations. The existing operation can be a base 312 operation defined in [RFC4511] (e.g., search, modify) , an extended 313 operation (e.g., Start TLS [RFC4511], Password Modify [RFC3062]), or 314 an operation defined as an extension to a base or extended operation. 315 316 Extensions SHOULD NOT return Response controls unless the server has 317 specific knowledge that the client can make use of the control. 318 Generally, the client requests the return of a particular response 319 control by providing a related request control. 320 321 An existing operation MAY be extended to return IntermediateResponse 322 messages [Protocol, Section 4.13]. 323 324 Specifications of controls SHALL NOT attach additional semantics to 325 the criticality of controls beyond those defined in [Protocol, 326 Section 4.1.11]. A specification MAY mandate the criticality take on 327 a particular value (e.g., TRUE or FALSE), where appropriate. 328 3293.1.1. Extending Bind Operation with Controls 330 331 Controls attached to the request and response messages of a Bind 332 Operation [RFC4511] are not protected by any security layers 333 established by that Bind operation. 334 335 336 337 338Zeilenga Best Current Practice [Page 6] 339 340RFC 4521 LDAP Extensions June 2006 341 342 343 Specifications detailing controls extending the Bind operation SHALL 344 detail that the Bind negotiated security layers do not protect the 345 information contained in these controls and SHALL detail how the 346 information in these controls is protected or why the information 347 does not need protection. 348 349 It is RECOMMENDED that designers consider alternative mechanisms for 350 providing the function. For example, an extended operation issued 351 subsequent to the Bind operation (hence, protected by the security 352 layers negotiated by the Bind operation) might be used to provide the 353 desired function. 354 355 Additionally, designers of Bind control extensions MUST also consider 356 how the controls' semantics interact with individual steps of a 357 multi-step Bind operation. Note that some steps are optional and 358 thus may require special attention in the design. 359 3603.1.2. Extending the Start TLS Operation with Controls 361 362 Controls attached to the request and response messages of a Start TLS 363 Operation [RFC4511] are not protected by the security layers 364 established by the Start TLS operation. 365 366 Specifications detailing controls extending the Start TLS operation 367 SHALL detail that the Start TLS negotiated security layers do not 368 protect the information contained in these controls and SHALL detail 369 how the information in these controls is protected or why the 370 information does not need protection. 371 372 It is RECOMMENDED that designers consider alternative mechanisms for 373 providing the function. For example, an extended operation issued 374 subsequent to the Start TLS operation (hence, protected by the 375 security layers negotiated by the Start TLS operation) might be used 376 to provided the desired function. 377 3783.1.3. Extending the Search Operation with Controls 379 380 The Search operation processing has two distinct phases: 381 382 - finding the base object; and 383 384 - searching for objects at or under that base object. 385 386 Specifications of controls extending the Search Operation should 387 clearly state in which phase(s) the control's semantics apply. 388 Semantics of controls that are not specific to the Search Operation 389 SHOULD apply in the finding phase. 390 391 392 393 394Zeilenga Best Current Practice [Page 7] 395 396RFC 4521 LDAP Extensions June 2006 397 398 3993.1.4. Extending the Update Operations with Controls 400 401 Update operations have properties of atomicity, consistency, 402 isolation, and durability ([ACID]). 403 404 - atomicity: All or none of the DIT changes requested are made. 405 406 - consistency: The resulting DIT state must be conform to schema 407 and other constraints. 408 409 - isolation: Intermediate states are not exposed. 410 411 - durability: The resulting DIT state is preserved until 412 subsequently updated. 413 414 When defining a control that requests additional (or other) DIT 415 changes be made to the DIT, these additional changes SHOULD NOT be 416 treated as part of a separate transaction. The specification MUST be 417 clear as to whether the additional DIT changes are part of the same 418 or a separate transaction as the DIT changes expressed in the request 419 of the base operation. 420 421 When defining a control that requests additional (or other) DIT 422 changes be made to the DIT, the specification MUST be clear as to the 423 order in which these and the base changes are to be applied to the 424 DIT. 425 4263.1.5. Extending the Responseless Operations with Controls 427 428 The Abandon and Unbind operations do not include a response message. 429 For this reason, specifications for controls designed to be attached 430 to Abandon and Unbind requests SHOULD mandate that the control's 431 criticality be FALSE. 432 4333.2. Extended Operations 434 435 Extended Operations [Protocol, Section 4.12] are the RECOMMENDED 436 mechanism for defining new operations. An extended operation 437 consists of an ExtendedRequest message, zero or more 438 IntermediateResponse messages, and an ExtendedResponse message. 439 4403.3. Intermediate Responses 441 442 Extensions SHALL use IntermediateResponse messages instead of 443 ExtendedResponse messages to return intermediate results. 444 445 446 447 448 449 450Zeilenga Best Current Practice [Page 8] 451 452RFC 4521 LDAP Extensions June 2006 453 454 4553.4. Unsolicited Notifications 456 457 Unsolicited notifications [Protocol, Section 4.4] offer a capability 458 for the server to notify the client of events not associated with the 459 operation currently being processed. 460 461 Extensions SHOULD be designed such that unsolicited notifications are 462 not returned unless the server has specific knowledge that the client 463 can make use of the notification. Generally, the client requests the 464 return of a particular unsolicited notification by performing a 465 related extended operation. 466 467 For example, a time hack extension could be designed to return 468 unsolicited notifications at regular intervals that were enabled by 469 an extended operation (which possibly specified the desired 470 interval). 471 4724. Extending the LDAP ASN.1 Definition 473 474 LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1 475 definition [Protocol, Appendix B] to be made. 476 4774.1. Result Codes 478 479 Extensions that specify new operations or enhance existing operations 480 often need to define new result codes. The extension SHOULD be 481 designed such that a client has a reasonably clear indication of the 482 nature of the successful or non-successful result. 483 484 Extensions SHOULD use existing result codes to indicate conditions 485 that are consistent with the intended meaning [RFC4511][X.511] of 486 these codes. Extensions MAY introduce new result codes [RFC4520] 487 where no existing result code provides an adequate indication of the 488 nature of the result. 489 490 Extensions SHALL NOT disallow or otherwise restrict the return of 491 general service result codes, especially those reporting a protocol, 492 service, or security problem, or indicating that the server is unable 493 or unwilling to complete the operation. 494 4954.2. LDAP Message Types 496 497 While extensions can specify new types of LDAP messages by extending 498 the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally 499 unnecessary and inappropriate. Existing operation extension 500 mechanisms (e.g., extended operations, unsolicited notifications, and 501 intermediate responses) SHOULD be used instead. However, there may 502 be cases where an extension does not fit well into these mechanisms. 503 504 505 506Zeilenga Best Current Practice [Page 9] 507 508RFC 4521 LDAP Extensions June 2006 509 510 511 In such cases, a new extension mechanism SHOULD be defined that can 512 be used by multiple extensions that have similar needs. 513 5144.3. Authentication Methods 515 516 The Bind operation currently supports two authentication methods, 517 simple and SASL. SASL [RFC4422] is an extensible authentication 518 framework used by multiple application-level protocols (e.g., BEEP, 519 IMAP, SMTP). It is RECOMMENDED that new authentication processes be 520 defined as SASL mechanisms. New LDAP authentication methods MAY be 521 added to support new authentication frameworks. 522 523 The Bind operation's primary function is to establish the LDAP 524 association [RFC4513]. No other operation SHALL be defined (or 525 extended) to establish the LDAP association. However, other 526 operations MAY be defined to establish other security associations 527 (e.g., IPsec). 528 5294.4. General ASN.1 Extensibility 530 531 Section 4 of [RFC4511] states the following: 532 533 In order to support future extensions to this protocol, 534 extensibility is implied where it is allowed per ASN.1 (i.e., 535 sequence, set, choice, and enumerated types are extensible). In 536 addition, ellipses (...) have been supplied in ASN.1 types that 537 are explicitly extensible as discussed in [RFC4520]. Because of 538 the implied extensibility, clients and servers MUST (unless 539 otherwise specified) ignore trailing SEQUENCE components whose 540 tags they do not recognize. 541 542 Designers SHOULD avoid introducing extensions that rely on 543 unsuspecting implementations to ignore trailing components of 544 SEQUENCE whose tags they do not recognize. 545 5465. Schema Extensions 547 548 Extensions defining LDAP schema elements SHALL provide schema 549 definitions conforming with syntaxes defined in [Models, Section 550 4.1]. While provided definitions MAY be reformatted (line wrapped) 551 for readability, this SHALL be noted in the specification. 552 553 For definitions that allow a NAME field, new schema elements SHOULD 554 provide one and only one name. The name SHOULD be short. 555 556 Each schema definition allows a DESC field. The DESC field, if 557 provided, SHOULD contain a short descriptive phrase. The DESC field 558 MUST be regarded as informational. That is, the specification MUST 559 560 561 562Zeilenga Best Current Practice [Page 10] 563 564RFC 4521 LDAP Extensions June 2006 565 566 567 be written such that its interpretation is the same with and without 568 the provided DESC fields. 569 570 The extension SHALL NOT mandate that implementations provide the same 571 DESC field in the schema they publish. Implementors MAY replace or 572 remove the DESC field. 573 574 Published schema elements SHALL NOT be redefined. Replacement schema 575 elements (new OIDs, new NAMEs) SHOULD be defined as needed. 576 577 Schema designers SHOULD reuse existing schema elements, where 578 appropriate. However, any reuse MUST not alter the semantics of the 579 element. 580 5815.1. LDAP Syntaxes 582 583 Each LDAP syntax [RFC4517] is defined in terms of ASN.1 [X.680]. 584 Each extension detailing an LDAP syntax MUST specify the ASN.1 data 585 definition associated with the syntax. A distinct LDAP syntax SHOULD 586 be created for each distinct ASN.1 data definition (including 587 constraints). 588 589 Each LDAP syntax SHOULD have a string encoding defined for it. It is 590 RECOMMENDED that this string encoding be restricted to UTF-8 591 [RFC3629] encoded Unicode [Unicode] characters. Use of Generic 592 String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic 593 string encoding rules to provide string encodings for complex ASN.1 594 data definitions is RECOMMENDED. Otherwise, it is RECOMMENDED that 595 the string encoding be described using a formal language (e.g., ABNF 596 [RFC4234]). Formal languages SHOULD be used in specifications in 597 accordance with IESG guidelines [FORMAL]. 598 599 If no string encoding is defined, the extension SHALL specify how the 600 transfer encoding is to be indicated. Generally, the extension 601 SHOULD mandate use of binary or other transfer encoding option. 602 6035.2. Matching Rules 604 605 Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and 606 SUBSTRING) may be associated with an attribute type. In addition, 607 LDAP provides an extensible matching rule mechanism. 608 609 The matching rule specification SHOULD detail which kind of matching 610 rule it is and SHOULD describe which kinds of values it can be used 611 with. 612 613 In addition to requirements stated in the LDAP technical 614 specification, equality matching rules SHOULD be commutative. 615 616 617 618Zeilenga Best Current Practice [Page 11] 619 620RFC 4521 LDAP Extensions June 2006 621 622 6235.3. Attribute Types 624 625 Designers SHOULD carefully consider how the structure of values is to 626 be restricted. Designers SHOULD consider that servers will only 627 enforce constraints of the attribute's syntax. That is, an attribute 628 intended to hold URIs, but that has directoryString syntax, is not 629 restricted to values that are URIs. 630 631 Designers SHOULD carefully consider which matching rules, if any, are 632 appropriate for the attribute type. Matching rules specified for an 633 attribute type MUST be compatible with the attribute type's syntax. 634 635 Extensions specifying operational attributes MUST detail how servers 636 are to maintain and/or utilize values of each operational attribute. 637 6385.4. Object Classes 639 640 Designers SHOULD carefully consider whether each attribute of an 641 object class is required ("MUST") or allowed ("MAY"). 642 643 Extensions specifying object classes that allow (or require) 644 operational attributes MUST specify how servers are to maintain 645 and/or utilize entries belonging to these object classes. 646 6476. Other Extension Mechanisms 648 6496.1. Attribute Description Options 650 651 Each option is identified by a string of letters, numbers, and 652 hyphens. This string SHOULD be short. 653 6546.2. Authorization Identities 655 656 Extensions interacting with authorization identities SHALL support 657 the LDAP authzId format [RFC4513]. The authzId format is extensible. 658 6596.3. LDAP URL Extensions 660 661 LDAP URL extensions are identified by a short string, a descriptor. 662 Like other descriptors, the string SHOULD be short. 663 6647. Security Considerations 665 666 LDAP does not place undue restrictions on the kinds of extensions 667 that can be implemented. While this document attempts to outline 668 some specific issues that designers need to consider, it is not (and 669 670 671 672 673 674Zeilenga Best Current Practice [Page 12] 675 676RFC 4521 LDAP Extensions June 2006 677 678 679 cannot be) all encompassing. Designers MUST do their own evaluations 680 of the security considerations applicable to their extensions. 681 682 Designers MUST NOT assume that the LDAP "core" technical 683 specification [RFC4510] adequately addresses the specific concerns 684 surrounding their extensions or assume that their extensions have no 685 specific concerns. 686 687 Extension specifications, however, SHOULD note whether security 688 considerations specific to the feature they are extending, as well as 689 general LDAP security considerations, apply to the extension. 690 6918. Acknowledgements 692 693 The author thanks the IETF LDAP community for their thoughtful 694 comments. 695 696 This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce 697 Greenblatt. 698 6999. References 700 7019.1. Normative References 702 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, March 1997. 705 706 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 707 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 708 October 1998. 709 710 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 711 Technical Specification", RFC 2849, June 2000. 712 713 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 714 10646", STD 63, RFC 3629, November 2003. 715 716 [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 717 Types", RFC 3641, October 2003. 718 719 [RFC3642] Legg, S., "Common Elements of Generic String Encoding 720 Rules (GSER) Encodings", RFC 3642, October 2003. 721 722 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 723 (LDAP): Directory Information Models", RFC 4512, June 724 2006. 725 726 727 728 729 730Zeilenga Best Current Practice [Page 13] 731 732RFC 4521 LDAP Extensions June 2006 733 734 735 [RFC3866] Zeilenga, K., Ed., "Language Tags and Ranges in the 736 Lightweight Directory Access Protocol (LDAP)", RFC 3866, 737 July 2004. 738 739 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 740 Specifications: ABNF", RFC 4234, October 2005. 741 742 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 743 (LDAP): Technical Specification Road Map", RFC 4510, June 744 2006. 745 746 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 747 Protocol (LDAP): The Protocol", RFC 4511, June 2006. 748 749 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 750 (LDAP): Directory Information Models", RFC 4512, June 751 2006. 752 753 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 754 (LDAP): Authentication Methods and Security Mechanisms", 755 RFC 4513, June 2006. 756 757 [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access 758 Protocol (LDAP): String Representation of Search Filters", 759 RFC 4515, June 2006. 760 761 [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access 762 Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 763 2006. 764 765 [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol 766 (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006. 767 768 [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol 769 (LDAP): String Representation of Distinguished Names", RFC 770 4518, June 2006. 771 772 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 773 Considerations for the Lightweight Directory Access 774 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 775 776 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 777 Authentication and Security Layer (SASL)", RFC 4422, June 778 2006. 779 780 781 782 783 784 785 786Zeilenga Best Current Practice [Page 14] 787 788RFC 4521 LDAP Extensions June 2006 789 790 791 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 792 3.2.0" is defined by "The Unicode Standard, Version 3.0" 793 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 794 as amended by the "Unicode Standard Annex #27: Unicode 795 3.1" (http://www.unicode.org/reports/tr27/) and by the 796 "Unicode Standard Annex #28: Unicode 3.2" 797 (http://www.unicode.org/reports/tr28/). 798 799 [FORMAL] IESG, "Guidelines for the use of formal languages in IETF 800 specifications", 801 <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in- 802 specs.txt>, 2001. 803 804 [X.511] International Telecommunication Union - Telecommunication 805 Standardization Sector, "The Directory: Abstract Service 806 Definition", X.511(1993) (also ISO/IEC 9594-3:1993). 807 808 [X.680] International Telecommunication Union - Telecommunication 809 Standardization Sector, "Abstract Syntax Notation One 810 (ASN.1) - Specification of Basic Notation", X.680(2002) 811 (also ISO/IEC 8824-1:2002). 812 813 [X.690] International Telecommunication Union - Telecommunication 814 Standardization Sector, "Specification of ASN.1 encoding 815 rules: Basic Encoding Rules (BER), Canonical Encoding 816 Rules (CER), and Distinguished Encoding Rules (DER)", 817 X.690(2002) (also ISO/IEC 8825-1:2002). 818 8199.2. Informative References 820 821 [ACID] Section 4 of ISO/IEC 10026-1:1992. 822 823 [GUIDE] Greenblatt, B., "LDAP Extension Style Guide", Work in 824 Progress. 825 826 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", 827 RFC 3062, February 2001. 828 829 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 830 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 831 832Author's Address 833 834 Kurt D. Zeilenga 835 OpenLDAP Foundation 836 837 EMail: Kurt@OpenLDAP.org 838 839 840 841 842Zeilenga Best Current Practice [Page 15] 843 844RFC 4521 LDAP Extensions June 2006 845 846 847Full Copyright Statement 848 849 Copyright (C) The Internet Society (2006). 850 851 This document is subject to the rights, licenses and restrictions 852 contained in BCP 78, and except as set forth therein, the authors 853 retain all their rights. 854 855 This document and the information contained herein are provided on an 856 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 857 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 858 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 859 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 860 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 861 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 862 863Intellectual Property 864 865 The IETF takes no position regarding the validity or scope of any 866 Intellectual Property Rights or other rights that might be claimed to 867 pertain to the implementation or use of the technology described in 868 this document or the extent to which any license under such rights 869 might or might not be available; nor does it represent that it has 870 made any independent effort to identify any such rights. Information 871 on the procedures with respect to rights in RFC documents can be 872 found in BCP 78 and BCP 79. 873 874 Copies of IPR disclosures made to the IETF Secretariat and any 875 assurances of licenses to be made available, or the result of an 876 attempt made to obtain a general license or permission for the use of 877 such proprietary rights by implementers or users of this 878 specification can be obtained from the IETF on-line IPR repository at 879 http://www.ietf.org/ipr. 880 881 The IETF invites any interested party to bring to its attention any 882 copyrights, patents or patent applications, or other proprietary 883 rights that may cover technology that may be required to implement 884 this standard. Please address the information to the IETF at 885 ietf-ipr@ietf.org. 886 887Acknowledgement 888 889 Funding for the RFC Editor function is provided by the IETF 890 Administrative Support Activity (IASA). 891 892 893 894 895 896 897 898Zeilenga Best Current Practice [Page 16] 899 900