idnits 2.17.00 (12 Aug 2021) /tmp/idnits43098/draft-melnikov-imap-partial-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 34 characters in excess of 72. -- The draft header indicates that this document updates RFC4731, but the abstract doesn't seem to directly say this. It does mention RFC4731 though, so this could be OK. -- The draft header indicates that this document updates RFC5267, but the abstract doesn't seem to directly say this. It does mention RFC5267 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC4731, updated by this document, for RFC5378 checks: 2005-02-11) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (7 February 2022) is 96 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) == Missing Reference: 'MESSAGELIMIT 1000' is mentioned on line 417, but not defined == Unused Reference: 'RFC5256' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC7162' is defined on line 575, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode 4 Updates: 5267, 4731 (if approved) A. P. Achuthan 5 Intended status: Standards Track V. Nagulakonda 6 Expires: 11 August 2022 Yahoo! 7 L. Alves 8 7 February 2022 10 IMAP Paged SEARCH & FETCH Extension 11 draft-melnikov-imap-partial-04 13 Abstract 15 The PARTIAL extension of the Internet Message Access Protocol (RFC 16 3501/RFC 9051) allows clients to limit the number of search results 17 returned, as well as to perform incremental (paged) searches. This 18 also helps servers to optimize resource usage when performing 19 searches. 21 This document extends PARTIAL SEARCH return option originally 22 specified in RFC 5267. It also clarifies some interactions between 23 RFC 5267 and RFC 4731/RFC 9051. 25 This document also describes the MESSAGELIMIT extension for 26 announcing a limit on the number of messages that can be processed in 27 a single FETCH/SEARCH/STORE/COPY/MOVE command. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 11 August 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 75 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 76 3. The PARTIAL extension . . . . . . . . . . . . . . . . . . . . 3 77 3.1. Incremental SEARCH and partial results . . . . . . . . . 4 78 3.2. Interaction between PARTIAL, MIN, MAX and SAVE SEARCH 79 return options . . . . . . . . . . . . . . . . . . . . . 5 80 3.3. Extension to UID FETCH . . . . . . . . . . . . . . . . . 6 81 3.4. Use of PARTIAL and CONDSTORE IMAP extensions together . . 7 82 4. The MESSAGELIMIT extension . . . . . . . . . . . . . . . . . 7 83 4.1. Returning limits on the number of messages processed in a 84 single SEARCH/FETCH/STORE/COPY/MOVE command . . . . . . . 8 85 4.2. Interaction with SORT and THREAD extensions . . . . . . . 10 86 5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 89 7.1. Changes/additions to the IMAP4 capabilities registry . . 12 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 93 9.2. Informative References . . . . . . . . . . . . . . . . . 13 95 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 98 1. Introduction and Overview 100 This document defines an extension to the Internet Message Access 101 Protocol [RFC3501] for performing incremental searches and fetches. 102 This extension is compatible with both IMAP4rev1 [RFC3501] and 103 IMAP4rev2 [RFC9051]. 105 The PARTIAL extension of the Internet Message Access Protocol (RFC 106 3501/RFC 9051) allows clients to limit the number of search results 107 returned, as well as to perform incremental (paged) searches. This 108 also helps servers to optimize resource usage when performing 109 searches. 111 This document extends PARTIAL SEARCH return option originally 112 specified in RFC 5267. It also clarifies some interactions between 113 RFC 5267 and RFC 4731/RFC 9051. 115 This document also describes the MESSAGELIMIT extension for 116 announcing a limit on the number of messages that can be processed in 117 a single FETCH/SEARCH/STORE/COPY/MOVE command. 119 2. Document Conventions 121 In protocol examples, this document uses a prefix of "C: " to denote 122 lines sent by the client to the server, and "S: " for lines sent by 123 the server to the client. Lines prefixed with "// " are comments 124 explaining the previous protocol line. These prefixes and comments 125 are not part of the protocol. Lines without any of these prefixes 126 are continuations of the previous line, and no line break is present 127 in the protocol unless specifically mentioned. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 Other capitalised words are IMAP keywords [RFC3501][RFC9051] or 136 keywords from this document. 138 3. The PARTIAL extension 140 An IMAP server advertises support for the PARTIAL extension by 141 including "PARTIAL" capability in the CAPABILITY response/response 142 code. 144 Clients that implement support for PARTIAL extension MUST also 145 support the MESSAGELIMIT response code (see Section 4). 147 3.1. Incremental SEARCH and partial results 149 The PARTIAL search return option causes the server to provide in an 150 ESEARCH response a subset of the results denoted by the sequence 151 range given as the mandatory argument. The first result (message 152 with the lowest matching UID) is 1; thus, the first 500 results would 153 be obtained by a return option of "PARTIAL 1:500", and the second 500 154 by "PARTIAL 501:1000". This intentionally mirrors message sequence 155 numbers. 157 It is also possible to direct the server to start SEARCH from the 158 latest matching (with the highest UID) message. This can be done by 159 prepeding "-" to the index. For example -1 is the last message, -2 160 is next to the last and so on. Using this syntax helps server 161 implementations to optimize their SEARCHes. 163 A single command MUST NOT contain more than one PARTIAL or ALL search 164 return option -- that is, either one PARTIAL, one ALL, or neither 165 PARTIAL nor ALL is allowed. 167 For SEARCH results, the entire result list MUST be ordered in mailbox 168 order, that is, in UID or message sequence number order. 170 Where a PARTIAL search return option references results that do not 171 exist, by using a range which starts or ends higher (or lower) than 172 the current number of results, then the server returns the results 173 that are in the set. This yields a PARTIAL return data item that 174 has, as payload, the original range and a potentially missing set of 175 results that may be shorter than the extent of the range. If the 176 whole range references results that do not exist, a special value 177 "NIL" is returned by the server instead of the sequence set. 179 Clients need not request PARTIAL results in any particular order. 180 Because mailboxes may change, clients might wish to use PARTIAL in 181 combination with UPDATE (see [RFC5267] if the server also advertises 182 CONTEXT=SEARCH capability, especially if the intent is to walk a 183 large set of results; however, these return options do not interact 184 -- the UPDATE will provide notifications for all matching results. 186 // Let's assume that the A01 SEARCH without PARTIAL would return 187 // 23764 results. 188 C: A01 UID SEARCH RETURN (PARTIAL -1:-100) UNDELETED 189 UNKEYWORD $Junk 190 S: * ESEARCH (TAG "A01") UID PARTIAL (-1:-100 ...) 191 // 100 most recent results in set syntax elided. 192 S: A01 OK Completed. 194 // Let's assume that the A02 SEARCH without PARTIAL would return 195 // 23764 results. 196 C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED 197 UNKEYWORD $Junk 198 C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED 199 UNKEYWORD $Junk 200 C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED 201 UNKEYWORD $Junk 202 S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...) 203 // 264 results in set syntax elided, 204 // this spans the end of the results. 205 S: A02 OK Completed. 206 S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...) 207 // 500 results in set syntax elided. 208 S: A03 OK Completed. 209 S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL) 210 // No results are present, this is beyond the end of the results. 211 S: A04 OK Completed. 213 3.2. Interaction between PARTIAL, MIN, MAX and SAVE SEARCH return 214 options 216 This section only applies if the server advertises PARTIAL IMAP 217 capability or CONTEXT=SEARCH [RFC5267], together with ESEARCH 218 [RFC4731] and/or IMAP4rev2"[RFC9051]. 220 The SAVE result option doesn't change whether the server would return 221 items corresponding to PARTIAL SEARCH result options. 223 As specified in Section 3.1, it is an error to specify both PARTIAL 224 and ALL result options in the same SEARCH command. 226 When the SAVE result option is combined with the PARTIAL result 227 option, and none of MIN/MAX/COUNT result options is present, the 228 corresponding PARTIAL is returned, and the "$" marker would contain 229 all messages returned by the PARTIAL result option. 231 When the SAVE + PARTIAL result options are combined with the MIN or 232 the MAX result option, and the COUNT result option is absent, the 233 corresponding PARTIAL result and MIN/MAX is returned (if the search 234 result is not empty), and the "$" marker would contain all messages 235 returned by the PARTIAL result option + the corresponding MIN/MAX 236 message. 238 If the SAVE + PARTIAL result options are combined with both MIN and 239 MAX result options, and the COUNT result options is absent, the 240 PARTIAL, MIN and MAX are returned (if the search result is not 241 empty), and the "$" marker would contain all messages returned by the 242 PARTIAL result option plus MIN and MAX messages. 244 If the SAVE + PARTIAL result options are combined with the COUNT 245 result option, the PARTIAL and COUNT are returned, and the "$" marker 246 would always contain all messages found by the SEARCH or UID SEARCH 247 command. 249 The following table summarizes the additional requirement on ESEARCH 250 server implementations described in this section. 252 +==============================+=====================+ 253 | Combination of Result option | "$" marker value | 254 +==============================+=====================+ 255 | SAVE PARTIAL | PARTIAL | 256 +------------------------------+---------------------+ 257 | SAVE PARTIAL MIN | PARTIAL & MIN | 258 +------------------------------+---------------------+ 259 | SAVE PARTIAL MAX | PARTIAL & MAX | 260 +------------------------------+---------------------+ 261 | SAVE PARTIAL MIN MAX | PARTIAL & MIN & MAX | 262 +------------------------------+---------------------+ 263 | SAVE PARTIAL COUNT [m] | all found messages | 264 +------------------------------+---------------------+ 266 Table 1 268 where '[m]' means optional "MIN" and/or "MAX" 270 3.3. Extension to UID FETCH 272 The PARTIAL extension also extends the UID FETCH command with a 273 PARTIAL FETCH modifier. The PARTIAL FETCH modifier has the same 274 syntax as the PARTIAL SEARCH result option. Presence of the PARTIAL 275 FETCH modifier instructs the server to only return FETCH results for 276 messages in the specified range. It is useful when the sequence-set 277 (first) parameter to the UID FETCH command includes unknown number of 278 messages. 280 // Returning information for the last 3 messages in the UID range 281 C: 10 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL -1:-3) 282 S: * 12888 FETCH (FLAGS (\Seen) UID 25996) 283 S: * 12889 FETCH (FLAGS (\Flagged \Answered) UID 25997) 284 S: * 12890 FETCH (FLAGS () UID 26600) 285 S: 10 OK FETCH completed 287 // Returning information for the first 5 messages in the UID range 288 C: 11 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL 1:5) 289 S: * 12591 FETCH (FLAGS (\Seen) UID 25900) 290 S: * 12592 FETCH (FLAGS (\Flagged) UID 25902) 291 S: * 12593 FETCH (FLAGS (\Answered) UID 26310) 292 S: * 12594 FETCH (FLAGS () UID 26311) 293 S: * 12595 FETCH (FLAGS (\Answered) UID 26498) 294 S: 11 OK FETCH completed 296 3.4. Use of PARTIAL and CONDSTORE IMAP extensions together 298 This section is informative. 300 The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE 301 FETCH modifier. 303 // Returning information for the last 30 messages in the UID range 304 // that have any flag/keyword modified since modseq 98305 305 C: 101 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL -1:-30 CHANGEDSINCE 98305) 306 S: * 12888 FETCH (FLAGS (\Flagged \Answered) MODSEQ (98306) UID 25997) 307 S: * 12890 FETCH (FLAGS () MODSEQ (98312) UID 26600) 308 S: 101 OK FETCH completed 310 The above example causes the server to first select the last 30 311 messages and then only return flag changes for subset of these 312 messages which have MODSEQ higher than 98305. 314 Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers in 315 the UID FETCH command is not important, i.e. the above example can 316 also use "UID FETCH 25900:26600 (UID FLAGS) (CHANGEDSINCE 98305 317 PARTIAL -1:-30)" command and it would result in the same responses. 319 4. The MESSAGELIMIT extension 321 An IMAP server advertises support for the MESSAGELIMIT extension by 322 including "MESSAGELIMIT=" capability in the CAPABILITY 323 response/response code, where "" is a positive integer that 324 conveys the maximum number of messages that can be processed in a 325 single SEARCH/FETCH/STORE/COPY/MOVE command. 327 4.1. Returning limits on the number of messages processed in a single 328 SEARCH/FETCH/STORE/COPY/MOVE command 330 // Do we need a way to specify SEARCH criterion for "all UIDs after" 331 // or "all UIDs before" a specific UID? 333 If a server implementation doesn't allow more than messages to be 334 operated on by a single SEARCH/FETCH/STORE/COPY/MOVE command, it MUST 335 return the MESSAGELIMIT response code defined below: 337 MESSAGELIMIT The server doesn't allow more than messages to be operated 338 on by a single SEARCH/FETCH/STORE/COPY/MOVE command. The 339 lowest processed UID is . The client needs to repeat 340 the operation for remaining messages, if required. 342 In the following example the value is 1000 and the lowest 343 processed UID is 23221. 345 C: 03 FETCH 10000:14589 (UID FLAGS) 346 S: * 14589 FETCH (FLAGS (\Seen) UID 25000) 347 S: * 14588 FETCH (FLAGS (\Answered) UID 24998) 348 S: ... further 997 fetch responses 349 S: * 13590 FETCH (FLAGS () UID 23221) 350 S: 03 OK [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial 351 results 353 In the following example the client searches for UNDELETED UIDs 354 between 22000:25000. The total number of matching messages 355 exceeds the server's published 1000 messages limit. 357 C: 04 UID SEARCH UID 22000:25000 UNDELETED 358 S: * SEARCH 25000 24998 (... 997 UIDs ...) 23221 359 S: 04 OK [MESSAGELIMIT 1000 23221] SEARCH completed with 1000 partial results 361 The following example demonstrates copy of messages with UIDs 362 between 18000:21000. The total message count exceeds the 363 server's published 1000 messages limit. 365 C: 05 UID COPY 18000:21000 "Trash" 366 S: * NO [MESSAGELIMIT 1000 20001] Too many messages to copy 367 S: 05 OK [COPYUID 1397597919 20001:21000 21363:22362] COPY completed for the last 1000 messages 369 Open Issue: Note that the above example shows a UID COPY that 370 partially fails. This is assumed to be better for clients that 371 don't understand the MESSAGELIMIT response code. However this 372 might cause naive clients to believe that the COPY fully 373 completed and that all messages were copied. (An alternative 374 would be to return MESSAGELIMIT in the tagged NO response, 375 meaning that no messages could be copied. However this 376 wouldn't work well with clients that don't support MESSAGELIMIT 377 response code.) 379 The following example shows MOVE of messages with UIDs between 380 18000:21000. The total message count exceeds the server's 381 published 1000 messages limit. The client that wants to move 382 all messages in the range and observes a MESSAGELIMIT response 383 code, can repeat the command by updating the UID set parameter 384 specified in the command. The client needs to keep doing this 385 until MESSAGELIMIT response is not returned (or until a tagged 386 NO/BAD is returned). 388 C: 06 UID MOVE 18000:21000 "Archive/2021/2021-12" 389 S: * OK [COPYUID 1397597919 20001:21000 22363:23362] Some messages were not moved 390 S: * 12336 EXPUNGE 391 S: * 12335 EXPUNGE 392 ... 393 S: * 11335 EXPUNGE 394 S: 06 OK [MESSAGELIMIT 1000 20001] MOVE completed for the last 1000 messages 396 The following example shows update of flags for messages with 397 UIDs between 18000:20000. The total message count exceeds the 398 server's published 1000 messages limit. The client that wants 399 to change flags for all messages in the range and observes a 400 MESSAGELIMIT response code, can repeat the command by updating 401 the UID set parameter specified in the command. The client 402 needs to keep doing this until MESSAGELIMIT response is not 403 returned (or until a tagged NO/BAD is returned). 405 C: 07 UID STORE 18000:20000 +FLAGS (\Seen) 406 S: * 11215 FETCH (FLAGS (\Seen \Deleted) UID 20000) 407 S: * 11214 FETCH (FLAGS (\Seen \Answered \Deleted) UID 19998) 408 ... 409 S: * 10216 FETCH (FLAGS (\Seen) UID 19578) 410 S: 07 OK [MESSAGELIMIT 1000 19578] STORE completed for the last 1000 messages 412 The following example shows use of MESSAGELIMIT response code 413 together with the PARTIAL extension. The total message count 414 exceeds the server's published 1000 messages limit. 416 C: 08 UID FETCH 22000:25000 (UID FLAGS MODSEQ) (PARTIAL -1:-1500) 417 S: 08 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum 1000 message limit 419 Note that when the server needs to return both EXPUNGEISSUED 420 ([RFC9051]) and MESSAGELIMIT response codes, the former MUST be 421 returned in the tagged OK response, while the latter MUST be returned 422 in an untagged NO response. The following example demonstrates that: 424 C: 031 FETCH 10000:14589 (UID FLAGS) 425 S: * 14589 FETCH (FLAGS (\Seen) UID 25000) 426 S: * 14588 FETCH (FLAGS (\Answered) UID 24998) 427 S: ... further 997 fetch responses 428 S: * 13590 FETCH (FLAGS () UID 23221) 429 S: * NO [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial 430 results 431 S: 031 OK [EXPUNGEISSUED] Some messages were also expunged 433 4.2. Interaction with SORT and THREAD extensions 435 Servers that advertise MESSAGELIMIT N will be unable to execute 436 THREAD command on mailboxes with more than N messages. 438 Servers that advertise MESSAGELIMIT N might be unable to execute SORT 439 command on mailboxes with more than N messages, unless they maintain 440 indeces for different SORT orders they support. 442 5. Formal syntax 444 The following syntax specification uses the Augmented Backus-Naur 445 Form (ABNF) notation as specified in [ABNF]. 447 Non-terminals referenced but not defined below are as defined by 448 IMAP4 [RFC3501]. 450 Except as noted otherwise, all alphabetic characters are case- 451 insensitive. The use of upper or lower case characters to define 452 token strings is for editorial clarity only. Implementations MUST 453 accept these strings in a case-insensitive fashion. 455 SP = 456 MINUS = "-" 458 capability =/ "PARTIAL" 459 ;; from [RFC3501] 461 modifier-partial = "PARTIAL" SP partial-range 462 partial-range-first = nz-number ":" nz-number 463 ;; Request to search from oldest (lowest UIDs) to 464 ;; more recent messages. 465 ;; A range 500:400 is the same as 400:500. 466 ;; This is similar to from [RFC3501], 467 ;; but cannot contain "*". 469 partial-range-last = MINUS nz-number ":" MINUS nz-number 470 ;; Request to search from newest (highest UIDs) to 471 ;; oldest messages. 472 ;; A range -500:-400 is the same as -400:-500. 474 partial-range = partial-range-first / partial-range-last 476 search-return-opt =/ modifier-partial 477 ;; All conform to , from [IMAP-ABNF]/[RFC9051] 479 search-return-data =/ ret-data-partial 481 ret-data-partial = "PARTIAL" 482 SP "(" partial-range SP partial-results ")" 483 ;; is the requested range. 485 partial-results = sequence-set / "NIL" 486 ;; from [RFC3501]. 487 ;; NIL indicates no results correspond to the requested range. 489 tagged-ext-simple =/ partial-range-last 491 fetch-modifier =/ modifier-partial 493 capability =/ "MESSAGELIMIT=" message-limit 494 ;; from [RFC3501] 496 message-limit = nz-number 498 resp-text-code =/ "MESSAGELIMIT" SP message-limit [SP uniqueid] 499 ;; No more than nz-number messages can be processed 500 ;; by any command at a time. The last (lowest) processed 501 ;; UID is uniqueid. 502 ;; The last parameter is omitted, when not known. 504 6. Security Considerations 506 TBD. 508 7. IANA Considerations 510 7.1. Changes/additions to the IMAP4 capabilities registry 512 IMAP4 capabilities are registered by publishing a standards track or 513 IESG approved Informational or Experimental RFC. The registry is 514 currently located at: 516 https://www.iana.org/assignments/imap4-capabilities 518 IANA is requested to add definition of the PARTIAL extension to point 519 to this document. 521 8. Acknowledgments 523 This document was motivated by Yahoo! team and their questions about 524 best client practices for dealing with large mailboxes. 526 Editor of this document would like to thank the following people who 527 provided useful comments or participated in discussions of this 528 document: Timo Sirainen. 530 This document uses lots of text from RFC 5267. Thus work of the RFC 531 5267 authors Dave Cridland and Curtis King is appreciated. 533 9. References 535 9.1. Normative References 537 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 538 Syntax Specifications: ABNF", RFC 5234, January 2008, 539 . 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, 543 DOI 10.17487/RFC2119, March 1997, 544 . 546 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 547 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 548 . 550 [RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH 551 Command for Controlling What Kind of Information Is 552 Returned", RFC 4731, DOI 10.17487/RFC4731, November 2006, 553 . 555 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access 556 Protocol - SORT and THREAD Extensions", RFC 5256, 557 DOI 10.17487/RFC5256, June 2008, 558 . 560 [RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, 561 DOI 10.17487/RFC5267, July 2008, 562 . 564 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 565 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 566 May 2017, . 568 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 569 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 570 DOI 10.17487/RFC9051, August 2021, 571 . 573 9.2. Informative References 575 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag 576 Changes Resynchronization (CONDSTORE) and Quick Mailbox 577 Resynchronization (QRESYNC)", RFC 7162, 578 DOI 10.17487/RFC7162, May 2014, 579 . 581 Index 583 M 585 M 587 MESSAGELIMIT (response code) 588 Section 4.1, Paragraph 3.2.1 590 Authors' Addresses 592 Alexey Melnikov 593 Isode Limited 595 Email: alexey.melnikov@isode.com 596 URI: https://www.isode.com 598 Arun Prakash Achuthan 599 Yahoo! 601 Email: arunprakash@myyahoo.com 602 Vikram Nagulakonda 603 Yahoo! 605 Email: nvikram_imap@yahoo.com 607 Luis Alves 609 Email: luis.alves@lafaspot.com