Subject: RE: Fix for VLV draft.

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 30 Jan 2001 11:34:20 -0700

>>> "John Liang" <[email-masked]> 1/29/01 10:35:29 AM >>>
>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.

No, during processing, if there is an error (due to the control being processed or otherwise), processing stops, and the searchResultDone is returned with (some) error code.

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

If the server returns all unsorted entries successfully, it is because the server does not support the vlv and sss controls, and they are not marked critical. Thus they are ignored and the search is processed as if it never had the controls. There is no sss or vlv response code in this case because the server doesn't recognise them.

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

Yes.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 30 Jan 2001 11:45:16 -0700

From my read of draft-armijo-ldap-control-error-00.txt, the proposal is to ammend RFC 2251 in a way that cannot be done. I may be misreading it. 

Maybe it intends to say that this result code MUST only be used when the operation is accompanied by a control that specifies its use. If this is the case, I think it should be re-worded, and progressed so that other I-Ds needing to consume it can be progressed.

Otherwise, I don't mind introducing a new error code in the VLV draft itself that is only used in the presence of the VLV control. 

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 1/29/01 10:49:32 AM >>>
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

At 10:16 AM 1/29/01 -0700, 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.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: Tue, 30 Jan 2001 14:58:09 -0500

> -----Original Message-----
> From: Jim Sermersheim [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2001 1:34 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Fix for VLV draft.
> 
> 
> No, during processing, if there is an error (due to the control 
> being processed or otherwise), processing stops, and the 
> searchResultDone is returned with (some) error code.
> 
> If the server returns all unsorted entries successfully, it is 
> because the server does not support the vlv and sss controls, and 
> they are not marked critical. Thus they are ignored and the 
> search is processed as if it never had the controls. There is no 
> sss or vlv response code in this case because the server doesn't 
> recognise them.
 
Jim,

It sounds different from RFC2891(LDAP Control Extension for Server
Side Sorting of Search Results), chapter 2, item 4:

4 - If the server supports this sorting control but for some reason
       cannot sort the search results using the specified sort keys and
       the client specified FALSE for the control's criticality field,
       then the server should return all search results unsorted and
       include the sortKeyResponseControl in the searchResultDone
       message.

It shows that if the server supportes this control, the unsorted result
could be sent back under certain conditions.

Any comments?

Thanks,
--
John Liang

---

From: "Michael Armijo" <[email-masked]>
Date: Tue, 30 Jan 2001 15:13:05 -0800

Jim Sermersheim said - "Maybe it intends to say that this result code
MUST only be used when the operation is accompanied by a control that
specifies its use"

I believe that may be the best way to go.  I will review the current
version and update the list with an updated draft.

Michael

> Sent: Tuesday, January 30, 2001 10:45 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Fix for VLV draft.
> 
> 
> From my read of draft-armijo-ldap-control-error-00.txt, the 
> proposal is to ammend RFC 2251 in a way that cannot be done. 
> I may be misreading it. 
> 
> Maybe it intends to say that this result code MUST only be 
> used when the operation is accompanied by a control that 
> specifies its use. If this is the case, I think it should be 
> re-worded, and progressed so that other I-Ds needing to 
> consume it can be progressed.
> 
> Otherwise, I don't mind introducing a new error code in the 
> VLV draft itself that is only used in the presence of the VLV 
> control. 
> 
> Jim
> 
> >Back in September, as the Virtual List View draft was going 
> through standardization process, Michael Armijo noted the 
> following problem:
> >

---

From: andy herron <[email-masked]>
Date: Tue, 30 Jan 2001 21:05:55 -0800

>Yes, I don't think we should have done that. I think we should have stated 
that an error
>is returned, and the client can re-try with a modified control.
>

Jim & John,

The original thinking in the sorting draft was that the client could ask 
for it to be sorted but not require it.  The criticality field seemed at 
the time perfectly suited for this use.  It could be that the client is 
capable of doing the sort but also "is hopeful" that the server already has 
the data indexed by the sort key so can simply run down the index when 
calculating/formatting the result set.

There are some implementations where sorting is performed/allowed only on 
fields where there exists an index (meaning that the server is 
unwilling/unable to sort the result set itself).  In these implementations, 
failing the entire search when the client was willing to have the result 
set unsorted seemed very reasonable.

What do you gain by having the client resend the search query with a 
modified sort control?  If the client wants this behavior, then the client 
should specify criticality as true.

That was the logic when we wrote the draft oh so long ago.

-Andy Herron
formerly Microsoft Corp, currently residing at University of Washington

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 31 Jan 2001 17:16:24 -0700

>calculating/formatting the result set.

I think, these days if someone were to define a control, and they wanted this functionality, they'd be persuaded to add an option to the control data that provided it.