Considerations for Lightweight Directory Access Protocol (LDAP) Extensions
The information below is for an old version of the document that is already published as an RFC.
This is an older version of an Internet-Draft that was ultimately published as RFC 4521.
|Last updated||2022-11-01 (Latest revision 2006-02-03)|
|RFC stream||Internet Engineering Task Force (IETF)|
|IESG||IESG state||RFC 4521 (Best Current Practice)|
|Responsible AD||Ted Hardie|
|Send notices to||(None)|
INTERNET-DRAFT Kurt D. Zeilenga Intended Category: BCP OpenLDAP Foundation Expires in six months 2 February 2006 Considerations for LDAP Extensions <draft-zeilenga-ldap-ext-10.txt> Status of this Memo This document is intended to be, after appropriate review and revision, submitted to the RFC Editor for publication as a BCP. Distribution of this memo is unlimited. Technical discussion of this document will take place on the IETF LDAP Extensions mailing list <email@example.com>. Please send editorial comments directly to the author <Kurt@OpenLDAP.org>. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright (C) The Internet Society (2006). All Rights Reserved. Please see the Full Copyright section near the end of this document for more information. Zeilenga LDAP Extensions [Page 1] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 Abstract The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schema. This document discusses considerations for designers of LDAP extensions. Table of Contents [[Page numbers to be filled in by RFC-Editor]] Status of this Memo Abstract Table of Contents 1. Background and Intended Use 2. General Considerations 2.1. Scope of Extension 2.2. Interaction between extensions 2.3. Discovery Mechanism 2.4. International Considerations 2.5. use of Basic Encoding Rules 2.6. Use of Formal Languages 2.7. Examples 2.8. Registratin of Protocol Values 3. LDAP Operation Extensions 3.1. Controls 3.2. Extended Operations 3.3. Intermediate Responses 3.4. Unsolicited Notifications 4. Extending LDAP ASN.1 definition 4.1. Result Codes 4.2. LDAP Message Types 4.3. Authentication Methods 4.4. General ASN.1 Extensibility 5. Schema Extensions 5.1. LDAP Syntaxes 5.2. Matching Rules 5.3. Attribute Types 5.4. Object Classes 6. Other Extension Mechanisms 6.1. Attribute Description Options 6.2. Authorization Identities 6.3. LDAP URL Extensions 7. Security Considerations 8. Acknowledgements 9. Author's Address 10. References Zeilenga LDAP Extensions [Page 2] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 Full Copyright Intellectual Property Rights 1. Background and Intended Use The Lightweight Directory Access Protocol (LDAP) [Roadmap] is an extensible protocol. LDAP allows for new operations to be added and existing operations to be enhanced [Protocol]. LDAP allows additional schema to be defined [Models]. This can include additional object classes, attribute types, matching rules, additional syntaxes, and other elements of schema. LDAP provides an ability to extend attribute types with options [Models]. LDAP supports a Simple Authentication and Security Layer (SASL) authentication method [Protocol][AuthMeth]. SASL [SASL] is extensible. LDAP may be extended to support additional authentication methods [Protocol]. LDAP supports establishment of Transport Layer Security (TLS) [Protocol][AuthMeth]. TLS [TLS] is extensible. LDAP has an extensible Uniform Resource Locator (URL) format [LDAPURL]. Lastly, LDAP allows for certain extensions to the protocol's Abstract Syntax Notation - One (ASN.1) [X.680] definition to be made. This facilitate a wide range of protocol enhancements. For example, new result codes needed to support extensions to be added through extension of the protocol's ASN.1 definition. This document describes practices which engineers should consider when designing extensions to LDAP. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. In this document, "the specification" as used by BCP 14 refers to the engineering of LDAP extensions. The term "Request Control" refers to a control attached to a client generated message sent to a server. The term "Response Control" Zeilenga LDAP Extensions [Page 3] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 refers to a control attached to a server generated message sent to a client. DIT stands for Directory Information Tree. DSA stands for Directory System Agent, a server. DSE stands for DSA-Specific Entry. DUA stands for Directory User Agent, a client. DN stands for Distinguished Name. 2. General Considerations 2.1 Scope of Extension Mutually agreeing peers may, within the confines of an extension, agree to significant changes in protocol semantics. However, designers MUST consider the impact of an extension upon protocol peers which have not agreed to implement, or otherwise recognize and support, the extension. Extensions MUST be "truly optional" [RFC2119]. 2.2. Interaction between extensions Designers SHOULD consider how extensions they engineer interaction with other extensions. Designers SHOULD consider extensibility of extensions they specify. Extensions to LDAP SHOULD themselves be extensible. Except where stated otherwise, extensibility is implied. 2.3. Discovery Mechanism Extensions SHOULD provide adequate discovery mechanisms. As LDAP design is based upon the client-request/server-response paradigm, the general discovery approach is for the client to discover the capabilities of the server before utilizing a particular extension. Commonly, this discovery involves querying the root DSE and/or other DSEs for operational information associated with the extension. LDAP provides no mechanism for a server to discover the capabilities of a client. The 'supportedControl' attribute [Models] is used to advertised supported controls. The 'supportedExtension' attribute [Models] is Zeilenga LDAP Extensions [Page 4] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 used to advertised supported extended operations. The 'supportedFeatures' attribute [RFC3674] is used to advertise features. Other root DSE attributes MAY be defined to advertise other capabilities. 2.4. Internationalization Considerations LDAP is designed to support the full Unicode [Unicode] repertory of characters. Extensions SHOULD avoid unnecessarily restricting applications to subsets of Unicode (e.g., Basic Multilingual Plane, ISO 8859-1, ASCII, Printable String). LDAP Language Tag options [RFC3866] provides a mechanism for tagging text (and other) values with language information. Extensions which define attribute types SHOULD allow use of language tags with these attributes. 2.5. Use of the Basic Encoding Rules Numerous elements of LDAP are described using ASN.1 [X.680] and are to encoded using a particular subset [Protocol, Section 5.2] of the Basic Encoding Rules (BER) [X.690]. To allow reuse of parsers/generators used in implementing the LDAP "core" technical specification [Roadmap], it is RECOMMENDED that extension elements (e.g. extension specific contents of controlValue, requestValue, responseValue fields) described by ASN.1 and encoded using BER be subjected to the restrictions of [Protocol, Section 5.2]. 2.6. Use of Formal Languages Formal languages SHOULD be used in specifications in accordance with IESG guidelines [FORMAL]. 2.7. Examples Example DN strings SHOULD conform to the syntax defined in [LDAPDN]. Example LDAP filter strings SHOULD conform to the syntax defined in [Filter]. Example LDAP URLs SHOULD conform to the syntax defined in [LDAPURL]. Entries SHOULD be represented using LDIF [RFC2849]. 2.8. Registration of Protocol Values Designers SHALL register protocol values of their LDAP extensions in Zeilenga LDAP Extensions [Page 5] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 accordance with BCP 64 [BCP64bis]. Specifications which create new extensible protocol elements SHALL extend existing or establish new registries for values of these elements in accordance with BCP 64 [BCP64bis] and BCP 26 [RFC2434]. 3. LDAP Operation Extensions Extensions SHOULD use controls in defining extensions which complement existing operations. Where the extension to be defined does not complement an existing operation, designers SHOULD consider defining an extended operation instead. For example, a subtree delete operation could be designed as either an extension of the delete operation or as a new operation. As the feature complements the existing delete operation, use of the control mechanism to extend the delete operation is likely more appropriate. As a counter (and contrived) example, a locate services operation (an operation which would return for a DN a set of LDAP URLs to services which may hold the entry named by this DN) could be designed as either a search operation or a new operation. As the feature doesn't complement the search operation (e.g., the operation is not contrived to search for entries held in the Directory Information Tree), it is likely more appropriate to define a new operation using the extended operation mechanism. 3.1. Controls Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for extending existing operations. The existing operation can be a base operation defined in [Protocol] (e.g., search, modify, etc.) or an extended operation (e.g. Start TLS [Protocol], Password Modify [RFC3062]), or an operation defined as an extension to a base or extended operation. Extensions SHOULD NOT return Response controls unless the server has specific knowledge that the client can make use of the control. Generally, the client requests the return of a particular response control by providing a related request control. An existing operation MAY be extended to return IntermediateResponse messages [Protocol, Section 4.13]. Specifications of controls SHALL NOT attach additional semantics to criticality of controls beyond those defined in [Protocol, Section Zeilenga LDAP Extensions [Page 6] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 4.1.11]. A specification MAY mandate the criticality take on a particular value (e.g., TRUE or FALSE) where appropriate. 3.1.1 Extending Bind Operation with Controls Controls attached to the request and response messages of a Bind Operation [Protocol] are not protected by any security layers established by that Bind operation. Specifications detailing controls extending the Bind operation SHALL detail that the Bind negotiated security layers do not protect the information contained in these controls and SHALL detail how the information in these controls is protected or why the information does not need protection. It is RECOMMENDED that designers consider alternative mechanisms for providing the function. For example, an extended operation issued subsequent to the Bind operation, hence protected by the security layers negotiated by the Bind operation, might be used to provided the desired function. Additionally, designers of Bind control extensions MUST also consider how the controls' semantics interact with individual steps of a multi- step Bind operation. It is noted that some steps are optional and hence may require special attention in the design. 3.1.2 Extending the Start TLS Operation with Controls Controls attached to the request and response messages of a Start TLS Operation [Protocol] are not protected by the security layers established by the Start TLS operation. Specifications detailing controls extending the Start TLS operation SHALL detail that the Start TLS negotiated security layers do not protect the information contained in these controls and SHALL detail how the information in these controls is protected or why the information does not need protection. It is RECOMMENDED that designers consider alternative mechanisms for providing the function. For example, an extended operation issued subsequent to the Start TLS operation, hence protected by the security layers negotiated by the Start TLS operation, might be used to provided the desired function. 3.1.3 Extending the Search Operation with Controls Zeilenga LDAP Extensions [Page 7] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 The Search operation processing has two distinct phases: - finding the base object; and - searching for objects at or under that base object. Specifications of controls extending the Search Operation should clearly state in which phase(s) the control's semantics apply. Semantics of controls which are not specific to the Search Operation SHOULD apply in the finding phase. 3.1.4 Extending the Update Operations with Controls Update operations have properties of atomicity, consistency, isolation, and durability ([ACID]). - atomicity: all or none of the DIT changes requested are made, - consistency: the resulting DIT state must be conform to schema and other constraints, - isolation: intermediate states are not exposed, - durability: the resulting DIT state is preserved until subsequently updated. When defining a control which requests additional (or other) DIT changes be made to the DIT, these additional changes SHOULD NOT be treated as part of a separate transaction. The specification MUST be clear as whether the additional DIT changes are part of the same or a separate transaction as the DIT changes expressed in the request of the base operation. When defining a control which requests additional (or other) DIT changes be made to the DIT, the specification MUST be clear as to the order in which these and the base changes are to be applied to the DIT. 3.1.4 Extending the Response-less Operations with Controls The Abandon and Unbind operations do not include a response message. For this reason, specifications for controls designed to be attached to Abandon and Unbind requests SHOULD mandate that the control's criticality be FALSE. 3.2. Extended Operations Extended Operations [Protocol, Section 4.12] is the RECOMMENDED mechanism for defining new operations. An extended operation consists of an ExtendedRequest message, zero or more IntermediateResponse messages, and an ExtendedResponse message. Zeilenga LDAP Extensions [Page 8] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 3.3. Intermediate Responses Extensions SHALL use IntermediateResponse messages instead of ExtendedResponse messages to return intermediate results. 3.4. Unsolicited Notifications Unsolicited notifications [Protocol, Section 4.4] offer a capability for the server to notify the client of events not associated with operation currently being processed. Extensions SHOULD be designed such that unsolicited notifications are not be returned unless the server has specific knowledge that the client can make use of the notification. Generally, the client requests the return of particular unsolicited notification by performing a related extended operation. For example, a time hack extension could be designed to return unsolicited notifications at regular intervals which were enabled by an extended operation (which possibly specified the desired interval). 4. Extending LDAP ASN.1 definition LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1 definition [Protocol, Appendix B] to be made. 4.1. Result Codes Extensions which specify new operations or enhance existing operations often need to define new result codes. The extension SHOULD be designed such that a client has a reasonably clear indication of the nature of the successful or non-successful result. Extensions SHOULD use existing result codes to indicate conditions which are consistent with the intended meaning [Protocol][X.511] of these codes. Extensions MAY introduce new result codes [BCP64bis] where no existing result code provides an adequate indication of the nature of the result. Extensions SHALL NOT disallow nor otherwise restrict the return of general service result codes, especially those reporting a protocol, service, or security problem, or indicating the server is unable or unwilling to complete the operation. Zeilenga LDAP Extensions [Page 9] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 4.2. LDAP Message Types While extensions can specify new types of LDAP messages by extending the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally unnecessary and inappropriate. Existing operation extension mechanisms (e.g., extended operations, unsolicited notifications, and intermediate responses) SHOULD be used instead. However, there may be cases where an extension does not fit well into these mechanisms. In such cases, a new extension mechanism SHOULD be defined which can be used by multiple extensions which have similar needs. 4.3. Authentication Methods The Bind operation currently supports two authentication methods, simple and SASL. SASL [SASL] is an extensible authentication framework used by multiple application-level protocols (e.g. BEEP, IMAP, SMTP). It is RECOMMENDED that new authentication processes be defined as SASL mechanisms. New LDAP authentication methods MAY be added to support new authentication frameworks. The Bind operation primary function is to establish the LDAP association [AuthMeth]. No other operation SHALL be defined (or extended) to establish the LDAP association. However, other operations MAY be defined to establish other security associations (e.g., IPSEC). 4.4. General ASN.1 extensibility Section 4 of [Protocol] states: In order to support future extensions to this protocol, extensibility is implied where it is allowed per ASN.1 (i.e. sequence, set, choice, and enumerated types are extensible). In addition, ellipses (...) have been supplied in ASN.1 types that are explicitly extensible as discussed in [BCP64bis]. Because of the implied extensibility, clients and servers MUST (unless otherwise specified) ignore trailing SEQUENCE components whose tags they do not recognize. Designers SHOULD avoid introducing extensions which rely on unsuspecting implementations to ignore trailing components of SEQUENCE whose tags they do not recognize. 5. Schema Extensions Extensions defining LDAP schema elements SHALL provide schema definitions conformant with syntaxes defined in [Models, Section 4.1]. Zeilenga LDAP Extensions [Page 10] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 While provided definitions MAY be reformatted (line wrapped) for readability, this SHALL be noted in the specification. For definitions allow a NAME field, new schema elements SHOULD provide one and only one name. The name SHOULD be short. Each schema definition allows a DESC field. The DESC field, if provided, SHOULD contain a short descriptive phrase. The DESC field MUST be regarded as informational. That is, the specification MUST be written such that its interpretation is the same with and without the provided DESC fields. The extension SHALL NOT mandate that implementations provide the same DESC field in schema they publish. Implementors MAY replace or remove the DESC field. Published schema elements SHALL NOT be redefined. Replacement schema elements (new OIDs, new NAMEs) SHOULD be defined as needed. Schema designers SHOULD reuse existing schema elements where appropriate. However, any reuse MUST not alter the semantics of the element. 5.1. LDAP Syntaxes Each LDAP syntax is defined in terms of ASN.1 [X.680]. Each extension detailing an LDAP syntax MUST specify the ASN.1 data definition associated with the syntax. A distinct LDAP syntax SHOULD be created for each distinct ASN.1 data definition (including constraints). Each LDAP syntax SHOULD have a string encoding defined for it. It is RECOMMENDED that this string encoding be restricted to a UTF-8 [RFC3629] encoded Unicode [Unicode] characters. Use of Generic String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic string encoding rules to provide string encodings for complex ASN.1 data definitions is RECOMMENDED. Otherwise, it is RECOMMENDED that the string encoding be described using a formal language (e.g., ABNF [ABNF]). Formal languages SHOULD be used in specifications in accordance with IESG guidelines [FORMAL]. If no string encoding is defined, the extension SHALL specify how the transfer encoding is to be indicated. Generally, the extension SHOULD mandate use of ;binary or other transfer encoding option. 5.2. Matching Rules Zeilenga LDAP Extensions [Page 11] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and SUBSTRING) may be associated with an attribute type. In addition, LDAP provides an extensible matching rule mechanism. The matching rule specification SHOULD detail which kind of matching rule it is and SHOULD describe which kinds of values it can be used with. In addition to requirements stated in the LDAP technical specification, equality matching rules SHOULD be commutative. 5.3. Attribute Types Designers SHOULD carefully consider how the structure of values is to restricted. Designers SHOULD consider that servers will only enforce constraints of the attribute's syntax. That is, an attribute intended to hold URIs, but which has directoryString syntax, is not restricted to values which are URIs. Designers SHOULD carefully consider which matching rules, if any, are appropriate for the attribute type. Matching rules specified for an attribute type MUST be compatible with the attribute type's syntax. Extensions specifying operational attributes MUST detail how servers are to maintain and/or utilize values of each operational attribute. 5.4. Object Classes Designers SHOULD carefully consider whether each attributes of an object class is required ("MUST") or allowed ("MAY"). Extensions specifying object classes which allow (or require) operational attributes MUST specify how servers are to maintain and/or utilize entries belonging to these object classes. 6. Other Extension Mechanisms 6.1. Attribute Description Options Each option is identified by a string of letters, numbers, and hyphens. This string SHOULD be short. 6.2. Authorization Identities Zeilenga LDAP Extensions [Page 12] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 Extensions interacting with authorization identities SHALL support the LDAP authzId format [AuthMeth]. The authzId format is extensible. 6.3. LDAP URL Extensions LDAP URL extensions are identified by a short string, a descriptor. Like other descriptors, the string SHOULD be short. 7. Security Considerations LDAP does not place undue restrictions on the kinds of extensions which can be implemented. While this document attempts to outline some specific issues which designers need to consider, it is not (and cannot be) all encompassing. Designers MUST do their own evaluation of the security considerations applicable to their extension. Designers MUST NOT the assume that the LDAP "core" technical specification [Roadmap] adequately addresses the specific concerns surrounding their extension nor assume that their extension has no specific concerns. Extensions specification, however, SHOULD note whether or not security considerations specific to the feature they are extending, as well as general LDAP security considerations, apply to the extension. 8. Acknowledgments The author thanks the IETF LDAP community for their thoughtful comments. This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce Greenblatt. 9. Author's Address Kurt D. Zeilenga OpenLDAP Foundation Email: Kurt@OpenLDAP.org 10. References [[Note to the RFC Editor: please replace the citation tags used in Zeilenga LDAP Extensions [Page 13] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 referencing Internet-Drafts with tags of the form RFCnnnn where possible.]] 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14 (also RFC 2119), March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26 (also RFC 2434), October 1998. [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629 (also STD 63), November 2003. [RFC3641] Legg, S., "Generic String Encoding Rules for ASN.1 Types", RFC 3641, October 2003. [RFC3642] Legg, S., "Common Elements of GSER Encodings", RFC 3642, October 2003. [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674, December 2003. [RFC3866] Zeilenga, K., Ed., "Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)", RFC 3866, July 2004. [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. [Models] Zeilenga, K. (editor), "LDAP: Directory Information Models", draft-ietf-ldapbis-models-xx.txt, a work in progress. [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-ietf-ldapbis-protocol-xx.txt, a work in progress. [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and Connection Level Security Mechanisms", Zeilenga LDAP Extensions [Page 14] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. [LDAPprep] Zeilenga, K., "LDAP: Internationalized String Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in progress. [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in progress. [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", draft-ietf-ldapbis-url-xx.txt, a work in progress. [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String Representation of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in progress. [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. [SASL] Melnikov, A. (Editor), "Simple Authentication and Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). [FORMAL] IESG, "Guidelines for the use of formal languages in IETF specifications", <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt>, 2001. [X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993) (also ISO/IEC 9594-3:1993). [X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Zeilenga LDAP Extensions [Page 15] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). [X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(2002) (also ISO/IEC 8825-1:2002). 10.2. Informative References [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", RFC 3062, February 2000. [ACID] Section 4 of ISO/IEC 10026-1:1992. [GUIDE] Greenblatt, B., "LDAP Extension Style Guide", draft-greenblatt-ldapext-style-xx.txt, an (expired) work in progress. [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress. Full Copyright Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Rights Zeilenga LDAP Extensions [Page 16] INTERNET-DRAFT draft-zeilenga-ldap-ext-10 2 February 2006 The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Zeilenga LDAP Extensions [Page 17]