One of our customers requested an extension to sort the values in
multi-valued attributes, which we have now implemented in OpenLDAP
2.3. Kurt suggested that we should also provide a (critical) control
so that new clients can explicitly request this behavior (or disable
it). I'm thinking we should publish the resulting work as an
Informational or Experimental RFC.
The extension on the server can be configured to use one of 5 sort
methods on a particular attributes in particular subtrees of the DIT.
The first 4 methods are pretty straightforward - alpha ascending,
alpha descending, and numeric ascending/descending. The 5th method is
called "weighted" and while the previous 4 methods can be used without
any special preparation, weighted sorting requires weights to be
prefixed to the attribute values of interest. The weights are denoted
by '{xx}' where 'xx' is an integer and are always sorted in ascending
order. Also, the weights are not returned with the values in normal
search results.
So, given an attribute
foo: {10}Animal
foo: {3}Vegetable
foo: {1}Mineral
a search response with weighted sorting would return
foo: Mineral
foo: Vegetable
foo: Animal
Currently the control is defined with a single boolean flag, which if
set TRUE, disables sorting and causes attributes to be returned as-is.
If it weren't for this weighted sorting method, I would have preferred
to have no server-side configuration, and just let the client choose
its sorting parameters completely in the control. That strikes me as
the most general solution. But this method was specified because they
wanted to get the sorting behavior without needing to update existing
clients, and there's no way you could support weights without
server-side state information. (And yes, even though there are no
guarantees about the order of values returned in multi-valued
attributes, they wrote their clients assuming there was a guaranteed
order. sigh...)