[Date Prev][Date Next]
Re: When to delete client content during RFC4533 synchronization?
- To: firstname.lastname@example.org
- Subject: Re: When to delete client content during RFC4533 synchronization?
- From: "Erik van Oosten" <email@example.com>
- Date: Thu, 1 Nov 2007 12:09:04 +0100 (CET)
- Importance: Normal
- In-reply-to: <4728CF93.firstname.lastname@example.org>
- References: <47288DFD.email@example.com> <4728CF93.firstname.lastname@example.org>
- User-agent: SquirrelMail/1.4.8
> Your use of the words "client" and "server" seem inconsistent here. The
> above questions made no sense to me. Servers don't send polls.
Sorry, my interpretation of RFC4533 terminology :) . What I read is that
the client may select from 2 modes of operation (by providing an initial
cookie). The first is described in the section called "initial content
poll", the second is called "content update poll". The server may however
ignore the request for a content update poll and do an "initial content
I was writing about that the client can not reliably determine which mode
was selected by the server. But I now see that it does not matter; at both
the end of the "initial content poll" /and/ at the end of present phase
(that is, without a delete phase) one should delete all unmentioned client
> If the client receives a SyncInfoMessage with refreshPresent and
> refreshDone set to TRUE that means there's only a present phase
> and no delete phase. ...
Indeed. With the addition that this message is used to end both the
"initial content poll" as the "content update poll".
> ... Therefore, any entry that wasn't marked
> present or added must be deleted.
Still, this interpretation can not be correct. When I run my sync client
program against OpenLDAP (2.3.36), and then restart it after the refresh
stage with the last received cookie (note: the DIT remains unchanged), the
first message is exactly that SyncInfoMessage of refreshPresent with
refreshDone set to TRUE. Using our interpretation I should now delete all
client content! Since the DIT was not changed this is clearly wrong. (By
the way the new server cookie is the same as the initial cookie, but
depending on this is tricky; the client should never interpret the
I am quite confused here. Where is the error in our reasoning?
> -- Howard Chu
> Chief Architect, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
Erik van Oosten