Subject: I-D ACTION:draft-ietf-ldup-lcup-04.txt

From: [email-masked]
Date: Fri, 07 Mar 2003 06:53:38 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF.

	Title		: LDAP Client Update Protocol
	Author(s)	: R. Megginson, M. Smith, O. Natkovich, J. Parham
	Filename	: draft-ietf-ldup-lcup-04.txt
	Pages		: 27
	Date		: 2003-3-6
	
This document defines the Lightweight Directory Access Protocol 
(LDAP) Client Update Protocol (LCUP). The protocol is intended to 
allow an LDAP client to synchronize with the content of a directory 
information tree (DIT) stored by an LDAP server and to be notified 
about the changes to that content.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldup-lcup-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ldup-lcup-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 09 Mar 2003 08:13:25 -0800

Is it the authors intent to allow state-based server 
implementation of this protocol?  It appears to me that
server implementations would need to maintain historical
information in order to appropriately support this
protocol.

Kurt

At 03:53 AM 3/7/2003, [email-masked] wrote:
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-ldup-lcup-04.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt>

---

From: [email-masked] (Rich Megginson)
Date: Mon, 10 Mar 2003 08:09:10 -0700

Kurt D. Zeilenga wrote:

>implementation of this protocol?
>
Yes.

>It appears to me that
Could you elaborate?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 Mar 2003 09:37:16 -0800

>>information in order to appropriately support this

The most obvious problems are with the requests for content
refresh.

Without historical information, a server has no means to
determine whether or not an entry whose state indicates it was
updated (add,modify,rename) since the previous refresh
request has left the content.  It can only determine whether
the updated entry is currently in the content or not.  The
server must assume the entry was previously in the content.
Hence, the server must generate a message (update or entryLeft)
for each updated entry in the context or require a reload.

But worse, if any entry was deleted from the context, a
server which maintains no historical information is forced
to respond that a reload is required.

Kurt

>>Kurt
>>
>>At 03:53 AM 3/7/2003, <mailto:[email-masked]>[email-masked] wrote:
>>  
>>>
>>><http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt>http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt
>>>
>>><http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html 
>>>or <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>>       <mailto:[email-masked]>[email-masked].
>>>In the body type:
>>>Content-ID:     <mailto:[email-masked]><[email-masked]>
>>>
>>>ENCODING mime

---

From: John Merrells <[email-masked]>
Date: Mon, 10 Mar 2003 10:33:56 -0800

Hmm. I can't resist dipping into this thread.

>Without historical information, 
>
In a state-based system the state records the history.

>a server has no means to
A state-based system can record the deleted/left entires in its state.

>to respond that a reload is required.
Too bad. The server implementation is up to the server implementor. The
server can store no state, some state, or all state. The trade off is server
storage and server code complexity against client efficiency,

John

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 Mar 2003 11:18:44 -0800

>In a state-based system the state records the history.

When I referred to a "state-based" system, I hoped it was
obvious that I was referring to a system which maintained
the current state of directory and meta information but
did not maintain historical state information, in particular
histories of state and/or content updates.  If this was
unclear, I apologize.

>A state-based system can record the deleted/left entires in its state.

I do not view such a system as being a state-based system.
I view it as a log-based system.   Do we need to more precisely
defined these terms?

>Too bad. The server implementation is up to the server implementor.

I disagree.  Every technical specifications limit implementation
approaches to those which can produce conformant implementations.
However, standard track technical specifications should avoid
placing undue constraints on implementation details.

Here I believe, as the author clarified, it was not/is not the
intent of the authors to preclude a state-based implementation
approach.  My follow-up message serves only to elaborate on why I
believe the technical specification does preclude state-based
implementation approaches.

It is possible that the authors misunderstood my initial question
in this thread.  If so, I assume they will post a clarification.

>The server can store no state, some state, or all state.

I believe that LCUP should be designed such that implementors may
choose whether to pursue a state-based or a log-based approach
(or, possibly, some hybrid approach).  I am attempting to demonstrate
how the current specification precludes the state-base (e.g., no
history) approach.

Kurt

---

From: John Merrells <[email-masked]>
Date: Mon, 10 Mar 2003 11:34:56 -0800

> histories of state and/or content updates.  If this was

Yes... the ldup documents use state-based to refer to systems
that store the historical information as state, rather than
log-based systems which store the historical information in a
change log.

Let's call your scenario 'no-history'. This is how I think a 'no-
history' session would work...

The client has a snapshot of the directory at some point. This
point is defined by the lcup cookie it received with the data.
The server is in a particular state, and knows nothing about
its previous states. When the client begins an lcup session
with the server it offers up its cookie. The server is unable
to determine the difference between the cookie point and
the current point so must therefore send everything. The
client now has a current snapshot and a new cookie.

Synchronization has been achieved, albeit rather inefficiently.

John

---

From: [email-masked] (Rich Megginson)
Date: Mon, 10 Mar 2003 12:43:10 -0700

>histories of state and/or content updates.  If this was
I think we do need to be clear on the definitions.  I assumed that a 
state based system would store some historical state information. 
 That's one of the implicit assumptions of the LCUP draft.

It is definitely not the intention of the authors of LCUP that the 
server has to store any histories of content updates.  That is in fact 
stated pretty clearly in the document.  If there is some wording in the 
document that suggests otherwise, I'd like to know about it and remove 
it/change it.

>I view it as a log-based system.   Do we need to more precisely
Yes.  A state based system can store historical state.  One of the 
assumptions of LCUP is that the server already has some sort of 
underlying historical information storage model, like a log or a 
state-based system with historical information.

>placing undue constraints on implementation details.
Define "undue".

>how the current specification precludes the state-base (e.g., no
But I don't want to force implementations to have to send every single 
entry in the LCUP context for every sync session, either the full entry 
(or at least the requested set of attributes) or just the DN.  I just 
don't think that approach will scale and I think it will be more 
unpopular than having to store some historical information.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 Mar 2003 12:15:28 -0800

Given the confusion over terminology, I suggest we start over.

Is it the authors intent to allow a "no-histories"-based server
implementation approach of this protocol?

A "no-histories" implementation approach is one where the server
does not maintain histories of directory or meta information changes
but instead relies on the current directory and meta information
and the "cookie".

It appears to me that server implementations would need
to maintain historical directory and meta information in
order to appropriately support this protocol.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 Mar 2003 12:34:06 -0800

At 11:43 AM 3/10/2003, Rich Megginson wrote:
>It is definitely not the intention of the authors of LCUP that the server has to store any histories of content updates.
[...]
>A state based system can store historical state.  One of the assumptions of LCUP is that the server already has some sort of underlying historical information storage model, like a log or a state-based system with historical information.

How do you reconcile your statement that a server need not store
any histories with your statement that LCUP assumes an historical
information storage model?  They seem counter to each other.

>>placing undue constraints on implementation details.

"inappropriate" or "improper".

---

From: [email-masked] (Rich Megginson)
Date: Mon, 10 Mar 2003 13:45:10 -0700

>information storage model?  They seem counter to each other.
Another misunderstanding.  I meant that we did not intend a server 
implementing LCUP to have to store any information specific to a client, 
like the last content update for a particular client.

>"inappropriate" or "improper". 
I just don't see how ANY synchronization protocol that attempts to not 
send every entry every sync session can be useful or even possible if 
the server stores no historical (even very recent) state information.