From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3674.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc3674.txt (limited to 'doc/rfc/rfc3674.txt') diff --git a/doc/rfc/rfc3674.txt b/doc/rfc/rfc3674.txt new file mode 100644 index 0000000..396bb01 --- /dev/null +++ b/doc/rfc/rfc3674.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 3674 OpenLDAP Foundation +Category: Standards Track December 2003 + + + Feature Discovery in Lightweight Directory Access Protocol (LDAP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The Lightweight Directory Access Protocol (LDAP) is an extensible + protocol with numerous elective features. This document introduces a + general mechanism for discovery of elective features and extensions + which cannot be discovered using existing mechanisms. + +1. Background and Intended Use + + The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an + extensible protocol with numerous elective features. LDAP provides + mechanisms for a client to discover supported protocol versions, + controls, extended operations, Simple Authentication and Security + Layer (SASL) mechanisms, and subschema information. However, these + mechanisms are not designed to support general feature discovery. + + This document describes a simple, general-purpose mechanism which + clients may use to discover the set of elective features supported by + a server. For example, this mechanism could be used by a client to + discover whether or not the server supports requests for all + operational attributes, e.g., "+" [RFC3673]. As another example, + this mechanism could be used to discover absolute true, e.g., "(&)" + and false, e.g., "(|)", search filters [T-F] support. + + This document extends the LDAP Protocol Mechanism registry [RFC3383] + to support registration of values of the supportedFeatures attribute. + This registry is managed by the Internet Assigned Numbers Authority + (IANA). + + + + +Zeilenga Standards Track [Page 1] + +RFC 3674 Feature Discovery in LDAP December 2003 + + + Schema definitions are provided using LDAP description formats + [RFC2252]. Definitions provided here are formatted (line wrapped) + for readability. + + 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]. + +2. Discovery of supported features + + Each elective feature whose support may be discovered SHALL be + identified by an Object Identifier (OID). A server advertises its + support for a given feature by providing the OID associated with the + feature as a value of the 'supportedFeatures' attribute held in the + root DSE. A client may examine the values of this attribute to + determine if a particular feature is supported by the server. A + client MUST ignore values it doesn't recognize as they refer to + elective features it doesn't implement. + + Features associated with Standard Track protocol mechanisms MUST be + registered. Features associated with other protocol mechanisms + SHOULD be registered. Procedures for registering protocol mechanisms + are described in BCP 64 [RFC3383]. The word "Feature" should be + placed in the usage field of the submitted LDAP Protocol Mechanism + template. + + The 'supportedFeatures' attribute type is described as follows: + + ( 1.3.6.1.4.1.4203.1.3.5 + NAME 'supportedFeatures' + DESC 'features supported by the server' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + USAGE dSAOperation ) + + Servers MUST be capable of recognizing this attribute type by the + name 'supportedFeatures'. Servers MAY recognize the attribute type + by other names. + +3. Security Considerations + + As rogue clients can discover features of a server by other means + (such as by trial and error), this feature discovery mechanism is not + believed to introduce any new security risk to LDAP. + + + + + + + +Zeilenga Standards Track [Page 2] + +RFC 3674 Feature Discovery in LDAP December 2003 + + +4. IANA Considerations + +4.1. Registration of Features as Protocol Mechanisms + + Future specifications detailing LDAP features are to register each + feature as a LDAP Protocol Mechanism per guidance given in BCP 64 + [RFC3383]. A usage of "Feature" in a Protocol Mechanism registration + template indicates that the value to be registered is associated with + an LDAP feature. + +4.2. Registration of the supportedFeatures descriptor + + The IANA has registered the LDAP 'supportedFeatures' descriptor. The + following registration template is suggested: + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): supportedFeatures + Object Identifier: 1.3.6.1.4.1.4203.1.3.5 + Person & email address to contact for further information: + Kurt Zeilenga + Usage: Attribute Type + Specification: RFC 3674 + Author/Change Controller: IESG + + This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA + assigned private enterprise allocation [PRIVATE] for use in this + specification. + +5. Acknowledgment + + This document is based upon input from the IETF LDAPEXT working + group. + +6. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + + +Zeilenga Standards Track [Page 3] + +RFC 3674 Feature Discovery in LDAP December 2003 + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute + Syntax Definitions", RFC 2252, December 1997. + + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 3383, September 2002. + +7.2. Informative References + + [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol + version 3 (LDAPv3): All Operational Attributes", RFC + 3673, December 2003. + + [T-F] Zeilenga, K., "LDAP True/False Filters", Work in + Progress. + + [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", + http://www.openldap.org/foundation/oid-delegate.txt. + + [PRIVATE] IANA, "Private Enterprise Numbers", + http://www.iana.org/assignments/enterprise-numbers. + +8. Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + +Zeilenga Standards Track [Page 4] + +RFC 3674 Feature Discovery in LDAP December 2003 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 5] + -- cgit v1.2.3