Re: [ldapext] VLV: absolute position of the list (negative offsets revisited)

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

> >Note that it is a non-goal of VLV to implement
> >the feature set of the simple paged results control,
> >or to implement paging.
> 
> I obviously don't share your view as to the goal of
> this work.

It's not a question of sharing opinions or not, it's a simple fact
that at an IETF meeting, I think in 1999, this was discussed
and rejected as a goal. Personally I was arguing on the
same side you now take. But the decision went the other way.
There were folks at that meeting with some implementation
experience with SPaged, who cited many reasons why
VLV couldn't trivially be extended to support an SPaged
superset. At the time I found their arguments persuasive
and gave up arguing the position which you are not advancing.

> This WG was chartered to produce a standard track
> specification "to allow a client to retrieve search
> results one page at a time".  VLV was suggested as an
> alternative approach to meet the WG meet this WG goal
> and the WG has taken this approach to meet its goal.
> However, the WG goal is unchanged.  It is still to
> provide a standard mechanism "to allow a client to
> retrieve search results one page at a time".

Fine with me. But this isn't VLV.

> The simple paged results control was published as
> Informational, not Standard Track, under the assumption
> that VLV would obsolete it.

Hmm...who assumed this ? I guess I wasn't at that meeting
and didn't see the list discussion on this subject.

> >It's designed to implement scrolling list views.
> 
> It also designed to support absolute positioning.  That
> feature however is flawed in that it only allows positioning
> from the head of the list.  This flaw is easily rectified.

While reataining backwards compatibility with existing
implementations ? If so then go ahead and suggest new
text to allow this. You still haven't supplied an example
where this would be useful, so I'm not sure how 
you'd fare in getting agreement to change the document
at this stage, even if you retain compatibility with 
existing implemetations.






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