The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message
RFC 3771
Document | Type |
RFC - Proposed Standard
(April 2004; No errata)
Updates RFC 2251
Was draft-rharrison-ldap-intermediate-resp (individual in app area)
|
|
---|---|---|---|
Last updated | 2018-07-18 | ||
Stream | IETF | ||
Formats | plain text pdf html bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3771 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
Send notices to | (None) |
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 unsolicitedShow full document text