Subject: RE: Fix for VLV draft.

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

>>> "John Liang" <[email-masked]> 1/30/01 12:58:09 PM >>>
>> >>> "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.
> 
>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?

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 30 Jan 2001 15:16:16 -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.

I concur and hope this will be resolved by a revision of the specification.
I also note that it may be appropriate for LDAPbis WG to consider adding a
statement to the TS to discourage further overloading of the criticality
field.  It should at least be covered in draft-greenblatt-ldapext-style-00.txt.

And, BTW, "The criticality is FALSE (MAY be absent)" [VLV, 5.2] should actually be
"The criticality SHALL be FALSE and, hence, absent."  Per RFC2251, DEFAULT
values are not present in the BER encoding of LDAP itself.

Kurt