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

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

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. Novell
is the one that requested it, and it wasn't to solve any performance
issues.

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

This should all be captured in the archives.

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

---

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

At 01:13 PM 2002-10-03, Jim Sermersheim wrote:
>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 <[email-masked]>.

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

>backward compatability problems with implementations that existed before

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