On Apr 20, 2012, at 7:56 AM, [email protected] wrote: > Le 20 avril 2012 16:22, <[email protected]> a écrit : >> [email protected] wrote: >>> On Apr 20, 2012, at 6:35 AM, Howard Chu wrote: >>> >>>> [email protected] 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.
