idnits 2.17.1 draft-ietf-asid-ldapv3-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-20) 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 5 longer pages, the longest (page 2) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 59: '... orderingRule [0] MatchingRuleId OPTIONAL,...' RFC 2119 keyword, line 101: '... attributeType [0] AttributeType OPTIONAL }...' RFC 2119 keyword, line 130: '...server SHOULD do the following: return...' RFC 2119 keyword, line 148: '...server SHOULD omit the sortKeyResponse...' RFC 2119 keyword, line 162: '...). Optionally, the server MAY set the...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...fts are worki...' == Line 13 has weird spacing: '...ments of the ...' == Line 14 has weird spacing: '...t other group...' == Line 18 has weird spacing: '...and may be ...' == Line 22 has weird spacing: '...atus of any ...' == (17 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 101 -- Looks like a reference, but probably isn't: '1' on line 60 == Unused Reference: 'Bradner97' is defined on line 219, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-asid-ldapv3-protocol-04 -- Unexpected draft version: The latest known version of draft-bradner-key-words is -02, but you're referring to -03. == 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: 12 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Herron, Microsoft 3 INTERNET DRAFT T. Howes, Netscape 4 Expire in six months M. Wahl, Critical Angle Inc 5 16 April, 1997 7 LDAP Control Extension for Server Side Sorting of Search Results 8 draft-ietf-asid-ldapv3-sorting-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference material 20 or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 2. Abstract 29 This document describes two LDAPv3 control extensions for server side 30 sorting of search results. These controls allows a client to specify the 31 attribute types and matching rules a server should use when returning 32 the results to an LDAP search request. The controls may be useful when 33 the LDAP client has limited functionality or for some other reason 34 cannot sort the results but still needs them sorted. Other permissible 35 controls on search operations are not defined in this extension. 37 The sort controls allow a server to return a result code for the sorting 38 of the results that is independent of the result code returned for the 39 search operation. 41 The key words "MUST", "SHOULD", and "MAY" used in this document are to 42 be interpreted as described in [bradner97]. 44 3. The Controls 46 3.1 Request Control 48 This control is included in the searchRequest message as part of the 49 controls field of the LDAPMessage, as defined in Section 4.1.12 of 50 [LDAPv3]. 52 The controlType is set to "1.2.840.113556.1.4.473". The criticality 53 MAY be either TRUE or FALSE (where absent is also equivalent to 54 FALSE) at the client's option. The controlValue is an OCTET STRING, 55 whose value is the BER encoding of a value of the following SEQUENCE: 57 SortKeyList ::= SEQUENCE OF SEQUENCE { 58 attributeType AttributeType, 59 orderingRule [0] MatchingRuleId OPTIONAL, 60 reverseOrder [1] BOOLEAN DEFAULT FALSE } 62 The SortKeyList sequence is in order of highest to lowest sort key 63 precedence. 65 Each attributeType should only occur in the SortKeyList once. If an 66 attributeType is included in the sort key list multiple times, the 67 server should return an error in the sortResult of unwillingToPerform. 69 3.2 Response Control 71 This control is included in the searchResultDone message as part of the 72 controls field of the LDAPMessage, as defined in Section 4.1.12 of 73 [LDAPv3]. 75 The controlType is set to "1.2.840.113556.1.4.474". The criticality is 76 FALSE (MAY be absent). The controlValue is an OCTET STRING, whose 77 value is the BER encoding of a value of the following SEQUENCE: 79 SortResult ::= SEQUENCE { 80 sortResult ENUMERATED { 81 success (0), -- results are sorted 82 operationsError (1), -- server internal failure 83 timeLimitExceeded (3), -- timelimit reached before 84 -- sorting was completed 85 strongAuthRequired (8), -- refused to return sorted 86 -- results via insecure 87 -- protocol 88 adminLimitExceeded (11), -- too many matching entries 89 -- for the server to sort 90 noSuchAttribute (16), -- unrecognized attribute 91 -- type in sort key 92 inappropriateMatching (18), -- unrecognized or inappro- 93 -- priate matching rule in 94 -- sort key 95 insufficientAccessRights (50), -- refused to return sorted 96 -- results to this client 97 busy (51), -- too busy to process 98 unwillingToPerform (53), -- unable to sort 99 other (80) 100 }, 101 attributeType [0] AttributeType OPTIONAL } 103 4. Client-Server Interaction 105 The sortKeyRequestControl specifies one or more attribute types and 106 matching rules for the results returned by a search request. The server 107 SHOULD return all results for the search request in the order specified 108 by the sort keys. If the reverseOrder field is set to TRUE, then the 109 entries will be presented in reverse sorted order for the specified 110 key. 112 There are six possible scenarios that may occur as a result of the sort 113 control being included on the search request : 115 1 - If the server does not support this sorting control and the client 116 specified TRUE for the control's criticality field, then the server 117 MUST return unavailableCriticalExtension as a return code in the 118 searchResultDone message and not send back any other results. This 119 behavior is specified in section 4.1.12 of [LDAPv3]. 121 2 - If the server does not support this sorting control and the client 122 specified FALSE for the control's criticality field, then the server 123 MUST ignore the sort control and process the search request as if it 124 were not present. This behavior is specified in section 4.1.12 of 125 [LDAPv3]. 127 3 - If the server supports this sorting control but for some reason 128 cannot sort the search results using the specified sort keys and the 129 client specified TRUE for the control's criticality field, then the 130 server SHOULD do the following: return unavailableCriticalExtension as 131 a return code in the searchResultDone message; include the 132 sortKeyResponseControl in the searchResultDone message, and not send 133 back any search result entries. 135 4 - If the server supports this sorting control but for some reason 136 cannot sort the search results using the specified sort keys and the 137 client specified FALSE for the control's criticality field, then the 138 server should return all search results unsorted and include the 139 sortKeyResponseControl in the searchResultDone message. 141 5 - If the server supports this sorting control and can sort the search 142 results using the specified sort keys, then it should include the 143 sortKeyResponseControl in the searchResultDone message with a 144 sortResult of success. 146 6 - If the search request failed for any reason and/or there are no 147 searchResultEntry messages returned for the search response, then the 148 server SHOULD omit the sortKeyResponseControl from the 149 searchResultDone message. 151 The client application is assured that the results are sorted in the 152 specified key order if and only if the result code in the 153 sortKeyResponseControl is success. If the server omits the 154 sortKeyResponseControl from the searchResultDone message, the client 155 SHOULD assume that the sort control was ignored by the server. 157 The sortKeyResponseControl, if included by the server in the 158 searchResultDone message, should have the sortResult set to either 159 success if the results were sorted in accordance with the keys specified 160 in the sortKeyRequestControl or set to the appropriate error code as 161 to why it could not sort the data (such as noSuchAttribute or 162 inappropriateMatching). Optionally, the server MAY set the 163 attributeType to the first attribute type specified in the SortKeyList 164 that was in error. The client SHOULD ignore the attributeType field if 165 the sortResult is success. 167 The server may not be able to sort the results using the specified sort 168 keys because it may not recognize one of the attribute types, the 169 matching rule associated with an attribute type is not applicable, or 170 none of the attributes in the search response are of these types. 171 Servers may also restrict the number of keys allowed in the control, 172 such as only supporting a single key. 174 Servers that chain requests to other LDAP servers should ensure that 175 the server satisfying the client's request sort the entire result set 176 prior to sending back the results. 178 5. Interaction with other search controls 180 When the sortKeyRequestControl control is included with the 181 pagedResultsControl control as specified in [LdapPaged], then the 182 server should send the searchResultEntry messages sorted according to 183 the sort keys applied to the entire result set. The server should not 184 simply sort each page, as this will give erroneous results to the 185 client. 187 The sortKeyList must be present on each searchRequest message for the 188 paged result. It also must not change between searchRequests for the 189 same result set. If the server has sorted the data, then it SHOULD 190 send back a sortKeyResponseControl control on every searchResultDone 191 message for each page. This will allow clients to quickly determine 192 if the result set is sorted, rather than waiting to receive the entire 193 result set. 195 6. Security Considerations 197 Implementors and administrators should be aware that allowing sorting 198 of results could enable the retrieval of a large number of records from 199 a given directory service, irregardless of administrative limits set on 200 the maximum number of records to return. 202 A client that desired to pull all records out of a directory service 203 could use a combination of sorting and updating of search filters to 204 retrieve all records in a database in small result sets, thus 205 circumventing administrative limits. 207 This behavior can be overcome by the judicious use of permissions on 208 the directory entries by the administrator and by intelligent 209 implementations of administrative limits on the number of records 210 retrieved by a client. 212 7. References 214 [LDAPv3] 215 Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access Pro- 216 tocol (v3)", Internet Draft, February, 1997. Available as draft- 217 ietf-asid-ldapv3-protocol-04.txt. 219 [Bradner97] 220 Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement 221 Levels", Internet Draft, January, 1997. Available as draft- 222 bradner-key-words-03.txt. 224 [LdapPaged] 225 C. Weider, A. Herron, and T. Howes, "LDAP Control Extension for 226 Simple Paged Results Manipulation", Internet Draft, February, 1997. 227 Available as draft-ietf-asid-ldapv3-simplepaged-00.txt. 229 8. Author's Address 231 Andy Herron 232 Microsoft Corp. 233 1 Microsoft Way 234 Redmond, WA 98052 235 USA 236 andyhe@microsoft.com 237 +1 206 882-8080 239 Tim Howes 240 Netscape Communications Corp. 241 501 E. Middlefield Road 242 Mountain View, CA 94043 243 USA 244 howes@netscape.com 245 +1 415 937-2600 247 Mark Wahl 248 Critical Angle Inc. 249 4815 W Braker Lane #502-385 250 Austin, TX 78759 251 USA 252 M.Wahl@critical-angle.com