INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 17 May 2002
+Expires in six months 1 November 2002
LDAPv3: All Operational Attributes
- <draft-zeilenga-ldap-opattrs-03.txt>
+ <draft-zeilenga-ldap-opattrs-05.txt>
Status of this Memo
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 <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
+ 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
Abstract
The Lightweight Directory Access Protocol (LDAP) supports a mechanism
- for requesting the return of all user attributes but does not all
+ 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-03 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
1. Overview
to a search operation. This mechanism is often used by clients to
discover which operational attributes are present in an entry.
- This documents extends LDAP [RFC2251] to provide a simple mechanism
- which clients may use to request the return of all operation
- attributes. The mechanism is designed for use with existing general
- purpose LDAP clients (including web browsers which support LDAP URLs)
- and existing LDAP API.
+ 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
2. All Operational Attributes
The presence of the attribute description "+" (ASCII 43) in the list
- of attributes in a Search Request SHALL signify a request for the
- return of all operational attributes.
+ 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. Clients implementors should also note
+ 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.
+ 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 includes web browsers which support LDAP URLs
- [RFC2255].
+ purpose LDAP clients including those supporting LDAP URLs [RFC2255].
- The addition of this mechanism to LDAPv3 is believed not to cause any
+ 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
+ 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-03 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
- [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.
4. Security Considerations
- This document provides a mechanism which clients may use to discover
- operational attributes. Those relying on security by obscurity SHOULD
- implement appropriate access controls to restricts access to
- operational attributes per local policy.
+ 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
- No IANA assignments are requested.
+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.
+ 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.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
-
-
-
-Zeilenga LDAP All Op Attrs [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
-
+ [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).
[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.
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,
-Zeilenga LDAP All Op Attrs [Page 4]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP All Op Attrs [Page 5]
\f
projects / openldap / blobdiff