mirror of
https://git.openldap.org/openldap/openldap.git
synced 2025-03-31 14:50:34 +08:00
Server Side Sorting now RFC2891
This commit is contained in:
Kurt Zeilenga
parent
c7abc6310d
commit
43613d460b
@ -1,302 +0,0 @@
|
||||
Network Working Group T. Howes, Netscape
|
||||
INTERNET DRAFT M. Wahl, Critical Angle Inc
|
||||
Intended Category: Standards Track A. Anantha, Microsoft
|
||||
Expires: December 5, 2000 June 5, 2000
|
||||
|
||||
|
||||
LDAP Control Extension for Server Side Sorting of Search Results
|
||||
draft-ietf-ldapext-sorting-03.txt
|
||||
|
||||
|
||||
1. Status of this Memo
|
||||
|
||||
This document is an Internet-Draft and is in full conformance with all
|
||||
provisions of Section 10 of RFC2026. Internet-Drafts are working
|
||||
documents of the Internet Engineering Task Force (IETF), its areas, and
|
||||
its working groups. Note that other groups may also distribute working
|
||||
documents as Internet-Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference material
|
||||
or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This draft document will be submitted to the RFC Editor as a Standards
|
||||
Track document. Distribution of this memo is unlimited. Technical
|
||||
discussion of this document will take place on the IETF LDAP Extension
|
||||
Working Group mailing list <ietf-ldapext@netscape.com>. Please send
|
||||
editorial comments directly to the authors.
|
||||
|
||||
2. Abstract
|
||||
|
||||
This document describes two LDAPv3 control extensions for server side
|
||||
sorting of search results. These controls allows a client to specify the
|
||||
attribute types and matching rules a server should use when returning
|
||||
the results to an LDAP search request. The controls may be useful 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 search operations are not defined in this extension.
|
||||
|
||||
The sort controls allow a server to return a result code for the sorting
|
||||
of the results that is independent of the result code returned for the
|
||||
search operation.
|
||||
|
||||
The key words "MUST", "SHOULD", and "MAY" used in this document are to
|
||||
be interpreted as described in [bradner97].
|
||||
|
||||
3. The Controls
|
||||
|
||||
3.1 Request Control
|
||||
|
||||
This control is included in the searchRequest 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.473". The criticality
|
||||
MAY be either TRUE or FALSE (where absent is also equivalent to
|
||||
FALSE) at the client's option. The controlValue is an OCTET STRING,
|
||||
whose value is the BER encoding of a value of the following SEQUENCE:
|
||||
|
||||
SortKeyList ::= SEQUENCE OF SEQUENCE {
|
||||
attributeType AttributeDescription,
|
||||
orderingRule [0] MatchingRuleId OPTIONAL,
|
||||
reverseOrder [1] BOOLEAN DEFAULT FALSE }
|
||||
|
||||
The SortKeyList sequence is in order of highest to lowest sort key
|
||||
precedence.
|
||||
|
||||
The MatchingRuleID SHOULD be one that is valid for the attribute type it
|
||||
applies to. If it is not, the server 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
|
||||
server should return an error in the sortResult of unwillingToPerform.
|
||||
|
||||
If the orderingRule is omitted, the ordering MatchingRule defined for
|
||||
use with this attribute MUST be used.
|
||||
|
||||
Any conformant implementation of this control MUST allow a sort key list
|
||||
with at least one key.
|
||||
|
||||
3.2 Response Control
|
||||
|
||||
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 }
|
||||
|
||||
|
||||
4. Client-Server Interaction
|
||||
|
||||
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.
|
||||
|
||||
4.1 Behavior in a chained environment
|
||||
|
||||
If a server receives a sort request, the client expects to receive a
|
||||
set of sorted results. If a client submits a sort request to a server
|
||||
which chains the request and gets entries from multiple servers, and
|
||||
the client has set the criticality of the sort extension to TRUE, the
|
||||
server MUST merge sort the results before returning them to the client
|
||||
or MUST return unwillingToPerform.
|
||||
|
||||
4.2 Other sort issues
|
||||
|
||||
An entry that meets the search criteria may be missing one or more of
|
||||
the sort keys. In that case, the 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 search criteria but do not have
|
||||
that key collate after all the entries which do have that key. If the
|
||||
reverseOrder flag is set, and only one key is specified, entries which
|
||||
meet the search criteria but do not have that key collate 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 present
|
||||
that affect the sorting order, then the server SHOULD use the least
|
||||
value (according to the ORDERING rule for that attribute).
|
||||
|
||||
5. Interaction with other search controls
|
||||
|
||||
When the sortKeyRequestControl control is included with the
|
||||
pagedResultsControl control as specified in [LdapPaged], then the
|
||||
server should send the searchResultEntry messages sorted according to
|
||||
the sort keys applied to the entire result set. The server should not
|
||||
simply sort each page, as this will give erroneous results to the
|
||||
|
||||
client.
|
||||
|
||||
The sortKeyList must be present on each searchRequest message for the
|
||||
paged result. It also must not change between searchRequests for the
|
||||
same result set. If the server has sorted the data, then it SHOULD
|
||||
send back a sortKeyResponseControl control on every searchResultDone
|
||||
message for each page. This will allow clients to quickly determine
|
||||
if the result set is sorted, rather than waiting to receive the entire
|
||||
result set.
|
||||
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
Implementors and administrators should be aware that allowing sorting of
|
||||
results could enable the retrieval of a large number of records from
|
||||
a given directory service, regardless of administrative limits set on
|
||||
the maximum number of records to return.
|
||||
|
||||
A client that desired to pull all records out of a directory service
|
||||
could use a combination of sorting and updating of search filters to
|
||||
retrieve all records in a database in small result sets, thus
|
||||
circumventing administrative limits.
|
||||
|
||||
This behavior can be overcome by the judicious use of permissions on
|
||||
the directory entries by the administrator and by intelligent
|
||||
implementations of administrative limits on the number of records
|
||||
retrieved by a client.
|
||||
|
||||
|
||||
7. References
|
||||
|
||||
[LDAPv3]
|
||||
Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access
|
||||
Protocol (v3)", RFC 2251, December, 1997.
|
||||
|
||||
[Bradner97]
|
||||
Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement
|
||||
Levels", RFC 2119, March, 1997.
|
||||
|
||||
[LdapPaged]
|
||||
C. Weider, A. Herron, A. Anantha and T. Howes, "LDAP Control
|
||||
Extension for Simple Paged Results Manipulation", RFC 2696,
|
||||
September 1999.
|
||||
|
||||
|
||||
8. Author's Address
|
||||
|
||||
Anoop Anantha
|
||||
Microsoft Corp.
|
||||
1 Microsoft Way
|
||||
Redmond, WA 98052
|
||||
USA
|
||||
anoopa@microsoft.com
|
||||
+1 425 882-8080
|
||||
|
||||
Tim Howes
|
||||
Loudcloud, Inc.
|
||||
615 Tasman Dr.
|
||||
Sunnyvale, CA 94089
|
||||
USA
|
||||
howes@loudcloud.com
|
||||
|
||||
Mark Wahl
|
||||
Sun Microsystems, Inc.
|
||||
8911 Capital of Texas Hwy Suite 4140
|
||||
Austin, TX 78759
|
||||
USA
|
||||
M.Wahl@innosoft.com
|
||||
|
||||
@ -47,6 +47,7 @@ rfc2829.txt LDAPv3: Authentication Methods (PS)
|
||||
rfc2830.txt LDAPv3: StartTLS (PS)
|
||||
rfc2831.txt SASL/DIGEST-MD5 (PS)
|
||||
rfc2849.txt LDIFv1 (PS)
|
||||
rfc2891.txt LDAPv3: Server Side Sorting of Search Results (PS)
|
||||
|
||||
Legend:
|
||||
STD Standard
|
||||
|
||||
451
doc/rfc/rfc2891.txt
Normal file
451
doc/rfc/rfc2891.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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 Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please 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 Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes two LDAPv3 control extensions for server side
|
||||
sorting of search results. These controls allows a client to specify
|
||||
the attribute types and matching rules a server should use when
|
||||
returning the results to an LDAP search request. The controls may be
|
||||
useful 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 search operations are not defined in
|
||||
this extension.
|
||||
|
||||
The sort controls allow a server to return a result code for the
|
||||
sorting of the results that is independent of the result code
|
||||
returned for the search operation.
|
||||
|
||||
The key words "MUST", "SHOULD", and "MAY" used in this document are
|
||||
to be interpreted as described in [bradner97].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes, et al. Standards Track [Page 1]
|
||||
|
||||
RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
|
||||
|
||||
|
||||
1. The Controls
|
||||
|
||||
1.1 Request Control
|
||||
|
||||
This control is included in the searchRequest 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.473". The criticality
|
||||
MAY be either TRUE or FALSE (where absent is also equivalent to
|
||||
FALSE) at the client's option. The controlValue is an OCTET STRING,
|
||||
whose value is the BER encoding of a value of the following SEQUENCE:
|
||||
|
||||
SortKeyList ::= SEQUENCE OF SEQUENCE {
|
||||
attributeType AttributeDescription,
|
||||
orderingRule [0] MatchingRuleId OPTIONAL,
|
||||
reverseOrder [1] BOOLEAN DEFAULT FALSE }
|
||||
|
||||
The SortKeyList sequence is in order of highest to lowest sort key
|
||||
precedence.
|
||||
|
||||
The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD
|
||||
be one that is valid for the attribute type it applies to. If it is
|
||||
not, the server 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
|
||||
server should return an error in the sortResult of
|
||||
unwillingToPerform.
|
||||
|
||||
If the orderingRule is omitted, the ordering MatchingRule defined for
|
||||
use with this attribute MUST be used.
|
||||
|
||||
Any conformant implementation of this control MUST allow a sort key
|
||||
list with at least one key.
|
||||
|
||||
1.2 Response Control
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes, et al. Standards Track [Page 2]
|
||||
|
||||
RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
|
||||
|
||||
|
||||
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 }
|
||||
|
||||
2. Client-Server Interaction
|
||||
|
||||
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].
|
||||
|
||||
|
||||
|
||||
Howes, et al. Standards Track [Page 3]
|
||||
|
||||
RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
Howes, et al. Standards Track [Page 4]
|
||||
|
||||
RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
|
||||
|
||||
|
||||
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.
|
||||
|
||||
2.1 Behavior in a chained environment
|
||||
|
||||
If a server receives a sort request, the client expects to receive a
|
||||
set of sorted results. If a client submits a sort request to a server
|
||||
which chains the request and gets entries from multiple servers, and
|
||||
the client has set the criticality of the sort extension to TRUE, the
|
||||
server 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 search criteria may be missing one or more of
|
||||
the sort keys. In that case, the 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 search criteria but do
|
||||
not have that key collate after all the entries which do have that
|
||||
key. If the reverseOrder flag is set, and only one key is specified,
|
||||
entries which meet the search criteria but do not have that key
|
||||
collate 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
|
||||
present that affect the sorting order, then the server SHOULD use the
|
||||
least value (according to the ORDERING rule for that attribute).
|
||||
|
||||
3. Interaction with other search controls
|
||||
|
||||
When the sortKeyRequestControl control is included with the
|
||||
pagedResultsControl control as specified in [LdapPaged], then the
|
||||
server should send the searchResultEntry messages sorted according to
|
||||
the sort keys applied to the entire result set. The server should not
|
||||
simply sort each page, as this will give erroneous results to the
|
||||
client.
|
||||
|
||||
The sortKeyList must be present on each searchRequest message for the
|
||||
paged result. It also must not change between searchRequests for the
|
||||
same result set. If the server has sorted the data, then it SHOULD
|
||||
send back a sortKeyResponseControl control on every searchResultDone
|
||||
message for each page. This will allow clients to quickly determine
|
||||
if the result set is sorted, rather than waiting to receive the
|
||||
entire result set.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes, et al. Standards Track [Page 5]
|
||||
|
||||
RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
|
||||
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
Implementors and administrators should be aware that allowing sorting
|
||||
of results could enable the retrieval of a large number of records
|
||||
from a given directory service, regardless of administrative limits
|
||||
set on the maximum number of records to return.
|
||||
|
||||
A client that desired to pull all records out of a directory service
|
||||
could use a combination of sorting and updating of search filters to
|
||||
retrieve all records in a database in small result sets, thus
|
||||
circumventing administrative limits.
|
||||
|
||||
This behavior can be overcome by the judicious use of permissions on
|
||||
the directory entries by the administrator and by intelligent
|
||||
implementations of administrative limits on the number of records
|
||||
retrieved by a client.
|
||||
|
||||
5. References
|
||||
|
||||
[LDAPv3] Wahl, M, Kille, S. and T. Howes, "Lightweight Directory
|
||||
Access Protocol (v3)", RFC 2251, December 1997.
|
||||
|
||||
[Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[LdapPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP
|
||||
Control Extension for Simple Paged Results Manipulation",
|
||||
RFC 2696, September 1999.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes, et al. Standards Track [Page 6]
|
||||
|
||||
RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
|
||||
|
||||
|
||||
6. Authors' Addresses
|
||||
|
||||
Anoop Anantha
|
||||
Microsoft Corp.
|
||||
1 Microsoft Way
|
||||
Redmond, WA 98052
|
||||
USA
|
||||
|
||||
Phone: +1 425 882-8080
|
||||
EMail: anoopa@microsoft.com
|
||||
|
||||
|
||||
Tim Howes
|
||||
Loudcloud, Inc.
|
||||
615 Tasman Dr.
|
||||
Sunnyvale, CA 94089
|
||||
USA
|
||||
|
||||
EMail: howes@loudcloud.com
|
||||
|
||||
|
||||
Mark Wahl
|
||||
Sun Microsystems, Inc.
|
||||
8911 Capital of Texas Hwy Suite 4140
|
||||
Austin, TX 78759
|
||||
USA
|
||||
|
||||
EMail: Mark.Wahl@sun.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes, et al. Standards Track [Page 7]
|
||||
|
||||
RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
|
||||
|
||||
|
||||
7. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes, et al. Standards Track [Page 8]
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user