idnits 2.17.1 draft-ietf-ldapext-sorting-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 313 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...fts are worki...' == Line 14 has weird spacing: '...ments of the ...' == Line 15 has weird spacing: '...t other group...' == Line 19 has weird spacing: '...and may be ...' == Line 23 has weird spacing: '...atus of any ...' == (14 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 1998) is 9544 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 113 -- Looks like a reference, but probably isn't: '1' on line 63 == Unused Reference: 'Bradner97' is defined on line 257, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (ref. 'LDAPv3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) == Outdated reference: A later version (-03) exists of draft-ietf-asid-ldapv3-simplepaged-00 ** Downref: Normative reference to an Informational draft: draft-ietf-asid-ldapv3-simplepaged (ref. 'LdapPaged') Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Herron, Microsoft 2 INTERNET DRAFT T. Howes, Netscape 3 Expire in six months M. Wahl, Critical Angle Inc 4 C.Weider, Microsoft 5 A. Anantha, Microsoft 6 March 10, 1998 8 LDAP Control Extension for Server Side Sorting of Search Results 9 draft-ietf-ldapext-sorting-00.txt 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its areas, and its 15 working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference material 21 or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 26 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 28 This document expires on September 10, 1998. 30 2. Abstract 32 This document describes two LDAPv3 control extensions for server side 33 sorting of search results. These controls allows a client to specify the 34 attribute types and matching rules a server should use when returning 35 the results to an LDAP search request. The controls may be useful when 36 the LDAP client has limited functionality or for some other reason 37 cannot sort the results but still needs them sorted. Other permissible 38 controls on search operations are not defined in this extension. 40 The sort controls allow a server to return a result code for the sorting 41 of the results that is independent of the result code returned for the 42 search operation. 44 The key words "MUST", "SHOULD", and "MAY" used in this document are to 45 be interpreted as described in [bradner97]. 47 3. The Controls 49 3.1 Request Control 51 This control is included in the searchRequest message as part of the 52 controls field of the LDAPMessage, as defined in Section 4.1.12 of 53 [LDAPv3]. 55 The controlType is set to "1.2.840.113556.1.4.473". The criticality 56 MAY be either TRUE or FALSE (where absent is also equivalent to 57 FALSE) at the client's option. The controlValue is an OCTET STRING, 58 whose value is the BER encoding of a value of the following SEQUENCE: 60 SortKeyList ::= SEQUENCE OF SEQUENCE { 61 attributeType AttributeDescription, 62 orderingRule [0] MatchingRuleId OPTIONAL, 63 reverseOrder [1] BOOLEAN DEFAULT FALSE } 65 The SortKeyList sequence is in order of highest to lowest sort key 66 precedence. 68 The MatchingRuleID SHOULD be one that is valid for the attribute type 69 it applies to. If it is not, the server MUST return unwillingToPerform. 71 Each attributeType should only occur in the SortKeyList once. If an 72 attributeType is included in the sort key list multiple times, the 73 server should return an error in the sortResult of unwillingToPerform. 75 If the orderingRule is omitted, the ordering MatchingRule defined for use 76 with this attribute MUST be used. 78 Any conformant implementation of this control MUST allow a sort key 79 list with at least one key. 81 3.2 Response Control 83 This control is included in the searchResultDone message as part of the 84 controls field of the LDAPMessage, as defined in Section 4.1.12 of 85 [LDAPv3]. 87 The controlType is set to "1.2.840.113556.1.4.474". The criticality is 88 FALSE (MAY be absent). The controlValue is an OCTET STRING, whose 89 value is the BER encoding of a value of the following SEQUENCE: 91 SortResult ::= SEQUENCE { 92 sortResult ENUMERATED { 93 success (0), -- results are sorted 94 operationsError (1), -- server internal failure 95 timeLimitExceeded (3), -- timelimit reached before 96 -- sorting was completed 97 strongAuthRequired (8), -- refused to return sorted 98 -- results via insecure 99 -- protocol 100 adminLimitExceeded (11), -- too many matching entries 101 -- for the server to sort 102 noSuchAttribute (16), -- unrecognized attribute 103 -- type in sort key 104 inappropriateMatching (18), -- unrecognized or inappro- 105 -- priate matching rule in 106 -- sort key 107 insufficientAccessRights (50), -- refused to return sorted 108 -- results to this client 109 busy (51), -- too busy to process 110 unwillingToPerform (53), -- unable to sort 111 other (80) 112 }, 113 attributeType [0] AttributeType OPTIONAL } 115 4. Client-Server Interaction 117 The sortKeyRequestControl specifies one or more attribute types and 118 matching rules for the results returned by a search request. The server 119 SHOULD return all results for the search request in the order specified 120 by the sort keys. If the reverseOrder field is set to TRUE, then the 121 entries will be presented in reverse sorted order for the specified 122 key. 124 There are six possible scenarios that may occur as a result of the sort 125 control being included on the search request : 127 1 - If the server does not support this sorting control and the client 128 specified TRUE for the control's criticality field, then the server 129 MUST return unavailableCriticalExtension as a return code in the 130 searchResultDone message and not send back any other results. This 131 behavior is specified in section 4.1.12 of [LDAPv3]. 133 2 - If the server does not support this sorting control and the client 134 specified FALSE for the control's criticality field, then the server 135 MUST ignore the sort control and process the search request as if it 136 were not present. This behavior is specified in section 4.1.12 of 137 [LDAPv3]. 139 3 - If the server supports this sorting control but for some reason 140 cannot sort the search results using the specified sort keys and the 141 client specified TRUE for the control's criticality field, then the 142 server SHOULD do the following: return unavailableCriticalExtension as 143 a return code in the searchResultDone message; include the 144 sortKeyResponseControl in the searchResultDone message, and not send 145 back any search result entries. 147 4 - If the server supports this sorting control but for some reason 148 cannot sort the search results using the specified sort keys and the 149 client specified FALSE for the control's criticality field, then the 150 server should return all search results unsorted and include the 151 sortKeyResponseControl in the searchResultDone message. 153 5 - If the server supports this sorting control and can sort the search 154 results using the specified sort keys, then it should include the 155 sortKeyResponseControl in the searchResultDone message with a 156 sortResult of success. 158 6 - If the search request failed for any reason and/or there are no 159 searchResultEntry messages returned for the search response, then the 160 server SHOULD omit the sortKeyResponseControl from the 161 searchResultDone message. 163 The client application is assured that the results are sorted in the 164 specified key order if and only if the result code in the 165 sortKeyResponseControl is success. If the server omits the 166 sortKeyResponseControl from the searchResultDone message, the client 167 SHOULD assume that the sort control was ignored by the server. 169 The sortKeyResponseControl, if included by the server in the 170 searchResultDone message, should have the sortResult set to either 171 success if the results were sorted in accordance with the keys 172 specified 173 in the sortKeyRequestControl or set to the appropriate error code as 174 to why it could not sort the data (such as noSuchAttribute or 175 inappropriateMatching). Optionally, the server MAY set the 176 attributeType to the first attribute type specified in the SortKeyList 177 that was in error. The client SHOULD ignore the attributeType field if 178 the sortResult is success. 180 The server may not be able to sort the results using the specified sort 181 keys because it may not recognize one of the attribute types, the 182 matching rule associated with an attribute type is not applicable, or 183 none of the attributes in the search response are of these types. 184 Servers may also restrict the number of keys allowed in the control, 185 such as only supporting a single key. 187 Servers that chain requests to other LDAP servers should ensure that 188 the server satisfying the client's request sort the entire result set 189 prior to sending back the results. 191 4.1 Behavior in a chained environment 193 If a server receives a sort request, the client expects to receive a 194 set of sorted results. If a client submits a sort request to a server 195 which chains the request and gets entries from multiple servers, and 196 the client has set the criticality of the sort extension to TRUE, the 197 server MUST merge sort the results before returning them to the client 198 or MUST return unwillingToPerform. 200 4.2 Other sort issues 202 An entry that meets the search criteria may be missing one or more of 203 the sort keys. In that case, the entry is considered to have a value of 204 NULL for that key. This standard considers NULL to be a larger value 205 than all other valid values for that key. For example, if only one key 206 is specified, entries which meet the search criteria but do not have 207 that key collate after all the entries which do have that key. If the 208 reverseOrder flag is set, and only one key is specified, entries which 209 meet the search criteria but do not have that key collate BEFORE all 210 the entries which do have that key. 212 If a sort key is a multi-valued attribute, and an entry happens to have 213 multiple values for that attribute, this standard does not specify 214 which of those values should be considered as the key. 216 5. Interaction with other search controls 218 When the sortKeyRequestControl control is included with the 219 pagedResultsControl control as specified in [LdapPaged], then the 220 server should send the searchResultEntry messages sorted according to 221 the sort keys applied to the entire result set. The server should not 222 simply sort each page, as this will give erroneous results to the 223 client. 225 The sortKeyList must be present on each searchRequest message for the 226 paged result. It also must not change between searchRequests for the 227 same result set. If the server has sorted the data, then it SHOULD 228 send back a sortKeyResponseControl control on every searchResultDone 229 message for each page. This will allow clients to quickly determine 230 if the result set is sorted, rather than waiting to receive the entire 231 result set. 233 6. Security Considerations 235 Implementors and administrators should be aware that allowing sorting 236 of results could enable the retrieval of a large number of records from 237 a given directory service, irregardless of administrative limits set on 238 the maximum number of records to return. 240 A client that desired to pull all records out of a directory service 241 could use a combination of sorting and updating of search filters to 242 retrieve all records in a database in small result sets, thus 243 circumventing administrative limits. 245 This behavior can be overcome by the judicious use of permissions on 246 the directory entries by the administrator and by intelligent 247 implementations of administrative limits on the number of records 248 retrieved by a client. 250 7. References 252 [LDAPv3] 253 Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access 254 Pro- 255 tocol (v3)", RFC 2251, December, 1997. 257 [Bradner97] 258 Bradner, Scott, "Key Words for use in RFCs to Indicate 259 Requirement 260 Levels", RFC 2119, March, 1997. 262 [LdapPaged] 263 C. Weider, A. Herron, and T. Howes, "LDAP Control Extension for 264 Simple Paged Results Manipulation", Internet Draft, February, 1997. 265 Available as draft-ietf-asid-ldapv3-simplepaged-00.txt. 267 8. Author's Address 269 Anoop Anantha 270 Microsoft Corp. 271 1 Microsoft Way 272 Redmond, WA 98052 273 USA 274 Anoopa@microsoft.com 275 +1 425 882-8080 277 Andy Herron 278 Microsoft Corp. 279 1 Microsoft Way 280 Redmond, WA 98052 281 USA 282 andyhe@microsoft.com 283 +1 425 882-8080 285 Tim Howes 286 Netscape Communications Corp. 287 501 E. Middlefield Road 288 Mountain View, CA 94043 289 USA 290 howes@netscape.com 291 +1 415 937-2600 293 Mark Wahl 294 Critical Angle Inc. 295 4815 W Braker Lane #502-385 296 Austin, TX 78759 297 USA 298 M.Wahl@critical-angle.com 300 Chris Weider 301 Microsoft Corp. 302 1 Microsoft Way 303 Redmond, WA 98052 304 USA 305 Cweider@microsoft.com 306 +1 425 882-8080