Briefly, the issue revolves around the desire to present
a surprise free user experience, specifically that paging
up in a search results UI window should not skip any
entries. That is, each page displayed should be contiguous
with its neighbors. Now, if a server is capable of understanding
that a client has asked for the next, or previous page within
a result set which they've been displaying, it my fetch
the "correct" set of results for that client. In, on the other
hand, the server doesn't know one VLV request from
another, originating from the same client, it is possible
to get into situations where the server will send back
discontiguous pages. The result is an unpleasant user
experience, since entries can seem to have vanished from
the list.
Now, this problem only shows up with servers which
use approximate index positioning. Servers which feature
precise index positioning (e.g. the Netscape implementation)
don't see the problem because the precise same set of
results is returned to any client when presenting the identical
VLV search request.
It has been proposed that the addition of a context
field to both the VLV request control and the VLV
response control would enable the protocol to work
well with both kinds of server implementation.
A server which wants to use the context information
can supply it in responses sent to clients. Clients
are required to return the context information to
the server within subsequent requests. The contents
of the context field are opaque to the client.
I think that this context field will also have the side
effect of making VLV a strict superset of paged
results. It had been pointed out some time ago that
while the current VLV control allows most of the
client/server interaction which people actually do with
the paged results control, it isn't a strict superset.
I'm making the assertion that the addition of a
context field (AKA "cookie") to the VLV control
will fix this. Paged results aficionados please think
about this and confirm or deny, please.
So, the purpose of this posting is to raise the
issue within the LDAP extensions community,
and to give warning to VLV implementors that
the protocol could change.
It's hoped that the changed can be made such
that upwards-compatibility with deployed
implementations can be achieved.