Re: [ldapext] VLV: a particular target entry

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

At 01:13 PM 2002-10-03, Jim Sermersheim wrote:
>The original purpose of the cookie was to provide a way for a server to
>associate a list with a client/connection. The problem was that a client
>could be maintaining two VLV lists on the same connection, using the
>same search criteria. In order for the server to perform certain
>operations (like consistent page up/down) it was neccessary to add the
>cookie so that the client's views could be known to the server.

Then the document should be clarified that the cookie is
used to maintain state between related operations and that
in the absence of a cookie, the server is to assume the
operation is for an unrelated list.

Note, even if the server only supported one list at a time, the
request needs to state whether it is related to previous VLV
operations or is unrelated.

>Novell is the one that requested it, and it wasn't to solve any performance
>issues.

Okay, but this isn't what the I-D says nor what the author has said
on this list in <003b01c265a6$eadb43d0$220aa8c0@mtbrook.boreham.org>.

  Cookies are optional because they're a performance optimization
  required only by a subset of implementations. 

>The reason it was added as an optional component was to not cause
>backward compatability problems with implementations that existed before
>its introduction.

If a server doesn't return a cookie, what is the client to
make of this?  Is it to assume that the server only supports
one VLV list?  Is it to assume that each subsequent requests
will be treated as related?  or treated as unrelated?

>This should all be captured in the archives.

It needs to be captured in the I-D.

Kurt



>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