Re: [ldapext] VLV: review notes

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:21 PM 2002-09-25, David Boreham wrote:
>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 ?

Paging of results.  Presently there is no standard track
mechanism to page through results.

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

My point is, there will be other ordering controls defined
eventually.  Whether they are defined because RFC 2891 doesn't
fulfill a particular ordering requirement or because RFC 2891
is flawed or whatever, is not terrible relevant.  VLV should not
care how the ordering is provided, just that ordering is provided.
RFC 2891 should be viewed only as one way to provide ordering.

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

First, I don't think 'repeatable order' is too vague.

Second, the ordering provided by RFC 2891 is equally vague.

For example, consider a set of entries who all have as
the attribute "givenName" the value "joe" which have been
sorted, per RFC 2891, by this attribute.  RFC 2891 does
not detail what order they are to be returned in.

VLV, however, assumes that the order is repeatable.
This is all that is necessary for VLV to work.

>Perhaps you could provide a use case where it would be
>valuable ?

Paging of results.  Determining the number of entries
to be returned without requiring them to be returned.

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

There is no ordering rule for DNs.  But there doesn't need
to be for a DN to be used to select a target entry from
an ordered set.

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

The wording in the document implies the last contextID returned
is to be returned, not the last contextID for a particular
virtual list view should be returned.  Likely some simple
rewording would resolving this issue.

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

I note that worse case under RFC 2891 is the same as no ordering
control.

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