Re: LCUP and eventual convergence
[email protected] (Rich Megginson) Thu, 01 May 2003 14:24:32 -0600
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Organization | Netscape - Directory Server |
| Message-ID | <[email protected]> |
This is the relevant text from lcup 05: > If at any time during an LCUP search, either during the sync phase or > the persist phase, the server determines that it cannot guarantee that > it can bring the client's copy of the data to eventual convergence, it > SHOULD immediately terminate the LCUP search request and return a > SearchResultDone message with a resultCode of lcupReloadRequired. > This can also happen at the beginning of an incremental > synchronization request, if the client presents a cookie that is out > of date or otherwise unable to be processed. The client should then > issue an initial synchronization request. Note that this implies that the server DOES generate the set of events necessary for eventual client convergence, either though LCUP update responses or by notifying the client that a reload is required. Kurt D. Zeilenga wrote: >In http://www.imc.org/ietf-ldup/mail-archive/msg01612.html, >the chairs declared WG consensus: > > The server needs to be required to generate the set of > events necessary for eventual convergence of the client's > copy of the DIT fragment. > >I haven't been able to find where draft-ietf-ldup-lcup >mandates that servers generate the set of events necessary >for eventual convergence (or, if not possible, return an error). >I would have expected to find such a statement in the >introductory portions of the document as well as in 4.3.7. > If the current LCUP wording is not sufficient to convey this mandate, then may I ask for a suggestion of how to reword it? > >Kurt > > >
smime.p7s
(application/x-pkcs7-signature, 3.5 KB) - not displayed