IMAP Extension for Referencing the Last SEARCH Result
RFC 5182
Document | Type |
RFC - Proposed Standard
(March 2008; No errata)
Updates RFC 3501
Was draft-melnikov-imap-search-res (individual in app area)
|
|
---|---|---|---|
Last updated | 2018-12-20 | ||
Stream | IETF | ||
Formats | plain text pdf html bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5182 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Chris Newman | ||
Send notices to | (None) |
Network Working Group A. Melnikov Request for Comments: 5182 Isode Ltd. Updates: 3501 March 2008 Category: Standards Track IMAP Extension for Referencing the Last SEARCH Result Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox. This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations. This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID) SEARCH) command as an input to any subsequent command. 1. Introduction Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox. This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or UID SEARCH) command as an input to any subsequent command. The SEARCH result reference extension defines a new SEARCH result option [IMAPABNF] "SAVE" that tells the server to remember the result of the SEARCH or UID SEARCH command (as well as any command based on SEARCH, e.g., SORT and THREAD [SORT]) and store it in an internal Melnikov Standards Track [Page 1] RFC 5182 Last SEARCH Result Reference March 2008 variable that we will reference as the "search result variable". The client can use the "$" marker to reference the content of this internal variable. The "$" marker can be used instead of message sequence or UID sequence in order to indicate that the server should substitute it with the list of messages from the search result variable. Thus, the client can use the result of the latest remembered SEARCH command as a parameter to another command. The search result marker has several advantages: * it avoids wasted bandwidth and associated delay; * it allows the client to pipeline a SEARCH [IMAP4] command with a subsequent FETCH/STORE/COPY/SEARCH [IMAP4] or UID EXPUNGE [UIDPLUS] command; * the client doesn't need to spend time reformatting the result of a SEARCH command into a message set used in the subsequent command; * it allows the server to perform optimizations. For example, if the server can execute several pipelined commands in parallel (or out of order), presence of the search result marker can allow the server to decide which commands may or may not be executed out of order. In absence of any other SEARCH result option, the SAVE result option also suppresses any SEARCH response that would have been otherwise returned by the SEARCH command. 1.1. Conventions Used in This Document In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. Explanatory comments in examples start with // and are not part of the protocol. Melnikov Standards Track [Page 2] RFC 5182 Last SEARCH Result Reference March 2008 2. Overview 2.1. Normative Description of the SEARCHRES Extension The SEARCH result reference extension described in this document is present in any IMAP4 server implementation that returns "SEARCHRES" as one of the supported capabilities in the CAPABILITY command response. Any such server MUST also implement the [ESEARCH] extension. Upon successful completion of a SELECT or an EXAMINE command (after the tagged OK response), the current search result variable is reset to the empty sequence. A successful SEARCH command with the SAVE result option sets theShow full document text