The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message
obsoleted by
- rfc-4510 — Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map
- rfc-4511 — Lightweight Directory Access Protocol (LDAP): The Protocol
updates
- rfc-2251 — Lightweight Directory Access Protocol (v3)
Extracted elements (14)
A new IntermediateResponse message type was introduced rather than reusing ExtendedResponse as a general intermediate response mechanism because adapting ExtendedResponse would likely require existing APIs to be redesigned and was believed to cause interoperability problems with existing deployed implementations.
A single, reusable LDAP message for carrying intermediate response information was desired to avoid repeated modification of the protocol each time a new multi-response operation needed to be defined.
Returning continuation references and intermediate status information as they are found (rather than with the final result) allows the client to perform multi-stage operations more efficiently, motivating the need for an intermediate response mechanism beyond the existing single-request/single-response paradigm.
Support for IntermediateResponse messages is advertised implicitly via the supportedExtension and supportedControl attributes of the root DSE; no separate advertisement mechanism is needed since IntermediateResponse is always associated with a specific extension or control.
Use of ExtendedResponse messages in response to LDAP search operations with controls (as permitted by RFC 2251 Section 4.5.2) SHOULD be viewed as deprecated in favor of IntermediateResponse messages.
A request control that defines the return of multiple kinds of IntermediateResponse messages MUST provide and document a mechanism for the client to distinguish the kind being sent, via different responseName values or identifying information in the responseValue.
All IntermediateResponse messages associated with request controls SHALL include a responseName, ensuring the client can correctly identify the source when multiple controls or a mix of controls and extended operations use IntermediateResponse messages.
An extended operation that defines the return of multiple kinds of IntermediateResponse messages MUST provide and document a mechanism for the client to distinguish the kind being sent, either by using different responseName values or by including identifying information in the responseValue.
IntermediateResponse messages SHALL NOT be returned to the client unless the client issues a request that specifically solicits their return. Two forms of solicitation are defined: extended operation and request control.
The value of the responseName (if present), the syntax of the responseValue (if present), and the semantics associated with a particular IntermediateResponse message MUST be specified in documents describing the extended operation or request control that uses them.
A single-request/multiple-response operation is structured as a single ExtendedRequest soliciting zero or more IntermediateResponse messages of one or more kinds, followed by exactly one ExtendedResponse message.
IANA registered LDAP Message Type 25 to identify the IntermediateResponse message. The registration is under RFC 3383 (IANA Considerations for LDAP), with IESG as change controller.
This document introduces no new security considerations to LDAP; all security considerations of RFC 3377 apply. Security considerations specific to each extension using IntermediateResponse shall be discussed in the technical specification for that extension.
IntermediateResponse is encoded as APPLICATION 25, a SEQUENCE containing an optional responseName field (tag [0], type LDAPOID) and an optional responseValue field (tag [1], type OCTET STRING). It extends the protocolOp CHOICE of LDAPMessage.