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

Document Type RFC - Proposed Standard (December 2003; No errata)
Was draft-zeilenga-ldap-opattrs (individual in app area)
Author Kurt Zeilenga 
Last updated 2018-07-18
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3673 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Ted Hardie
Send notices to (None)
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.


   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

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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 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 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],

   Subject: Request for LDAP Protocol Mechanism Registration

   Object Identifier:

   Description: All Op Attrs
Show full document text