Subject: Fix for VLV draft.

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 29 Jan 2001 10:16:32 -0700

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

If 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

---

From: "John Liang" <[email-masked]>
Date: Mon, 29 Jan 2001 12:35:29 -0500

I want to ask a few questions about this topic:

1> if the control is not critical, and there is an error in server side
sorting control
or virutal list view control, the server is supposed to send back all
unsorted result.

if the server returns all unsorted entries successfully,
is LDAP searchResultDone message supposed to return LDAP_SUCCESS or
other(80)?
Must we include sssResponse and vlvResponse with corresponding error code?

2> if the control is critical, besides return
LDAP_UNAVAILABLE_CRITICAL_EXTENSION,
Must we return the corrseponding sssResponse and vlvResponse result code?

Thanks,
--
John Liang
  -----Original Message-----
  From: Jim Sermersheim [mailto:[email-masked]]
  Sent: Monday, January 29, 2001 12:17 PM
  To: [email-masked]
  Subject: Fix for VLV draft.

  Back in September, as the Virtual List View draft was going through

  >referenced) in the VLV draft.

  I propose that we fix this by inserting the following statement as
paragraph 4 of Section 3.2

  If there are no objections, I'd like to add this and allow the draft to
progress.

  Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Jan 2001 09:49:32 -0800

I think it's a bad idea to overload the semantics of the 'other'
(or any other existing) result code.  'other' should only imply
some implementation specific error.   IIRC, Michael previously
suggested introduction a new result code indicating that an error
occurred during control processing.  I believe we should pursue
this approach.

Kurt

---

From: [email-masked] (Mark C Smith)
Date: Mon, 29 Jan 2001 13:03:56 -0500

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:

> standardization process, Michael Armijo noted the following
> problem: >In section 3.2 we have details about what the
> virtualListViewResult
> >other then success(0) in the virtualListViewResult.>>We should return
> something other then success(0)in the SearchResultDone
> >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),
> value in the virtualListViewResult field.If there are no objections,
> I'd like to add this and allow the draft to progress. Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Jan 2001 10:05:42 -0800

I think we have a general problem with this and other controls
in behavior of critical vs. non-critical controls.

Processing of a recognized and appropriate control should not
depend on the control's criticality.  If the control is recognized
and supported but contains some error, I suggest the operation
return an error.

We had a good discussion regarding this general issue in regards to
the DUPENT I-D which folks might want to review.

At 12:35 PM 1/29/01 -0500, John Liang wrote:
>1> if the control is not critical, and there is an error in server side sorting control 
>or virutal list view control, the server is supposed to send back all unsorted result.

>is LDAP searchResultDone message supposed to return LDAP_SUCCESS or other(80)?
>2> if the control is critical, besides return LDAP_UNAVAILABLE_CRITICAL_EXTENSION,

---

From: "John Liang" <[email-masked]>
Date: Mon, 29 Jan 2001 13:30:51 -0500

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Monday, January 29, 2001 1:06 PM
> To: [email-masked]
> Cc: Jim Sermersheim; [email-masked]
> Subject: RE: Fix for VLV draft.
> 
> 

So you mean the unsorted entries will be returned but there will
be an error code in the LDAP searchResultDone message. Then in this
case, do we need to send sssResponse and vlvResponse with the same
error code? Sounds like a duplicate error code.
 
> the DUPENT I-D which folks might want to review.
Where could i find more details about the discussion?

Thanks,
--
John Liang

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Jan 2001 11:14:46 -0800

At 01:30 PM 1/29/01 -0500, John Liang wrote:

>be an error code in the LDAP searchResultDone message.

I'm saying that a control TS which overloads the control
criticality field is flawed and this flaw should be fixed.
I have not yet made any suggestion on how it should be fixed.

>Where could i find more details about the discussion?

In the archives: http://www.openldap.org/lists/ietf-ldapext/
Try searching for "dupent;criticality".