Re: Applicability of LDAP Content Sync to loosely coupled replica sets
[email protected] (Mark C Smith) Mon, 09 Jun 2003 10:18:09 -0400
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Organization | Netscape Communications Corp. |
| Message-ID | <[email protected]> |
John McMeeking wrote: > > > > > I think either of the sync proposals could be made to work with loosely > coupled replicas if: > 1) the replication mechanism supports something like LDUP's "update vector" > -- something that indicates the latest information a replica has seen from > other replicas, AND > 2) the cookie contains the equivalent of an update vector, AND > 3) there is a defined cookie format that is understood by the DSAs the > client syncs with (possibly requested by the client) > > This is already described in the back of LCUP, but it applies to both sync > proposals. > > Or did I misinterpret this discussion? > > [BTW - (3) is something else that is missing from draft-zeilenga-ldup-sync, > but I'm almost convinced it isn't needed. Read on.] In the past, there were very strong feelings expressed by several LDUP WG members that a defined cookie format IS needed. Assume Server A was written by Vendor A and Server B by Vendor B. Without a well defined cookie format, an LCUP client will not be able synchronize with Server A today and with Server B tomorrow without doing a full reload. While I think we are some distance away from being ready to define a standard cookie format, I do agree we will want to do so eventually. Hence the cookie scheme identifier (OID) contained in the LCUP working group deliverable. Because I interpreted the recent charge from the WG chairs and ADs as "focus on whether draft-ietf-ldup-lcup-05 has any show stopper problems" I have avoided diving into a detailed discussion of draft-zeilenga-ldup-sync. But one comment related to this cookie issue: the text in draft-zeilenga-ldup-sync leads me to believe that its "Synchronization Sessions" not only can't occur across different vendor implementations, but are restricted to one particular server instance as well. That limitation might be OK if your primary goal is to provide server to server replication, but it is unacceptable in many other scenarios. For example, I want to provide a distributed set of LDAP replicas that email clients may use to maintain offline copies of the corporate addressbook. -Mark