Isode Limited

alexey.melnikov@isode.com https://www.isode.com

Yahoo!

arunprakash@myyahoo.com

Yahoo!

nvikram_imap@yahoo.com

luis.alves@lafaspot.com

art extra The PARTIAL extension of the Internet Message Access Protocol (see RFCs 3501 and 9051) allows clients to limit the number of SEARCH results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches. This document extends the PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions between RFC 5267 and RFCs 4731 and 9051. This document updates RFCs 4731 and 5267.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

• .  Introduction and Overview
• .  Document Conventions
• .  The PARTIAL Extension
  • .  Incremental SEARCH and Partial Results
  • .  Interaction between PARTIAL, MIN, MAX, and SAVE SEARCH Return Options
  • .  Extension to UID FETCH
  • .  Use of "PARTIAL" and "CONDSTORE" IMAP Extensions Together
• .  Formal Syntax
• .  Security Considerations
• .  IANA Considerations
  • .  Changes/Additions to the IMAP Capabilities Registry
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Authors' Addresses

Introduction and Overview This document defines an extension to the Internet Message Access Protocol for performing incremental searches and fetches. This extension is compatible with both IMAP4rev1 and IMAP4rev2 . This extension uses IMAP extensibility rules defined in . The PARTIAL extension of the Internet Message Access Protocol allows clients to limit the number of SEARCH results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches. This document extends the PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions between RFC 5267 and RFCs 4731 and 9051.

Document Conventions In protocol examples, this document uses a prefix of "C: " to denote lines sent by the client to the server and "S: " for lines sent by the server to the client. Lines prefixed with "// " are comments explaining the previous protocol line. These prefixes and comments are not part of the protocol. Lines without any of these prefixes are continuations of the previous line, and no line breaks are present in the protocol unless specifically mentioned. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Other capitalized words are IMAP key words or key words from this document.

The PARTIAL Extension An IMAP server advertises support for the PARTIAL extension by including the "PARTIAL" capability in the CAPABILITY response / response code.

Incremental SEARCH and Partial Results The PARTIAL SEARCH return option causes the server to provide in an ESEARCH response a subset of the results denoted by the sequence range given as the mandatory argument. The first result (message with the lowest matching Unique Identifier (UID)) is 1; thus, the first 500 results would be obtained by a return option of "PARTIAL 1:500" and the second 500 by "PARTIAL 501:1000". This intentionally mirrors message sequence numbers. It is also possible to direct the server to start the SEARCH from the latest matching (with the highest UID) message. This can be done by prepending "-" to the index. For example, -1 is the last message, -2 is next to the last, and so on. Using this syntax helps server implementations to optimize their SEARCHes. A single command MUST NOT contain more than one PARTIAL or ALL search return option; that is, either one PARTIAL, one ALL, or neither PARTIAL nor ALL is allowed. For SEARCH results, the entire list of results MUST be ordered in mailbox order -- that is, in UID or message sequence number order. In cases where a PARTIAL SEARCH return option references results that do not exist by using a range that starts or ends higher (or lower) than the current number of results, the server returns the results that are in the set. This yields a PARTIAL return data item that has, as payload, the original range and a potentially missing set of results that may be shorter than the extent of the range. If the whole range references results that do not exist, a special value "NIL" is returned by the server instead of the sequence set. Clients need not request PARTIAL results in any particular order. Because mailboxes may change, clients might wish to use PARTIAL in combination with UPDATE (see ) if the server also advertises the "CONTEXT=SEARCH" capability, especially if the intent is to walk a large set of results; however, these return options do not interact -- the UPDATE will provide notifications for all matching results. // Let's assume that the A01 SEARCH without PARTIAL would return // 23764 results. C: A01 UID SEARCH RETURN (PARTIAL -1:-100) UNDELETED UNKEYWORD $Junk S: * ESEARCH (TAG "A01") UID PARTIAL (-1:-100 ...) // 100 most recent results in set syntax elided. S: A01 OK Completed. // Let's assume that the A02 SEARCH without PARTIAL would return // 23764 results. C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED UNKEYWORD $Junk C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED UNKEYWORD $Junk C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED UNKEYWORD $Junk S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...) // 264 results in set syntax elided; // this spans the end of the results. S: A02 OK Completed. S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...) // 500 results in set syntax elided. S: A03 OK Completed. S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL) // No results are present; this is beyond the end of the results. S: A04 OK Completed.

Interaction between PARTIAL, MIN, MAX, and SAVE SEARCH Return Options This section only applies if the server advertises the "PARTIAL" IMAP capability or "CONTEXT=SEARCH" , together with "ESEARCH" and/or IMAP4rev2 . The SAVE result option doesn't change whether the server would return items corresponding to PARTIAL SEARCH result options. As specified in , it is an error to specify both the PARTIAL and ALL result options in the same SEARCH command. When the SAVE result option is combined with the PARTIAL result option and none of the MIN/MAX/COUNT result options are present, the corresponding PARTIAL is returned, and the "$" marker would contain references to all messages returned by the PARTIAL result option. When the SAVE and PARTIAL result options are combined with the MIN or MAX result option and the COUNT result option is absent, the corresponding PARTIAL result and MIN/MAX are returned (if the SEARCH result is not empty), and the "$" marker would contain references to all messages returned by the PARTIAL result option together with the corresponding MIN/MAX message. If the SAVE and PARTIAL result options are combined with both the MIN and MAX result options and the COUNT result option is absent, the PARTIAL, MIN, and MAX result options are returned (if the SEARCH result is not empty), and the "$" marker would contain references to all messages returned by the PARTIAL result option together with the MIN and MAX messages. If the SAVE and PARTIAL result options are combined with the COUNT result option, the PARTIAL and COUNT result options are returned, and the "$" marker would always contain references to all messages found by the SEARCH or UID SEARCH command. summarizes additional requirements for ESEARCH server implementations described in this section. Note regarding : "[m]" means optional "MIN" and/or "MAX".

