Lightweight Directory Access Protocol (LDAP) Transactions
RFC 5805

Document Type RFC - Experimental (March 2010; Errata)
Author Kurt Zeilenga 
Last updated 2018-01-30
Stream Independent Submission
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream ISE state (None)
Consensus Boilerplate Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5805 (Experimental)
Action Holders
Telechat date
Responsible AD Alexey Melnikov
Send notices to
Independent Submission                                       K. Zeilenga
Request for Comments: 5805                                 Isode Limited
Category: Experimental                                        March 2010
ISSN: 2070-1721

       Lightweight Directory Access Protocol (LDAP) Transactions


   Lightweight Directory Access Protocol (LDAP) update operations, such
   as Add, Delete, and Modify operations, have atomic, consistency,
   isolation, durability (ACID) properties.  Each of these update
   operations act upon an entry.  It is often desirable to update two or
   more entries in a single unit of interaction, a transaction.
   Transactions are necessary to support a number of applications
   including resource provisioning.  This document extends LDAP to
   support transactions.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and

   This document defines an Experimental Protocol for the Internet
   community.  This is a contribution to the RFC Series, independently
   of any other RFC stream.  The RFC Editor has chosen to publish this
   document at its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Zeilenga                      Experimental                      [Page 1]
RFC 5805                    LDAP Transactions                 March 2010

1.  Overview

   This document extends the Lightweight Directory Access Protocol
   (LDAP) [RFC4510] to allow clients to relate a number of update
   operations [RFC4511] and have them performed as one unit of
   interaction, a transaction.  As with distinct update operations, each
   transaction has atomic, consistency, isolation, and durability (ACID)
   properties [ACID].

   This extension consists of two extended operations, one control, and
   one unsolicited notification message.  The Start Transaction
   operation is used to obtain a transaction identifier.  This
   identifier is then attached to multiple update operations to indicate
   that they belong to the transaction using the Transaction
   Specification control.  The End Transaction is used to settle (commit
   or abort) the transaction.  The Aborted Transaction Notice is
   provided by the server to notify the client that the server is no
   longer willing or able to process an outstanding transaction.

1.1.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Protocol elements are described using ASN.1 [X.680] with implicit
   tags.  The term "BER-encoded" means the element is to be encoded
   using the Basic Encoding Rules [X.690] under the restrictions
   detailed in Section 5.1 of [RFC4511].

   DSA stands for "Directory System Agent" (a server).  DSE stands for
   "DSA-specific entry".

2.  Elements of an LDAP Transaction

2.1.  Start Transaction Request and Response

   A Start Transaction Request is an LDAPMessage of CHOICE extendedReq
   where the requestName is and the requestValue is

   A Start Transaction Response is an LDAPMessage of CHOICE extendedRes
   sent in response to a Start Transaction Request.  Its responseName is
   absent.  When the resultCode is success (0), responseValue is present
   and contains a transaction identifier.  Otherwise, the responseValue
   is absent.

Zeilenga                      Experimental                      [Page 2]
RFC 5805                    LDAP Transactions                 March 2010

2.2.  Transaction Specification Control

   A Transaction Specification Control is an LDAPControl where the
   controlType is, the criticality is TRUE, and the
   controlValue is a transaction identifier.  The control is appropriate
   for update requests including Add, Delete, Modify, and ModifyDN
   (Rename) requests [RFC4511], as well as the Password Modify requests

   As discussed in Section 4, the Transaction Specification control can
   be used in conjunction with request controls appropriate for the
Show full document text