RFC 2891

LDAP Control Extension for Server Side Sorting of Search Results

📅 published August 2000, from ietf

LDAP Control Extension for Server Side Sorting of Search Results 💖 is RFC 2891, and it's giving standards track energy 👑. T. Howes (Loudcloud), M. Wahl (Sun Microsystems), and A. Anantha (Microsoft) wrote it in August 2000 🦋. The header doesn't list anything it obsoletes or updates, so it's just doing its own thing 💅.

Status of this Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2000). All Rights Reserved. 💜

Abstract 🧚

Okay so this doc describes two LDAPv3 control extensions for server side sorting of search results 🌸. The controls let a client say which attribute types and matching rules the server should use when it returns results to an LDAP search request 🔥. They may be super useful when the LDAP client has limited functionality, or when it can't sort the results for some other reason but still needs them sorted 🙈. Other permissible controls on search operations aren't defined in this extension, so don't look for them here 💀.

The sort controls also let a server return a result code for the sorting that's totally separate from the result code for the search operation itself 💅✨.

Also, the key words "MUST", "SHOULD", and "MAY" in this doc get read the way [bradner97] describes 🤓.

1. The Controls 💅

1.1 Request Control 🦋

This control goes in the controls field of the LDAPMessage, inside the searchRequest message, as defined in Section 4.1.12 of [LDAPv3] 📬.

The controlType is "1.2.840.113556.1.4.473" 🍓. The criticality MAY be either TRUE or FALSE (where absent is also equivalent to FALSE), and that's up to the client 🫶. The controlValue is an OCTET STRING, and its value is the BER encoding of the following SEQUENCE 🧠:

      SortKeyList ::= SEQUENCE OF SEQUENCE {
                 attributeType   AttributeDescription,
                 orderingRule    [0] MatchingRuleId OPTIONAL,
                 reverseOrder    [1] BOOLEAN DEFAULT FALSE }

The SortKeyList is ordered from highest to lowest sort key precedence, so the first key is the boss 👑.

The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD be one that's valid for the attribute type it applies to 🤌. If it isn't, the server will return inappropriateMatching 🚫.

Each attributeType should only occur in the SortKeyList once 🙅‍♀️. If an attributeType shows up 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 goes in the controls field of the LDAPMessage, inside the searchResultDone message, as defined in Section 4.1.12 of [LDAPv3] ✨.

The controlType is "1.2.840.113556.1.4.474" 💜. The criticality is FALSE, and it MAY be absent 🙈. The controlValue is an OCTET STRING, and its value is the BER encoding 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. Security Considerations 🔐

Okay bestie, this part is serious, so listen up 👀. Implementors and administrators should be aware that allowing sorting of results could let someone pull a huge number of records out of a directory service, even when there are administrative limits on how many records can be returned. Sorting can quietly break those limits 😳.

A client that wanted to grab every single record could mix sorting with changing its search filters, so it gets everything in tiny result sets and walks right past the administrative limits. Not okay 💀.

The good news is that this can be handled. Administrators can use permissions on directory entries wisely, and implementations can be smart about how they enforce administrative limits on the number of records a client retrieves 🛡️✨.

5. References 📚

Here's the reading list, complete with every detail 🤓🎀

  • [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.

6. Authors' Addresses 🦋

Meet the people who made this happen 💖. Here are their addresses, copied exactly as written:

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

The legal bit has to stay word for word, so here it is in full, no edits 🙏:

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 🫶

Last one, and it's a quick one ✨. The RFC Editor function is currently funded by the Internet Society. Thank you for reading, bestie 🌈💜

📦 where this page comes from