RFC 3771: The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message
This RFC has been replaced. Do not implement against it for new work — it was formally obsoleted by RFC 4510, RFC 4511.
Current document in this lineage: RFC 3494 — Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status; RFC 4510 — Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map; RFC 4511 — Lightweight Directory Access Protocol (LDAP): The Protocol; RFC 4512 — Lightweight Directory Access Protocol (LDAP): Directory Information Models; RFC 4513 — Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms; RFC 4514 — Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names; RFC 4515 — Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters; RFC 4516 — Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator; RFC 4517 — Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules; RFC 4519 — Lightweight Directory Access Protocol (LDAP): Schema for User Applications; RFC 4523 — Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates
In plain English — editorial summary, not part of the RFC
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. [STANDARDS-TRACK]
Document record
- Document ID
- RFC3771
- Published
- April 2004
- Authors
- R. Harrison; K. Zeilenga
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- —
- Pages
- 8
- Also known as
- —
- Updates:
- RFC 2251
Topics
Standards lineage
This document is one revision in a chain of 35 RFCs, each formally replacing the one before it.
- RFC 1484 (1993)
- RFC 1485 (1993)
- RFC 1487 (1993)
- RFC 1488 (1993)
- RFC 1558 (1993)
- RFC 1777 (1995)
- RFC 1778 (1995)
- RFC 1779 (1995)
- RFC 1781 (1995)
- RFC 1959 (1996)
- RFC 1960 (1996)
- RFC 2251 (1997)
- RFC 2252 (1997)
- RFC 2253 (1997)
- RFC 2254 (1997)
- RFC 2255 (1997)
- RFC 2256 (1997)
- RFC 2559 (1999)
- RFC 2587 (1999)
- RFC 2829 (2000)
- RFC 2830 (2000)
- RFC 3377 (2002)
- RFC 3494 (2003)
- RFC 3674 (2003)
- RFC 3771 (2004)
- RFC 4510 (2006)
- RFC 4511 (2006)
- RFC 4512 (2006)
- RFC 4513 (2006)
- RFC 4514 (2006)
- RFC 4515 (2006)
- RFC 4516 (2006)
- RFC 4517 (2006)
- RFC 4519 (2006)
- RFC 4523 (2006) ✓
Referenced by
2 later RFCs formally update or obsolete part of this document.
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 4512Lightweight Directory Access Protocol (LDAP): Directory Information ModelsCurrent
June 2006
- RFC 4514Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished NamesCurrent
June 2006
- RFC 4515Lightweight Directory Access Protocol (LDAP): String Representation of Search FiltersCurrent
June 2006
- RFC 4517Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching RulesCurrent
June 2006
- RFC 4523Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 CertificatesCurrent
June 2006
- RFC 2254The String Representation of LDAP Search FiltersObsoleted
December 1997
- RFC 2253Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished NamesObsoleted
December 1997
- RFC 2252Lightweight Directory Access Protocol (v3): Attribute Syntax DefinitionsObsoleted
December 1997
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?