Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes
RFC 3673

 
Document Type RFC - Proposed Standard (December 2003; No errata)
Last updated 2013-03-02
Stream ISE
Formats plain text pdf html
Stream ISE state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3673 (Proposed Standard)
Telechat date
Responsible AD Ted Hardie
Send notices to <kurt@openLDAP.org>
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
Show full document text