Re: [ldapext] VLV: a particular target entry

["Jim Sermersheim" <jimse@novell.com>]

>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/03/02 02:35PM >>>
>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.

I agree (unless the server implementation is to work against a more
static 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.

yes

>>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. 

It was added a long time ago. We should have added the intent into the
doc (we probably left it out in order to leave its use unlimited).

>>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?

Since some implementations use more static (pre-canned) result sets,
the client can't really assume anything. Even if we required the cookie,
we can't cause all implementations to use it to ensure continuity or
quality. I think it's sufficient to have the mechanism available, state
its intended use, and allow clients to assume that all servers will
return contiguous results, regardless of how they achieve that.

>>This should all be captured in the archives.
>
>It needs to be captured in the I-D.

I agree. This is an easy fix.

Jim

>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