RE: Fix for VLV draft.

[andy herron <andyhe@msn.com>]

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