IMAP Extension for Referencing the Last SEARCH Result
RFC 5182

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

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 the