On Apr 20, 2012, at 7:54 AM, Hallvard Breien Furuseth wrote:

...

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

Though the new behavior may be formally compatible with both RFCs, it certainly breaks the expectations of one of them and must do so.

Client developers implementing/using RFC 2891 should only have one key expectation: 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.

Clients which assume results are otherwise sorted are simply broken.

And, more generally, the client developer should not assume servers adhere to all "shoulds" and "SHOULDs" in a spec.

How long has the previous behavior been in in OpenLDAP? Is it feasible to delay the change until RE25? Seems like a typical kind of change to avoid doing in the middle of a release series.

As Howard's comment imply, we implement the behavior I suggest... all he's doing is clarifying in comments the current code behaves consistently with both RFC 2891 and RFC 4510.

-- Kurt