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