Re: Is this really an LCUP show stopper?

First, a logistical comment: Rich Megginson is currently enjoying a long 
awaited sabbatical and is probably not reading email right now. I am 
sure he would have a lot to say if he was available, but I think he will 
be out for the next month or so.


Jonghyuk Choi wrote:
> 
> Because even a single omission of delete / modify in history can make
> it impossible to recreate the previous sync result the cookie of a sync
> request refers to, it looks more like a matter of how long the full
> history information is maintained rather than how complete the history
> information is.

LCUP does not require that the server be able to "recreate the previous 
sync result." It requires that the server be able to, based on the 
cookie supplied by the client, generate a set of Sync Update messages 
that allow the client to synchronize with the server. This is a subtle 
difference, but important in some scenarios.


> That is, as to the completeness of history, it is a binary
> decision, not a wide range of variations. How long the full history is
> maintained for sync purpose would give a tradeoff. But it still requires
> maintaining full history in order to benefit even a small from the 
> tradeoff.
> It in fact assumes an implementation option and gives tradeoffs only 
> within that option.

If a server implementor wants to minimize the Sync Update message sent 
to clients and minimize the frequency of full resyncs and support all 
possible sync scenarios, then yes, quite a bit of state information must 
be maintained. But there are some tricks implementors can use to reduce 
the amount of state storage needed. For example, in most environments 
the search criteria used by all of the LCUP clients will involve a very 
small subset of the attribute types and values contained in the DIT. If 
my server only needs to support LCUP requests that use the search filter 
(objectClass=person) then I can reduce the amount of "extra" state 
storage down to a reasonably small amount. It will always be possible to 
come up with examples that make LCUP look bad from one perspective or 
another (wire traffic vs. server implementation burden), but I suspect 
the same is true of most synchronization protocols.


> The concern here is that other mechanisms (full reload / sending excessive
> entries) would be the norm for most cases.

Perhaps your common use cases are different than the ones I have in 
mind. Or maybe you and Kurt are right. But I think we are mainly arguing 
about the validity of the engineering tradeoffs that were made in 
drafting and achieving consensus around draft-ietf-ldup-lcup-05.txt. 
Certainly this is a useful discussion; I hope more people will join in soon.

-Mark Smith
  Netscape