Re: [ldapext] VLV: review notes

["David Boreham" <david_list@boreham.org>]

Comments on your notes:

>I believe this control should also be usable without a sorting
>control.  Just as one can page through unsorted results using
>[SPaged], one should be able to VLV through unsorted results.

This has been discussed several times in the past.
Can you give an example of where it would be useful
to use VLV on a randomly sorted result set ?

>This MUST should be dropped.  It should be acceptable for a VLV
>implementation not to support [SSS], just as a [SPaged] implementation
>need not support [SSS].  It should be possible to use VLV with other
>ordering controls instead of [SSS].

I've not been paying attention. Can you point me at the other
ordering controls please ? (when VLV was written , there were none).

>All that is necessary is is to say that implementations must provide
>unsorted results in some repeatable order.  That is, the order must
>be consistent for subsequent operations.  It should be sufficient
>to outline the ordering requirements and to state those requirements
>are not provided, the VLV control cannot be used.

Again, this has been discussed many times long ago.
The view taken was that 'repeatable order' is too vague a 
concept to be useful in the context of an interoperability standard.
Perhaps you could provide a use case where it would be
valuable ?

>I believe VLV should offer all the capabilities of [SPaged].  In
>fact, it's my opinion that VLV should obsolete [SPaged].

This was the original goal for VLV. However, due to the 
timeline for some vendors implementations, it didn't happen.
Your support is welcome.

>I note that there is no way to specify the target be a particular
>entry.  That is, by DN.  Whether or not select by DN is particularly
>useful is another matter.

Hmm....I remember thinking about this. Are there rules for
magnitude comparison of DN values ? If so then perhaps this
'just works (tm)'. 

>What if the client has two different virtual lists?  Should
>the contextID be associated with a particular virtual list?
>Also, is the client free to change any and all search/VLV
>parameters associated with a virtual list and, hence, a
>contextID?

Some background: the first VLV implementation was Netscape's.
Netscape's implementation was stateless, and had no context ID.
Later, another vendor with a different server architecture 
started to implement VLV. They discovered that their more stateful
design required that the client context cookie be added to the protocol.
The resulting wording in the RFC is designed to allow both designs
to interoperate.

So to answer: yes a contextID is associated with a particular
view onto a particular list (hence the term context rather than list
or client). It seems sensible to allow a client to submit whatever
it likes for the contextID (we're not the protocol police after all),
but if it doesn't play by the rules (submit the value previously 
supplied by the server), then performance and/or results could
be undefined. 

I won't comment on all the result code stuff: it's from after my 
work on the document, and it plain made my head spin !

Similarity to SPaged: discussion at previous WG meetings
persuaded me that SPaged and VLV are sufficiently semanticically
differnent that it was not appropriate to try to make VLV a superset
of SPaged functionality. For example: in SPaged, the server never
needs to 'go backwards' in the result set. Therefore the lack 
of a need to specify sort order is not a practical problem.
However, in VLV, we can go backwards, and the result set
could be spectacularly large. Hence there would be a need
to store sufficient state on the server side to ensure that regardless
of the clients's partying back and forth on the result set, we never
get lost as to what we've returned before and what comes 
next. It is not at all clear to me that this is a) tractable and b) 
advisable. This is one of the reasons why sort order is required
in VLV. 

I note further than some implementations will have a 'natural order'.
e.g. UMich-derived implemenations will typically return results in
entryID order. So it is tempting to say 'heck, no sort control, we 
just return entries in entryID order'. I believe that this thinking is
too much driven by experience with that particular implementation.
Further, if there is such a thing as 'the natural sort order', I'd rather
see that specified with some kind of ordering control, rather than
implied by the absence of any ordering control. To me, no ordering
specified means totally random and not repeatable order, in the worst case.




















_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext