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

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 03 Oct 2002 17:28:47 -0600

Kurt, 

If I understand correctly, your view is that the control ought to
guarantee continuity when a cookie is being exchanged. If continuity is
lost, the server returns an error, and the client can re-request with a
null cookie.

Is that accurate? If so, I think this could be done with relatively few
changes to the draft. I'm not sure how many of the current
implementations will adopt the behavior. Given that most of them don't
use the cookie today, I guess they'd still be acting in accordance with
the draft.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 10/03/02 04:51PM >>>
At 03:16 PM 2002-10-03, David Boreham wrote:
>> If every entry in the client's current view has vanished, you would
just
>> attempt a re-position based on their current requested offset. They
>> would end up in a place that may or may not be confusing.
>
>Indeed.

Or return an error.

>> In my mind, for this particular issue, there doesn't need to be any
>> change to the VLV protocol. Only clarifications and further notes
to
>> implementers.
>
>My point was that there is no general solution to the
>dynamic list content problem,

I believe there are at least two general solutions to this
problem.
  1) a cookie (stateful) approach which can be used to position the
  view based upon previous list state and returned results,
  2) a stateless approach which positions the view relative
  to a particular object in the list.

Both solutions, where continuity cannot be provided, can detect
the lack of continuity.

>only various suggestions to make it not so bad,

I disagree.  Both of the above approaches not only handle
minor list changes but deal with some major list changes...
and, where they cannot deal with changes, they can detect
that they cannot and return an error.  This is significantly
better ignoring the problem.

>in the abstract, with no cited
>application where the problem has proven to arise in the
>first place.

(Based upon your description of the Sun/Netscape server)
Take your address book client, select a view against the
Sun/Netscape server, add one entry from the list before
the target, then page down.  The provided view will skip
over one entry. That's a problem, it's real.

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 16:57:01 -0700

At 04:28 PM 2002-10-03, Jim Sermersheim wrote:
>Is that accurate?

Yes.

>If so, I think this could be done with relatively few
>changes to the draft.

Basically, I think the I-D needs to:
 a) state what "continuity" means,
 b) state that intent of the cookie is to provide state to ensure continuity,
 c) state continuity requirements,
 d) state when a VLV operation with no cookie may
    be processed independently of other VLV operations and, hence,
    no continuity is ensured.

Kurt