From: Kurt Zeilenga Date: Fri, 19 Dec 2003 01:51:02 +0000 (+0000) Subject: supportedFeatures and "+" are now RFCs X-Git-Tag: OPENLDAP_REL_ENG_2_1_MP~137 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=082087691e3bd08bfaaad1e704aebf15fbd52f3f;p=openldap supportedFeatures and "+" are now RFCs --- diff --git a/doc/drafts/draft-zeilenga-ldap-features-xx.txt b/doc/drafts/draft-zeilenga-ldap-features-xx.txt deleted file mode 100644 index 73b6ae4f6a..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-features-xx.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 26 May 2003 - - - Feature Discovery in LDAP - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as an Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extension Working Group - mailing list . Please send editorial comments - directly to the author . - - 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 - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - Please see the Full Copyright section near the end of this document - for more information. - - -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. - - - - - -Zeilenga draft-zeilenga-ldap-features-05 [Page 1] - -INTERNET-DRAFT LDAP supportedFeatures 26 May 2003 - - -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. "+" [OPATTRS]. 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). - - 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 are - described in [RFC3383]. "Feature" should be placed in the usage field - of the submitted LDAP Protocol Mechanism template. - - - - -Zeilenga draft-zeilenga-ldap-features-05 [Page 2] - -INTERNET-DRAFT LDAP supportedFeatures 26 May 2003 - - - 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. - - -4. 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. - - -5. IANA Considerations - -5.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. - - -5.2. Registration of the supportedFeatures descriptor - - It is requested that IANA register upon Standards Action 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 XXXX - Author/Change Controller: IESG - - This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA - - - -Zeilenga draft-zeilenga-ldap-features-05 [Page 3] - -INTERNET-DRAFT LDAP supportedFeatures 26 May 2003 - - - assigned private enterprise allocation [PRIVATE] for use in this - specification. - - -6. Acknowledgment - - This document is based upon input from the IETF LDAPEXT working group. - - -7. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - -8. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2252] Wahl, M., A. Coulbeck, T. Howes, 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., "IANA Considerations for LDAP", BCP 64 - (also RFC 3383), September 2002. - - -9. Informative References - - [OPATTRS] Zeilenga, K., "LDAPv3: All Operational Attributes", - draft-zeilenga-ldap-opattrs-xx.txt, a work in progress. - - [T-F] Zeilenga, K., "LDAP True/False Filters", - draft-zeilenga-ldap-t-f-xx.txt, a 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. - - - - - -Zeilenga draft-zeilenga-ldap-features-05 [Page 4] - -INTERNET-DRAFT LDAP supportedFeatures 26 May 2003 - - -Intellectual Property Rights - - 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. - - 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. - - - -Full Copyright - - 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 implmentation 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. - - - - - - - - - - - -Zeilenga draft-zeilenga-ldap-features-05 [Page 5] - diff --git a/doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt b/doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt deleted file mode 100644 index 38e0bf1a69..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 1 November 2002 - - - - LDAPv3: All Operational Attributes - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extensions Working Group - mailing list . Please send editorial comments - directly to the author . - - 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 - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2002, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - - -Abstract - - The Lightweight Directory Access Protocol (LDAP) supports a mechanism - for requesting the return of all user attributes but not all - operational attributes. This document describes an LDAP extension - which clients may use to request the return of all operational - attributes. - - - -Zeilenga LDAP All Op Attrs [Page 1] - -INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002 - - -1. Overview - - X.500 [X.500] provides a mechanism for clients to request all - operational attributes be returned with entries provided in response - to a search operation. This mechanism is often used by clients to - discover which operational attributes are present in an entry. - - This documents extends the Lightweight Directory Access Protocol - (LDAP) [RFC3377] to provide a simple mechanism which clients may use - to request the return of all operational attributes. The mechanism is - designed for use with existing general purpose LDAP clients (including - web browsers which support LDAP URLs) and existing LDAP APIs. - - 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. All Operational Attributes - - The presence of the attribute description "+" (ASCII 43) in the list - of attributes in a Search Request [RFC2251] SHALL signify a request - for the return of all operational attributes. - - As with all search requests, client implementors should note that - results may not include all requested attributes due to access - controls or other restrictions. Client implementors should also note - that certain operational attributes may be returned only if requested - by name even when "+" is present. This is because some operational - attributes are very expensive to return. - - Servers supporting this feature SHOULD publish the Object Identifier - 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures' - [FEATURES] attribute in the root DSE. - - -3. Interoperability Considerations - - This mechanism is specifically designed to allow users to request all - operational attributes using existing LDAP clients. In particular, - the mechanism is designed to be compatible with existing general - purpose LDAP clients including those supporting LDAP URLs [RFC2255]. - - The addition of this mechanism to LDAP is not believed to cause any - significant interoperability issues (this has been confirmed through - testing). Servers which have yet to implement this specification - should ignore the "+" as an unrecognized attribute description per - [RFC2251, Section 4.5.1]. From the client's perspective, a server - - - -Zeilenga LDAP All Op Attrs [Page 2] - -INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002 - - - which does not return all operational attributes when "+" is requested - should be viewed as having other restrictions. - - It is also noted that this mechanism is believed to require no - modification of existing LDAP APIs. - - -4. Security Considerations - - This document provides a general mechanism which clients may use to - discover operational attributes. Prior to the introduction of this - mechanism, operational attributes where only returned when requested - by name. Some might have viewed this as obscurity" feature. However, - this sense of security as the attributes were still transferable. - - Implementations SHOULD implement appropriate access controls - mechanisms to restricts access to operational attributes. - - -5. IANA Considerations - - This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the - feature described above. This OID was assigned [ASSIGN] by OpenLDAP - Foundation, under its IANA-assigned private enterprise allocation - [PRIVATE], for use in this specification. - - Registration of this feature is requested [FEATURES][RFC3383]. - - Subject: Request for LDAP Protocol Mechanism Registration - - Object Identifier: 1.3.6.1.4.1.4203.1.5.1 - - Description: All Op Attrs - - Person & email address to contact for further information: - Kurt Zeilenga - - Usage: Feature - - Specification: RFCxxxx - - Author/Change Controller: IESG - - Comments: none - - -6. Acknowledgment - - - - -Zeilenga LDAP All Op Attrs [Page 3] - -INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002 - - - The "+" mechanism is believed to have been first suggested by Bruce - Greenblatt in a November 1998 post to the IETF LDAPext Working Group - mailing list. - - -7. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - -8. Normative References - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol - (v3): Technical Specification", RFC 3377, September 2002. - - [FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga- - ldap-features-xx.txt (a work in progress). - - -9. Informative References - - [RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255, - December 1997. - - [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also - RFC 3383), September 2002. - - [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, - Models and Service", 1993. - - [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. - - -Copyright 2002, The Internet Society. All Rights Reserved. - - This document and translations of it may be copied and furnished to - - - -Zeilenga LDAP All Op Attrs [Page 4] - -INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002 - - - 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 assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE AUTHORS, 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga LDAP All Op Attrs [Page 5] - diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX index 56418ae152..63ea38f5f8 100644 --- a/doc/rfc/INDEX +++ b/doc/rfc/INDEX @@ -32,7 +32,8 @@ rfc3112.txt LDAP Authentication Password Schema (I) rfc3296.txt Named Subordinate References in LDAP (PS) rfc3377.txt LDAP(v3): Technical Specification (PS) rfc3383.txt IANA Considerations for LDAP (BCP) - +rfc3673.txt LDAPv3: All Operational Attributes (PS) +rfc3674.txt Feature Discovery in LDAP (PS) Legend: STD Standard @@ -43,4 +44,6 @@ E Experimental FYI For Your Information BCP Best Common Practice +Please see http://www.rfc-editor.org/ for up-to-date status information. + $OpenLDAP$ diff --git a/doc/rfc/rfc3673.txt b/doc/rfc/rfc3673.txt new file mode 100644 index 0000000000..97aed74d89 --- /dev/null +++ b/doc/rfc/rfc3673.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 3673 OpenLDAP Foundation +Category: Standards Track December 2003 + + + Lightweight Directory Access Protocol version 3 (LDAPv3): + All Operational Attributes + +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) supports a mechanism + for requesting the return of all user attributes but not all + operational attributes. This document describes an LDAP extension + which clients may use to request the return of all operational + attributes. + +1. Overview + + X.500 [X.500] provides a mechanism for clients to request all + operational attributes be returned with entries provided in response + to a search operation. This mechanism is often used by clients to + discover which operational attributes are present in an entry. + + This documents extends the Lightweight Directory Access Protocol + (LDAP) [RFC3377] to provide a simple mechanism which clients may use + to request the return of all operational attributes. The mechanism + is designed for use with existing general purpose LDAP clients + (including web browsers which support LDAP URLs) and existing LDAP + APIs. + + 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]. + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 3673 LDAPv3: All Operational Attributes December 2003 + + +2. All Operational Attributes + + The presence of the attribute description "+" (ASCII 43) in the list + of attributes in a Search Request [RFC2251] SHALL signify a request + for the return of all operational attributes. + + As with all search requests, client implementors should note that + results may not include all requested attributes due to access + controls or other restrictions. Client implementors should also note + that certain operational attributes may be returned only if requested + by name even when "+" is present. This is because some operational + attributes are very expensive to return. + + Servers supporting this feature SHOULD publish the Object Identifier + 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures' + [RFC3674] attribute in the root DSE. + +3. Interoperability Considerations + + This mechanism is specifically designed to allow users to request all + operational attributes using existing LDAP clients. In particular, + the mechanism is designed to be compatible with existing general + purpose LDAP clients including those supporting LDAP URLs [RFC2255]. + + The addition of this mechanism to LDAP is not believed to cause any + significant interoperability issues (this has been confirmed through + testing). Servers which have yet to implement this specification + should ignore the "+" as an unrecognized attribute description per + [RFC2251, Section 4.5.1]. From the client's perspective, a server + which does not return all operational attributes when "+" is + requested should be viewed as having other restrictions. + + It is also noted that this mechanism is believed to require no + modification of existing LDAP APIs. + +4. Security Considerations + + This document provides a general mechanism which clients may use to + discover operational attributes. Prior to the introduction of this + mechanism, operational attributes were only returned when requested + by name. Some might have viewed this as obscurity feature. However, + this feature offers a false sense of security as the attributes were + still transferable. + + Implementations SHOULD implement appropriate access controls + mechanisms to restricts access to operational attributes. + + + + + +Zeilenga Standards Track [Page 2] + +RFC 3673 LDAPv3: All Operational Attributes December 2003 + + +5. IANA Considerations + + This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the + feature described above. This OID was assigned [ASSIGN] by OpenLDAP + Foundation, under its IANA-assigned private enterprise allocation + [PRIVATE], for use in this specification. + + Registration of this feature has been completed by IANA [RFC3674], + [RFC3383]. + + Subject: Request for LDAP Protocol Mechanism Registration + + Object Identifier: 1.3.6.1.4.1.4203.1.5.1 + + Description: All Op Attrs + + Person & email address to contact for further information: + Kurt Zeilenga + + Usage: Feature + + Specification: RFC3673 + + Author/Change Controller: IESG + + Comments: none + +6. Acknowledgment + + The "+" mechanism is believed to have been first suggested by Bruce + Greenblatt in a November 1998 post to the IETF LDAPext Working Group + mailing list. + +7. 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 3673 LDAPv3: All Operational Attributes 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. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + [RFC3674] Zeilenga, K., "Feature Discovery in Lightweight Directory + Access Protocol (LDAP)", RFC 3674, December 2003. + +8.2. Informative References + + [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, + December 1997. + + [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 3383, September 2002. + + [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, + Models and Service", 1993. + + [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. + +9. Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + +Zeilenga Standards Track [Page 4] + +RFC 3673 LDAPv3: All Operational Attributes December 2003 + + +10. 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] + diff --git a/doc/rfc/rfc3674.txt b/doc/rfc/rfc3674.txt new file mode 100644 index 0000000000..396bb010bc --- /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] +