LDAP Control Extension for Server Side Sorting of Search Results
Extracted elements (23)
An entry missing one or more sort keys is treated as having NULL for that key. NULL is defined to be a larger value than all other valid values, so entries without a key sort after all entries that have the key. With reverseOrder, NULL-keyed entries sort before all others.
The optional attributeType field in SortResult allows the server to identify the first attribute type in the SortKeyList that caused a sort error, helping clients diagnose which key was problematic. Clients SHOULD ignore it when sortResult is success.
The sort controls are designed to allow the server to return a result code for sorting that is independent of the result code for the search operation itself, enabling the client to distinguish search failures from sort failures.
A client is assured that results are sorted if and only if the sortResult in the sortKeyResponseControl is success. If the server omits the sortKeyResponseControl, the client SHOULD assume the sort control was ignored.
Servers that chain requests to other LDAP servers must ensure that the results for the entire result set are merged and sorted prior to sending back any results to the client.
When sortKeyRequestControl is used with the pagedResultsControl (RFC 2696), the server must sort the entire result set, not just each individual page, to avoid returning erroneous results to the client.
Any conformant implementation of this control MUST allow a sort key list with at least one key.
If a client submits a sort request to a server that chains the request and the criticality is TRUE, the server MUST merge sort all results before returning them to the client or MUST return unwillingToPerform.
If a server supports sorting but cannot sort and criticality is FALSE, it should return all search results unsorted and include the sortKeyResponseControl in searchResultDone.
If a sort key is a multi-valued attribute and an entry has multiple values for that attribute, the server SHOULD use the least value according to the ORDERING rule for that attribute.
If an attributeType appears in the SortKeyList multiple times, the server should return an error of unwillingToPerform in the sortResult.
If the orderingRule is omitted from a sort key, the ordering MatchingRule defined for use with that attribute MUST be used.
If the search request failed or no searchResultEntry messages are returned, the server SHOULD omit the sortKeyResponseControl from searchResultDone.
If the server does not support the sorting control and the client specified criticality FALSE, the server MUST ignore the sort control and process the search request as if it were not present.
The server SHOULD return all results for the search request in the order specified by the sort keys. If reverseOrder is TRUE, entries MUST be presented in reverse sorted order for the specified key.
The sortKeyList MUST be present on each searchRequest message for a paged result set and MUST NOT change between searchRequests for the same result set.
When used with the pagedResultsControl, the server SHOULD send back a sortKeyResponseControl on every searchResultDone message for each page, so clients can quickly determine if results are sorted.
The sortKeyRequestControl is an LDAPv3 control with OID 1.2.840.113556.1.4.473, included in the searchRequest controls field. Its criticality MAY be TRUE or FALSE. The controlValue is the BER encoding of a SortKeyList SEQUENCE OF SEQUENCE.
The sortKeyResponseControl is an LDAPv3 control with OID 1.2.840.113556.1.4.474, included in the searchResultDone controls field with criticality FALSE. Its controlValue is the BER encoding of a SortResult SEQUENCE.
Allowing server-side sorting can enable retrieval of a large number of records regardless of administrative limits on maximum records returned. A client could combine sorting with updated search filters to retrieve all records in small result sets, circumventing administrative limits.
The SortResult code strongAuthRequired(8) allows a server to refuse returning sorted results over an insecure protocol, protecting against information exposure when strong authentication is absent.
SortKeyList ::= SEQUENCE OF SEQUENCE { attributeType AttributeDescription, orderingRule [0] MatchingRuleId OPTIONAL, reverseOrder [1] BOOLEAN DEFAULT FALSE }. The sequence is ordered from highest to lowest sort key precedence.
SortResult ::= SEQUENCE { sortResult ENUMERATED { success(0), operationsError(1), timeLimitExceeded(3), strongAuthRequired(8), adminLimitExceeded(11), noSuchAttribute(16), inappropriateMatching(18), insufficientAccessRights(50), busy(51), unwillingToPerform(53), other(80) }, attributeType [0] AttributeDescription OPTIONAL }.