On Apr 20, 2012, at 7:56 AM, clem.oudot@gmail.com wrote:

Le 20 avril 2012 16:22, hyc@symas.com a écrit :

...

Kurt@OpenLDAP.org wrote:

...

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

...

Kurt@OpenLDAP.org wrote:

...

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.

OK. I'm going to add some comments to this effect in sssvlv.c but otherwise close this ITS, works as designed.

I would like just mention that this choice may be relevant from an RFC/standardization point of view, but will lead to incompatibility of OpenLDAP with some softwares like Cognos or Outlook, which use the sss control on standards attributes like cn or sn.

maybe you should file a bug report with them.

May it be possible to add an option in the sssvlv overlay to ignore such errors?

I prefer not to condone non-standard behaviors by adding workarounds for them.