The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message
RFC 3771

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                        R. Harrison
Request for Comments: 3771                                  Novell, Inc.
Updates: 2251                                                K. Zeilenga
Category: Standards Track                            OpenLDAP Foundation
                                                              April 2004

           The Lightweight Directory Access Protocol (LDAP)
                     Intermediate Response Message

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 (2004).  All Rights Reserved.

Abstract

   This document defines and describes the IntermediateResponse message,
   a general mechanism for defining single-request/multiple-response
   operations in Lightweight Directory Access Protocol (LDAP).  The
   IntermediateResponse message is defined in such a way that the
   protocol behavior of existing LDAP operations is maintained.  This
   message is intended to be used in conjunction with the LDAP
   ExtendedRequest and ExtendedResponse to define new single-
   request/multiple-response operations or in conjunction with a control
   when extending existing LDAP operations in a way that requires them
   to return intermediate response information.

Harrison & Zeilenga         Standards Track                     [Page 1]
RFC 3771               LDAP Intermediate Response             April 2004

1.  Introduction

   The Lightweight Directory Access Protocol (LDAP), version 3 [RFC3377]
   is an extensible protocol.  Extended operations ([RFC2251] Section
   4.12) are defined to allow for the addition of operations to LDAP,
   without requiring revisions of the protocol.  Similarly, controls
   ([RFC2251] Section 4.1.12) are defined to extend or modify the
   behavior of existing LDAP operations.

   LDAP is a client-request/server-response based protocol.  With the
   exception of the search operation, the entire response to an
   operation request is returned in a single protocol data unit (i.e.,
   LDAP message).  While this single-request/single-response paradigm is
   sufficient for many operations (including all but one of those
   currently defined by [RFC3377]), both intuition and practical
   experience validate the notion that it is insufficient for others.

   For example, the LDAP delete operation could be extended via a
   subtree control to mean that an entire subtree is to be deleted.  A
   subtree delete operation needs to return continuation references
   based upon subordinate knowledge information contained in the server
   so that the client can complete the operation.  Returning references
   as they are found, instead of with the final result, allows the
   client to perform the operation more efficiently because it does not
   have to wait for the final result to get this continuation reference
   information.

   Similarly, an engineer might choose to design the subtree delete
   operation as an extended operation of its own rather than using a
   subtree control in conjunction with the delete operation.  Once
   again, the same continuation reference information is needed by the
   client to complete the operation, and sending the continuation
   references as they are found would allow the client to perform the
   operation more efficiently.

   Operations that are completed in stages or that progress through
   various states as they are completed might want to send intermediate
   responses to the client, thereby informing it of the status of the
   operation.  For example, an LDAP implementation might define an
   extended operation to create a new replica of an administrative area
   on a server, and the operation is completed in three stages: (1)
   begin creation of replica, (2) send replica data to server, (3)
   replica creation complete.  Intermediate messages might be sent from
   the server to the client at the beginning of each stage with the
   final response for the extended operation being sent after stage (3)
   is complete.

Harrison & Zeilenga         Standards Track                     [Page 2]
RFC 3771               LDAP Intermediate Response             April 2004

   As LDAP [RFC3377] is currently defined, there is no general LDAP
   message type that can be used to return intermediate results.  A
   single, reusable LDAP message for carrying intermediate response
   information is desired to avoid repeated modification of the
   protocol.  Although the ExtendedResponse message is defined in LDAP,
   it is defined to be the one and only response message to an
   ExtendedRequest message ([RFC2251] Section 4.12), for unsolicited