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 | 2015-10-14 | ||
| 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"
Show full document text