RE: LDAP Client Update: consideration of alternative proposals

Irony is having someone else argue for state-based synchronization
approaches after going so long with LDUP in which no one was
interested in them.  

As I recall, some of us thought the implementation choice of the
backend didn't matter to the consumers of the protocol, until
we ran into all the various ordering constraints necessary
to deal with partial transfers of changes (necessary in 
the absence of commit/rollback semantics, if you want to
avoid retransmission of already sent changes).

I'm glad I'm not the one trying to justify them, this time.
>>> "Kurt D. Zeilenga" <[email protected]> 6/3/2003 6:15:00 PM >>>

At 08:37 AM 5/29/2003, Chris Apple wrote:
>Perhaps one source of difficulty in discussions
>related to this topic is that there is not
>agreement between yourself and the editors
>of LCUP as to how broad a range of applicability
>is appropriate for the LCUP deliverable?

It's my opinion that LCUP deliverable should be generally
applicable to directory applications needing content
synchronization facilities.  Both drafts seem to have the
same applicability in terms of directory applications they
apply to, how they differ significantly in the kinds of
constraints they place on their implementations.

I use the term constraint here instead of requirement to
highlight the distinction of fulfilling a need of the
directory applications versus of fulfilling a need of the
design of a protocol.

Our basic application requirement is that protocol provide
efficient and effective content synchronization, with modes
for polling for changes and listing for changes.  Efficient
implies a need to manage protocol exchanges to minimize
traffic in most cases while generally avoiding "overly"
chatty behavior.  Effective implies a need for a reasonable
level of data consistency.

Applications could care less of whether their requirement
was met using a history based approach or using state
indicators based approach, that's an server implementation
detail to them.   Hence, draft-ietf-ldup-lcup need for
servers to maintain and use history information is not an
application requirement but a design constraint.

I consider the draft-ietf-ldup-lcup's history design
constraint unreasonable.  This constraint certainly will
will have an impact on its wide adoption as a technical
solution to the general problem.

Kurt