+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 26 May 2003
-
-
- Feature Discovery in LDAP
- <draft-zeilenga-ldap-features-05.txt>
-
-
-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 <ldapext@ietf.org>. Please send editorial comments
- directly to the author <Kurt@OpenLDAP.org>.
-
- 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/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- 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]
-\f
-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]
-\f
-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 <kurt@OpenLDAP.org>
- 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]
-\f
-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
- <Kurt@OpenLDAP.org>
-
-
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 1 November 2002
-
-
-
- LDAPv3: All Operational Attributes
- <draft-zeilenga-ldap-opattrs-05.txt>
-
-
-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 <ldapext@ietf.org>. Please send editorial comments
- directly to the author <Kurt@OpenLDAP.org>.
-
- 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/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- 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]
-\f
-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]
-\f
-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 <kurt@openldap.org>
-
- Usage: Feature
-
- Specification: RFCxxxx
-
- Author/Change Controller: IESG
-
- Comments: none
-
-
-6. Acknowledgment
-
-
-
-
-Zeilenga LDAP All Op Attrs [Page 3]
-\f
-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
- <Kurt@OpenLDAP.org>
-
-
-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]
-\f
-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]
-\f
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
FYI For Your Information
BCP Best Common Practice
+Please see http://www.rfc-editor.org/ for up-to-date status information.
+
$OpenLDAP$
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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 <kurt@openldap.org>
+
+ 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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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 <kurt@OpenLDAP.org>
+ 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]
+\f
+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]
+\f
+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]
+\f
projects / openldap / commitdiff