Re: Fix for VLV draft.

[mcs@netscape.com (Mark C Smith)]

I think you meant to say "section 5.2" not "section 3.2".

I think your proposed change is okay.  Another valid approach, and this
is the one that is implemented in iPlanet's products, is to recommend
that the client always examine the virtualListViewResult.  A VLV client
will need to parse the virtualListViewResponse upon success (to get the
VLV offset information) or error (to find out if VLV control caused the
error to be generated).  So it would be sufficient IMHO to just say "a
result code other than success SHOULD be returned in the
SearchResultDone message if the virtualListViewResult is not success."

-Mark Smith
 Netscape


Jim Sermersheim wrote:

>  Back in September, as the Virtual List View draft was going through
> standardization process, Michael Armijo noted the following
> problem: >In section 3.2 we have details about what the
> virtualListViewResult
> >codes mean, but we still do not define what result code should be
> >returned in the actual SearchResult in the case where there is a
> value
> >other then success(0) in the virtualListViewResult.>>We should return
> something other then success(0)in the SearchResultDone
> >if there is a result code other then success(0) in the
> >virtualListViewResult and what that result code is should be defined
> (or
> >referenced) in the VLV draft. I propose that we fix this by inserting
> the following statement as paragraph 4 of Section 3.2If the LDAP
> SearchResultDone message has a resultCode of other (80),
> the virtualListViewResponse MAY be included and MAY hold a non-zero
> value in the virtualListViewResult field.If there are no objections,
> I'd like to add this and allow the draft to progress. Jim