LCUP meeting summary and Draft report to LDUP WG

On the afternoon of 3/18/03, Kurt and Rich, along with several other 
members of the LDAP and X.500 community, met to discuss the 
applicability of LCUP 
(http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt) versus 
the applicability of LDAP Content Sync 
(http://www.ietf.org/internet-drafts/draft-zeilenga-ldup-sync-01.txt).  
We discussed the 3 main points of contention:

1) Both protocols are concerned with synchronization of directory 
information. LCUP operates generally within the user information model. 
LDAP Content Sync operates generally within the system information model.

Example:  Let's say you have a container ou=People which holds user 
entries.  Furthermore, there is a scheme by which the attribute 
facsimileTelephoneNumber is generated in all user entries - it is a 
virtual or collective attribute.  The definition of this attribute is in 
a subentry of ou=People.

With LCUP, the user wants to sync with the user entries, and wants to 
include the facsimileTelephoneNumber as part of that data.  The user 
issues an LCUP search with a base of ou=People and a scope of one, and 
some arbitrary filter that returns one or more user entries, and the 
facsimileTelephoneNumber attribute in the attribute list.  The user 
receives that data, including the facsimileTelephoneNumber.

With LDAP Content Sync, the user wants to sync with the user entries, 
and wants to include the facsimileTelephoneNumber as part of that data.  
The user issues an LDAP Content Sync search with a base of ou=People and 
a scope of one, and some arbitrary filter that returns one or more user 
entries, and the facsimileTelephoneNumber attribute in the attribute 
list.  The user also includes the LDAP SubEntry control in the search so 
that LDAP SubEntries are returned, specifically the subentry holding the 
virtual or collective attribute definition.  The user receives the data 
for user entries but the facsimileTelephoneNumber attribute is NOT 
present in those entries.  The user also receives the collective 
attribute definition and must derive the facsimileTelephoneNumber for 
user entries.

Consequences:
With LCUP, a change to the collective attribute definition causes every 
entry with that attribute to be reported as modified, which would cause 
either a large number of entries to be returned to the client, either as 
modified entries or via a full resync.  With LDAP Content Sync, a change 
to the collective attribute definition causes only that 1 entry to be 
returned as changed (and all of the other entries in scope to be 
returned as unchanged).

If you wanted to do the same thing as LDAP Content Sync with LCUP in 
this case, you would have to issue 2 separate searches: one search for 
the collective attribute definition including the 
facsimileTelephoneNumber, and one search for the user entries WITHOUT 
the facsimileTelephoneNumber attribute.

With LCUP, the client needs no special knowledge of the physical 
information model.  With LDAP Content Sync, the client MUST know about 
the physical information model.  There is no way the client can use the 
"view" of the user information model.
One proposed solution was to just include a bit in the LCUP protocol 
that would tell the server if the client wanted the user view or the 
physical view, but we decided that a change such as that would make the 
protocol too complex.
.
2) LCUP assumes the server stores historical change information, either 
in a state based system or a log based system, about changes to entries, 
attributes, and values.  LDAP Content Sync does not make this 
assumption, or at least assumes that the absolute minimum state 
information will be present, such as a modifyTimestamp/createTimestamp 
or an entryCSN.

LDAP Content Sync works by sending the full requested entry if modified, 
and sending the DN or UUID of the entry for unchanged entries.  The 
client is responsible for deleting entries from its local store that are 
not returned - this is implicit deletion - entries not returned as 
modified or present are assumed to have been deleted or otherwise 
removed from the search result set.  A consequence of this is that, if 
you have N entries in your search result set, making a modification to 1 
value of 1 entry causes N messages to be sent.

With LCUP, just the 1 entry would be sent, because the historical data 
allows the optimization.

One proposed solution was to include a bit in the LCUP protocol which 
would allow the server to calculate if it would be more efficient to 
send updates+deletes or updates+present entries, and tell the client 
what to expect.  But we thought this would make client implementation 
too hard.

Another proposed solution was to add a bit to LDAP Content Sync to allow 
updates+deletes in addition to our current updates+presents approach 
(allowing an implementation with histories to optimize the traffic).

3) In LCUP, changes to meta data, and subtree rename/delete operations, 
may cause a large number of messages to be sent or force the client to 
resync.  LCUP assumes that these operations are very infrequent and so 
not very expensive.  LDAP Content Sync gets around this issue because it 
always sends a message for every entry in the scope.  This can be an 
advantage in a situation where a large number of entries have been 
deleted or removed from the search scope (e.g. access control change).  
In this case, only a few entries have to be returned as modified or 
present.  Of course, in this case, an LCUP server can conclude that it 
would be prohibitively expensive to send all of these deletions, and 
simply force the client to resync.  This also one case where a single 
change to user information will cause a large number of messages to be 
sent (during persist mode). In LCUP, a single modrdn to a non-leaf entry 
may result in multiple messages (one for the entry, one for each of its 
children) being generated. In LDAP Sync, a single modrdn generates a 
single update (the impact of the modrdn upon children of the entry is 
managed by the client).

The conclusion is that some applications need LCUP and some need LDAP 
Content Sync, and it would make either protocol too complex to try to 
change it to meet the needs of the other.  The LCUP authors and the LDAP 
Content Sync authors each will add a detailed applicability statement to 
the respective documents to allow implementors to better understand the 
assumptions and for what kinds of applications each mechanism is best 
suited for.