Re: [ldapext] VLV: a particular target entry

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:16 PM 2002-10-03, Jim Sermersheim wrote:
>I suggest we add more information on the intent of the contextID
>(cookie) and state that servers choosing to not use it may run into
>instability problems.

It's the client what will run into stability problems if
its not provided with a cookie and it doesn't provide the
cookie in the next related request.



>Jim
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/03/02 01:05PM >>>
>At 11:49 AM 2002-10-03, Jim Sermersheim wrote:
>>Help me understand the stability problem further. If the cookie
>>mechanism is used, a server knows the last view that the client has.
>If
>>a client asks for a new view (by offset) that overlaps or adjoins the
>>last view, the server should be able to provide contiguous
>results--even
>>when updates are happening.
>
>First, note that the present cookie is optionally provided by
>the server and optionally returned by the server.  It's purpose
>has been described to allow the server to make optimize processing
>of related requests.  It, however, hasn't been described as a
>mechanism which the protocol relies on to address content
>instability.
>
>If servers were REQUIRED to provide a cookie and clients
>were REQUIRED used the cookie in subsequent related requests, then
>the cookie could be used to address the stability problem.
>
>I would refer to this as a "state-full" approach.
>
>However, the authors have stated that VLV could be implemented
>in a "state-less" fashion.  No cookies.
>
>Either VLV is
>        stateful - some state is needed.
>        stateless - no state is needed.
>
>Which is it?
>
>>Jim
>>
>>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/01/02 09:09AM >>>
>>At 07:21 AM 2002-10-01, David Boreham wrote:
>>>> Do you not see that VLV is broken without selection by DN.
>>>> That is, the VLV scroll up/down mechanism fails in the
>>>> general case, e.g. when content is unstable.
>>>
>>>Highly unstable content isn't within the scope of this
>>>protocol.
>>
>>Note that I did not say "highly unstable".  I said "unstable".
>>That is, one entry add/modification/delete is sufficient
>>to cause this protocol to fail.
>>
>>>Directories typically don't have highly unstable content.
>>
>>But directories typically do change.  And any change is
>>sufficient to cause failure in this protocol.
>>
>>>Kurt: do you have a counterexample ? e.g. something
>>>you tried to implement with the current protocol but failed 
>>>to get to work ? Tell us about it.
>>
>>Based upon my operational experience with implementing similar
>>controls, it is obvious to me that the current protocol fails
>>where contain is not stable.  In particular, were DIT
>>modification causes the positioning of entries in the list to
>>shift.
>>
>>Kurt
>>
>>_______________________________________________
>>Ldapext mailing list
>>Ldapext@ietf.org 
>>https://www1.ietf.org/mailman/listinfo/ldapext 
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org 
>https://www1.ietf.org/mailman/listinfo/ldapext
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext