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

[Kurt@OpenLDAP.org]

On Apr 20, 2012, at 6:35 AM, Howard Chu wrote:

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

RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510.  Overloading criticality (or any protocol element) is simply a bad thing.

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

Both 3 and 4, especially when taken together, overload criticality.

3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control!   3 is also problematic as the server might detect the problem only after it has returned some entries.

4 isn't much better.

So the whole specification is a mess.

What I recommend is this,

If the server implements the control:

If the control is present, try to sort.  If able to do so, return sortResult.success.  Otherwise return sortResult with sortResult != success.

This, I think is consistent with RFC 2891.
   The client application is assured that the results are sorted in the
   specified key order if and only if the result code in the
   sortKeyResponseControl is success.

clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes.  I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above.


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