RE: LDAP Client Update: consideration of alternative proposals

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