mirror of
https://git.openldap.org/openldap/openldap.git
synced 2025-12-20 22:59:34 -05:00
supportedFeatures and "+" are now RFCs
This commit is contained in:
Kurt Zeilenga
parent
6c7e753c0d
commit
082087691e
5 changed files with 570 additions and 567 deletions
|
|
@ -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
|
|
||||||
<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]
|
|
||||||
|
|
||||||
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 <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]
|
|
||||||
|
|
||||||
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]
|
|
||||||
|
|
||||||
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]
|
|
||||||
|
|
||||||
|
|
@ -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
|
|
||||||
<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]
|
|
||||||
|
|
||||||
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 <kurt@openldap.org>
|
|
||||||
|
|
||||||
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
|
|
||||||
<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]
|
|
||||||
|
|
||||||
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]
|
|
||||||
|
|
||||||
|
|
@ -32,7 +32,8 @@ rfc3112.txt LDAP Authentication Password Schema (I)
|
||||||
rfc3296.txt Named Subordinate References in LDAP (PS)
|
rfc3296.txt Named Subordinate References in LDAP (PS)
|
||||||
rfc3377.txt LDAP(v3): Technical Specification (PS)
|
rfc3377.txt LDAP(v3): Technical Specification (PS)
|
||||||
rfc3383.txt IANA Considerations for LDAP (BCP)
|
rfc3383.txt IANA Considerations for LDAP (BCP)
|
||||||
|
rfc3673.txt LDAPv3: All Operational Attributes (PS)
|
||||||
|
rfc3674.txt Feature Discovery in LDAP (PS)
|
||||||
|
|
||||||
Legend:
|
Legend:
|
||||||
STD Standard
|
STD Standard
|
||||||
|
|
@ -43,4 +44,6 @@ E Experimental
|
||||||
FYI For Your Information
|
FYI For Your Information
|
||||||
BCP Best Common Practice
|
BCP Best Common Practice
|
||||||
|
|
||||||
|
Please see http://www.rfc-editor.org/ for up-to-date status information.
|
||||||
|
|
||||||
$OpenLDAP$
|
$OpenLDAP$
|
||||||
|
|
|
||||||
283
doc/rfc/rfc3673.txt
Normal file
283
doc/rfc/rfc3673.txt
Normal file
|
|
@ -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 <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]
|
||||||
|
|
||||||
|
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]
|
||||||
|
|
||||||
283
doc/rfc/rfc3674.txt
Normal file
283
doc/rfc/rfc3674.txt
Normal file
|
|
@ -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 <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]
|
||||||
|
|
||||||
|
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]
|
||||||
|
|
||||||
Loading…
Reference in a new issue