Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical

[hyc@symas.com]

Kurt@OpenLDAP.org wrote:
> On Apr 20, 2012, at 5:17 AM, coudot@linagora.com wrote:
>
>> Full_Name: Clément OUDOT
>> Version: 2.4.30
>> OS: GNU/Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (88.173.78.196)
>>
>>
>> I noticed that with OpenLDAP 2.4.30, a search request with a non
>> criticical sss control on an attribute without ordering matching rule
>> returns an error:
>>
>> clement@ader:~/Programmes/openldap$ bin/ldapsearch -H
>> ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b
>> ou=people,ou=XXX -E sss=cn
>> # extended LDIF
>> #
>> # LDAPv3
>> # with server side sorting control
>> #
>>
>> # search result
>> search: 2
>> result: 18 Inappropriate matching
>> text: serverSort control: No ordering rule
>>
>> # numResponses: 1
>>
>> I think the error should only be returned if the control is critical. Else, the
>> search results should be returned, not sorted.
>
> Incorrect behavior per the standards. If the control is recognized and
implemented, then it's to be processed regardless of the criticality. There's
not supposed to be any "if it errors, ignore it" processing.

Thanks for the confirmation. The text of RFC2891 seems contradictory here 
though. Specifically, section 2 clause #4 says if critical is False, the 
search results should be returned unsorted, with a sortKeyResponseControl in 
the searchResultDone message, containing the error (e.g. inappropriateMatching).

I remember we had this conversation about control criticality before, but 
don't recall the details. Does the later clarification of Criticality 
supersede the text of RFC2891?

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/