Subject: Re: [ldapext] VLV: a particular target entry

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 03 Oct 2002 14:56:15 -0600

The client may or may not run into a stability problem, depending on the
server implementation. I believe iPlanet implements VLVs by using a
pre-canned result set (at least that's one implementation). With that
model, it can better ensure consistency without using state
information.

I don't know how they handle changes to the canned result set, or
changes to the users access control.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 10/03/02 02:38PM >>>
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" <[email-masked]> 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" <[email-masked]> 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
>>[email-masked] 
>>https://www1.ietf.org/mailman/listinfo/ldapext 
>
>_______________________________________________
>Ldapext mailing list
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/ldapext 
>_______________________________________________
>Ldapext mailing list
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 03 Oct 2002 14:10:07 -0700

>changes to the users access control.

I don't see how they could possibly pre-can dynamic content.
I see how they might pre-can static content.

If no cookie is not returned, should the client assume the
content is static?

Kurt