Re: [ldapext] Content Synchronization Operation + Transactions

Petr Spacek <> Mon, 29 June 2015 12:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B47E91A908B for <>; Mon, 29 Jun 2015 05:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F1KQl6SdZt7P for <>; Mon, 29 Jun 2015 05:07:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E9411A908D for <>; Mon, 29 Jun 2015 05:07:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 0A983B66AD for <>; Mon, 29 Jun 2015 12:07:55 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id t5TC7rcX018190 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <>; Mon, 29 Jun 2015 08:07:54 -0400
Message-ID: <>
Date: Mon, 29 Jun 2015 14:07:53 +0200
From: Petr Spacek <>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on
Archived-At: <>
Subject: Re: [ldapext] Content Synchronization Operation + Transactions
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Jun 2015 12:07:56 -0000

On 3.6.2015 09:35, Petr Spacek wrote:
> Hello,
> it seems to me that LDAP Transactions (RFC 5805) are not perfectly integrated
> into Content Synchronization Operation (RFC 4533).
> Mainly the client has no idea what changes were part of single transaction. As
> a result, client cannot replicate transactions reliably, especially when
> connection drops in the middle of persist phase of Content Synchronization
> Operation.
> Also some clients could use the information where LDAP transaction
> started/ended for application-level transactions (if the application uses the
> data in real-time) or possibly some optimizations (if some application-level
> work needs to be done after each group of updates).
> I'm going to sketch -00 draft which will attempt to address this, probably by
> adding new messages to indicate where transaction started and ended.
> Naturally, this makes sense only for persist phase.

The 00 version of the draft is now available. I would really appreciate any

Particularly, I'm not very sure that "transaction identifier" in "End
Transaction Notification Message" is the best idea.

The latest working version of the document is also available from Github:

Pull requests are also more than welcome :-)

Petr^2 Spacek

-------- Forwarded Message --------
Subject: New Version Notification for
Date: Mon, 29 Jun 2015 04:57:56 -0700
To: Petr Spacek <>om>, Petr Spacek <>

A new version of I-D, draft-spacek-ldapext-syncrepl-transaction-00.txt
has been successfully submitted by Petr Spacek and posted to the
IETF repository.

Name:		draft-spacek-ldapext-syncrepl-transaction
Revision:	00
Title:		The Lightweight Directory Access Protocol (LDAP) Content
Synchronization Operation with Transactions
Document date:	2015-06-29
Group:		Individual Submission
Pages:		5

   This document specifies LDAP Control which extends the persist stage
   of the Content Synchronization Operation with information about LDAP
   transaction boundaries.  This information can be used to support
   application-level transactions or for application-level