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

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


Reply via email to