Combination of Result Options	"$" Marker Value
SAVE PARTIAL	PARTIAL
SAVE PARTIAL MIN	PARTIAL & MIN
SAVE PARTIAL MAX	PARTIAL & MAX
SAVE PARTIAL MIN MAX	PARTIAL & MIN & MAX
SAVE PARTIAL COUNT [m]	all found messages

Extension to UID FETCH The PARTIAL extension also extends the UID FETCH command with a PARTIAL FETCH modifier. The PARTIAL FETCH modifier has the same syntax as the PARTIAL SEARCH result option. The presence of the PARTIAL FETCH modifier instructs the server to only return FETCH results for messages in the specified range. It is useful when the sequence-set (first) parameter in the UID FETCH command includes an unknown number of messages. // Returning information for the last 3 messages in the UID range C: 10 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL -1:-3) S: * 12888 FETCH (FLAGS (\Seen) UID 25996) S: * 12889 FETCH (FLAGS (\Flagged \Answered) UID 25997) S: * 12890 FETCH (FLAGS () UID 26600) S: 10 OK FETCH completed // Returning information for the first 5 messages in the UID range C: 11 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL 1:5) S: * 12591 FETCH (FLAGS (\Seen) UID 25900) S: * 12592 FETCH (FLAGS (\Flagged) UID 25902) S: * 12593 FETCH (FLAGS (\Answered) UID 26310) S: * 12594 FETCH (FLAGS () UID 26311) S: * 12595 FETCH (FLAGS (\Answered) UID 26498) S: 11 OK FETCH completed

Use of "PARTIAL" and "CONDSTORE" IMAP Extensions Together This section is informative. The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE FETCH modifier . // Returning information for the last 30 messages in the UID range // that have any flags/keywords modified since MODSEQ 98305 C: 101 UID FETCH 25900:26600 (UID FLAGS ) (PARTIAL -1:-30 CHANGEDSINCE 98305) S: * 12888 FETCH (FLAGS (\Flagged \Answered ) MODSEQ (98306) UID 25997) S: * 12890 FETCH (FLAGS () MODSEQ (98312) UID 26600) S: 101 OK FETCH completed The above example causes the server to first select the last 30 messages and then only return flag changes for a subset of those messages that have MODSEQ higher than 98305. Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers in the UID FETCH command is not important, i.e., the above example can also use the "UID FETCH 25900:26600 (UID FLAGS) (CHANGEDSINCE 98305 PARTIAL -1:-30)" command and it would result in the same responses.

Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in . Non-terminals referenced but not defined below are as defined by IMAP4rev1 or IMAP4rev2. Except as noted otherwise, all alphabetic characters are case insensitive. The use of uppercase or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. SP = <Defined in RFC 5234> MINUS = "-" capability =/ "PARTIAL" ;; <capability> from [RFC3501]. modifier-partial = "PARTIAL" SP partial-range partial-range-first = nz-number ":" nz-number ;; Request to search from oldest (lowest UIDs) to ;; more recent messages. ;; A range 500:400 is the same as 400:500. ;; This is similar to <seq-range> from [RFC3501] ;; but cannot contain "*". partial-range-last = MINUS nz-number ":" MINUS nz-number ;; Request to search from newest (highest UIDs) to ;; oldest messages. ;; A range -500:-400 is the same as -400:-500. partial-range = partial-range-first / partial-range-last search-return-opt =/ modifier-partial ;; All conform to <search-return-opt> from ;; [RFC4466] and [RFC9051]. search-return-data =/ ret-data-partial ret-data-partial = "PARTIAL" SP "(" partial-range SP partial-results ")" ;; <partial-range> is the requested range. partial-results = sequence-set / "NIL" ;; <sequence-set> from [RFC3501]. ;; NIL indicates that no results correspond to ;; the requested range. tagged-ext-simple =/ partial-range-last fetch-modifier =/ modifier-partial ;; <fetch-modifier> from [RFC4466].

Security Considerations This document defines an additional IMAP4 capability. As such, it does not change the underlying security considerations of IMAP4rev1 and IMAP4rev2 . The authors and reviewers believe that no new security issues are introduced with these additional IMAP4 capabilities. This document defines an optimization that can reduce both the amount of work performed by the server and the amount of data returned to the client. Use of this extension is likely to cause the server and the client to use less memory than when the extension is not used. However, as this is going to be new code in both the client and the server, rigorous testing of such code is required in order to avoid introducing new implementation bugs.

IANA Considerations

Changes/Additions to the IMAP Capabilities Registry IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Informational or Experimental RFC. The registry is currently located at . IANA has added the PARTIAL extension to the "IMAP Capabilities" registry with RFC 9394 as the reference.

References Normative References Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK] Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place. This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions. This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. [STANDARDS-TRACK] This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. [STANDARDS-TRACK] The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. Informative References Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience. This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162. Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683.

Acknowledgments This document was motivated by the Yahoo! team and their questions about best client practices for dealing with large mailboxes. The authors of this document would like to thank the following people, who provided useful comments or participated in discussions of this document: and . This document uses a lot of text from RFC 5267. Thus, the work of the RFC 5267 authors -- and -- is appreciated.

Authors' Addresses Isode Limited

alexey.melnikov@isode.com https://www.isode.com

Yahoo!

arunprakash@myyahoo.com

Yahoo!

nvikram_imap@yahoo.com

luis.alves@lafaspot.com