Network Working Group T. Howes Request for Comments: 2891 Loudcloud Category: Standards Track M. Wahl Sun Microsystems A. Anantha Microsoft August 2000 LDAP Control Extension for Server Side Sorting of Search Results
Status of this Memo2013年江苏高考英语
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for
improvements. Plea refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Rerved.
Abstract
This document describes two LDAPv3 control extensions for rver side sorting of arch results. The controls allows a client to specify the attribute types and matching rules a rver should u when
returning the results to an LDAP arch request. The controls may be uful when the LDAP client has limited functionality or for some
other reason cannot sort the results but still needs them sorted.
Other permissible controls on arch operations are not defined in
this extension.
The sort controls allow a rver to return a result code for the
sorting of the results that is independent of the result code
returned for the arch operation.
The key words "MUST", "SHOULD", and "MAY" ud in this document are
to be interpreted as described in [bradner97].
Howes, et al. Standards Track [Page 1]
1. The Controls崇拜英文
1.1 Request Control
This control is included in the archRequest message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of
[LDAPv3].
The controlType is t to "1.2.840.113556.1.4.473". The criticality
MAY be either TRUE or FALSE (where abnt is also equivalent to
FALSE) at the client’s option. The controlValue is an OCTET STRING,
who value is the BER encoding of a value of the following SEQUENCE: SortKeyList ::= SEQUENCE OF SEQUENCE {
attributeType AttributeDescription,
orderingRule [0] MatchingRuleId OPTIONAL,
reverOrder [1] BOOLEAN DEFAULT FALSE }
The SortKeyList quence is in order of highest to lowest sort key
precedence.
The MatchingRuleId, as defined in ction 4.1.9 of [LDAPv3], SHOULD
be one that is valid for the attribute type it applies to. If it is not, the rver will return inappropriateMatching.
Each attributeType should only occur in the SortKeyList once. If an
attributeType is included in the sort key list multiple times, the
rver should return an error in the sortResult of
unwillingToPerform.
If the orderingRule is omitted, the ordering MatchingRule defined for u with this attribute MUST be ud.
Any conformant implementation of this control MUST allow a sort key
list with at least one key.
1.2 Respon Control
This control is included in the archResultDone message as part of
the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3].
The controlType is t to "1.2.840.113556.1.4.474". The criticality
is FALSE (MAY be abnt). The controlValue is an OCTET STRING, who value is the BER encoding of a value of the following SEQUENCE: Howes, et al. Standards Track
[Page 2]
SortResult ::= SEQUENCE {
sortResult ENUMERATED {
success (0), -- results are sorted
operationsError (1), -- rver internal failure
timeLimitExceeded (3), -- timelimit reached before -- sorting was completed
strongAuthRequired (8), -- refud to return sorted -- results via incure
-- protocol
adminLimitExceeded (11), -- too many matching entries -- for the rver to sort
noSuchAttribute (16), -- unrecognized attribute
-- type in sort key
inappropriateMatching (18), -- unrecognized or
-- inappropriate matching
-- rule in sort key
insufficientAccessRights (50), -- refud to return sorted -- results to this client
busy (51), -- too busy to process
unwillingToPerform (53), -- unable to sort
other (80)
},
attributeType [0] AttributeDescription OPTIONAL }gemei
2. Client-Server Interaction
The sortKeyRequestControl specifies one or more attribute types and
matching rules for the results returned by a arch request. The
rver SHOULD return all results for the arch request in the order specified by the sort keys. If the reverOrder field is t to TRUE, then the entries will be prented in rever 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 arch request:
1 - If the rver does not support this sorting control and the
client specified TRUE for the control’s criticality field, then
the rver MUST return unavailableCriticalExtension as a return
code in the archResultDone message and not nd back any other results. This behavior is specified in ction 4.1.12 of
[LDAPv3].
2 - If the rver does not support this sorting control and the
client specified FALSE for the control’s criticality field, then the rver MUST ignore the sort control and process the arch
request as if it were not prent. This behavior is specified in ction 4.1.12 of [LDAPv3].
Howes, et al. Standards Track [Page 3]
3 - If the rver supports this sorting control but for some reason
轻快的英文歌cannot sort the arch results using the specified sort keys and the client specified TRUE for the control’s criticality field,
then the rver SHOULD do the following: return
unavailableCriticalExtension as a return code in the
archResultDone message; include the sortKeyResponControl in
the archResultDone message, and not nd back any arch result entries.
4 - If the rver supports this sorting control but for some reason
cannot sort the arch results using the specified sort keys and the client specified FALSE for the control’s criticality field,
then the rver should return all arch results unsorted and
include the sortKeyResponControl in the archResultDone
message.
5 - If the rver supports this sorting control and can sort the
arch results using the specified sort keys, then it should
include the sortKeyResponControl in the archResultDone
英语影评
message with a sortResult of success.
6 - If the arch request failed for any reason and/or there are no
archResultEntry messages returned for the arch respon, then the rver SHOULD omit the sortKeyResponControl from the讲文明树新风演讲稿
archResultDone 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
sortKeyResponControl is success. If the rver omits the
sortKeyResponControl from the archResultDone message, the client SHOULD assume that the sort control was ignored by the rver.
The sortKeyResponControl, if included by the rver in the
archResultDone message, should have the sortResult t to either
success if the results were sorted in accordance with the keys
specified in the sortKeyRequestControl or t to the appropriate
error code as to why it could not sort the data (such as
noSuchAttribute or inappropriateMatching). Optionally, the rver MAY t 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 rver may not be able to sort the results using the specified
sort keys becau 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 arch respon are of
the types. Servers may also restrict the number of keys allowed in the control, such as only supporting a single key.
Howes, et al. Standards Track [Page 4]
Servers that chain requests to other LDAP rvers should ensure that the rver satisfying the client’s request sort the entire result t prior to nding back the results.
2.1 Behavior in a chained environment
If a rver receives a sort request, the client expects to receive a t of sorted results. If a client submits a sort request to a rver which chains the request and gets entries from multiple rvers, and the client has t the criticality of the sort extension to TRUE, the rver MUST merge sort the results before returning them to the
client or MUST return unwillingToPerform.
2.2 Other sort issues
An entry that meets the arch criteria may be missing one or more of the sort keys. In that ca, t
he entry is considered to have a value of NULL for that key. This standard considers NULL to be a larger
value than all other valid values for that key. For example, if only one key is specified, entries which meet the arch criteria but do
not have that key collate after all the entries which do have that
key. If the reverOrder flag is t, and only one key is specified, entries which meet the arch criteria but do not have that key
adapttocollate BEFORE all the entries which do have that key.
If a sort key is a multi-valued attribute, and an entry happens to法国文化
have multiple values for that attribute and no other controls are
prent that affect the sorting order, then the rver SHOULD u the least value (according to the ORDERING rule for that attribute).
3. Interaction with other arch controls
rabona
When the sortKeyRequestControl control is included with the
pagedResultsControl control as specified in [LdapPaged], then the
rver should nd the archResultEntry messages sorted according to the sort keys applied to the entire result t. The rver should not simply sort each page, as this will give erroneous results to the
client.
The sortKeyList must be prent on each archRequest message for the paged result. It also must not change between archRequests for the same result t. If the rver has sorted the data, then it SHOULD
nd back a sortKeyResponControl control on every archResultDone message for each page. This will allow clients to quickly determine
if the result t is sorted, rather than waiting to receive the
entire result t.
Howes, et al. Standards Track [Page 5]
