|   | 
Client-Server Interaction | 
 
| 
 | 
 
 
Subject: Client-Server Interaction
Author: SteveHB
 In response to: Response Control
Posted on: 06/07/2007 12:57:43 PM
  
    The sortKeyRequestControl specifies one or more attribute types and    matching rules for the results returned by a search request. The    server SHOULD return all results for the search request in the order    specified by the sort keys. If the reverseOrder field is set to TRUE,    then the entries will be presented in reverse sorted order for the    specified key.
     There are six possible scenarios that may occur as a result of the    sort control being included on the search request:
     1 - If the server does not support this sorting control and the        client specified TRUE for the control's criticality field, then        the server MUST return unavailableCriticalExtension as a return        code in the searchResultDone message and not send back any other        results. This behavior is specified in section 4.1.12 of        [LDAPv3].
     2 - If the server does not support this sorting control and the        client specified FALSE for the control's criticality field, then        the server MUST ignore the sort control and process the search        request as if it were not present. This behavior is specified in        section 4.1.12 of [LDAPv3].
     3 - If the server supports this sorting control but for some reason        cannot sort the search results using the specified sort keys and        the client specified TRUE for the control's criticality field,        then the server SHOULD do the following: return        unavailableCriticalExtension as a return code in the        searchResultDone message; include the sortKeyResponseControl in        the searchResultDone message, and not send back any search result        entries.
     4 - If the server supports this sorting control but for some reason        cannot sort the search results using the specified sort keys and        the client specified FALSE for the control's criticality field,        then the server should return all search results unsorted and        include the sortKeyResponseControl in the searchResultDone        message.
     5 - If the server supports this sorting control and can sort the        search results using the specified sort keys, then it should        include the sortKeyResponseControl in the searchResultDone        message with a sortResult of success.
     6 - If the search request failed for any reason and/or there are no        searchResultEntry messages returned for the search response, then        the server SHOULD omit the sortKeyResponseControl from the        searchResultDone message.
     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. If the server omits the    sortKeyResponseControl from the searchResultDone message, the client    SHOULD assume that the sort control was ignored by the server.
     The sortKeyResponseControl, if included by the server in the    searchResultDone message, should have the sortResult set to either    success if the results were sorted in accordance with the keys    specified in the sortKeyRequestControl or set to the appropriate    error code as to why it could not sort the data (such as    noSuchAttribute or inappropriateMatching). Optionally, the server MAY    set the attributeType to the first attribute type specified in the    SortKeyList that was in error. The client SHOULD ignore the    attributeType field if the sortResult is success.
     The server may not be able to sort the results using the specified    sort keys because it may not recognize one of the attribute types,    the matching rule associated with an attribute type is not    applicable, or none of the attributes in the search response are of    these types.  Servers may also restrict the number of keys allowed in    the control, such as only supporting a single key.
     Servers that chain requests to other LDAP servers should ensure that    the server satisfying the client's request sort the entire result set    prior to sending back the results.
  
 
  
>  
> On 06/07/2007 12:47:50 PM SteveHB wrote: 
  
    This control is included in the searchResultDone message as part of    the controls field of the LDAPMessage, as defined in Section  4.1.12    of [LDAPv3].
     The controlType is set to 1.2.840.113556.1.4.474. The criticality    is FALSE (MAY be absent). The controlValue is an OCTET STRING, whose    value is the BER encoding of a value of the following SEQUENCE:
 
      SortResult ::= SEQUENCE {
         sortResult  ENUMERATED {
             success                   (0), -- results are sorted
             operationsError           (1), -- server internal failure
             timeLimitExceeded         (3), -- timelimit reached before
                                            -- sorting was completed
             strongAuthRequired        (8), -- refused to return sorted
                                            -- results via insecure
                                            -- protocol
             adminLimitExceeded       (11), -- too many matching entries
                                            -- for the server to sort
             noSuchAttribute          (16), -- unrecognized attribute
                                            -- type in sort key
             inappropriateMatching    (18), -- unrecognized or
                                            -- inappropriate matching
                                            -- rule in sort key
             insufficientAccessRights (50), -- refused to return sorted
                                            -- results to this client
             busy                     (51), -- too busy to process
             unwillingToPerform       (53), -- unable to sort
             other                    (80)
             },
       attributeType [0] AttributeDescription OPTIONAL }
 
References:
  | 
  | 
 
  |   
 |