[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5182

Document: draft-melnikov-imap-search-res-01.txt           A. Melnikov
Intended category: Standard Track                          Isode Ltd.
Expires: August 2005                                    February 2005

         IMAP extension for referencing the last SEARCH result

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   A revised version of this draft document will be submitted to the RFC
   editor as a Proposed Standard for the Internet Community.  Discussion
   and suggestions for improvement are requested, and should be sent to
   the IMAPEXT Mailing list <ietf-imapext@imc.org>. Distribution of this
   draft is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.


   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

Melnikov                  Expires: August 2005                  [Page 1]

INTERNET DRAFT        Last SEARCH result reference         February 2005

   2501, 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.

   This document proposes an IMAP extension that allows a client to tell
   a server to use the result of the latest SEARCH (or UID SEARCH)
   command as an input to any subsequent command.

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 keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
   this document when typed in uppercase are to be interpreted as
   defined in "Key words for use in RFCs to Indicate Requirement Levels"

   <<Other editorial comments/questions are shown like this.>>

2.   New sequence element for referencing the result of the last SEARCH

   The SEARCH result reference extension described in this document is
   present in any IMAP4 implementation which returns "X-DRAFT-
   I01-SEARCHRES" as one of the supported capabilities in the CAPABILITY
   command response. <<Note to the RFC Editor: the capability name will
   change upon publication as an RFC>>.

   The SEARCH result reference extension REQUIREs that a compliant
   server remembers the result of the latest SEARCH (also UID SEARCH,
   SORT, UID SORT) command and stores it in an internal variable that we
   will reference as the "search result variable". The client can use
   the "$" marker in message (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 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 command with a
      subsequent FETCH/STORE/COPY/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. <<?>>

Melnikov                  Expires: August 2005                  [Page 2]

INTERNET DRAFT        Last SEARCH result reference         February 2005

   Upon successful completion of SELECT or EXAMINE command, the current
   search result variable is reset to the empty sequence.  <<Change this
   to "1:*" if this is more useful?>>

   A successful SEARCH command sets the value of the search result
   variable to the list of messages found in the SEARCH command. For
   example, if no messages were found, the search result variable will
   contain the empty list.  A failed SEARCH command (any SEARCH command
   that caused the server to return BAD or NO tagged response) doesn't
   change the search result variable.

   When a message listed in the search result variable is EXPUNGEd, it
   is automatically removed from the list.  (Implementation note: if the
   server stores the list as a list of message numbers, it MUST
   automatically adjust them when sending any untagged EXPUNGE response)

   If the server decides to send a new UIDVALIDITY value while mailbox
   is opened, this causes resetting the search variable to the empty

   <<Implementation consideration: SEARCH returned message numbers, the
   next command is an UID command (or vice versa)>>

   <<Open Issues:

   1). Does this has to be extended to apply to other commands, e.g.

   2). Add a SEARCH command parameter that suppresses sending untagged
       SEARCH result? (probably "yes") >>

 2.1.   Examples

   1) The following example demonstrates how the client can use the
      result of a SEARCH command to FETCH headers of interesting

   Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
               S: * SEARCH 2 84 882
               S: A282 OK SEARCH completed
               S: * 2 FETCH (UID 14 ...
               S: * 84 FETCH (UID 100 ...
               S: * 882 FETCH (UID 1115 ...
               S: A283 OK completed

   The client can also pipeline the two commands:

Melnikov                  Expires: August 2005                  [Page 3]

INTERNET DRAFT        Last SEARCH result reference         February 2005

   Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
               S: * SEARCH 2 84 882
               S: A282 OK SEARCH completed
               S: * 2 FETCH (UID 14 ...
               S: * 84 FETCH (UID 100 ...
               S: * 882 FETCH (UID 1115 ...
               S: A283 OK completed

   2) The following example demonstrates that the result of one SEARCH
      command can be used to subset the result of another SEARCH

   Example:    C: A300 SEARCH SINCE 1-Jan-2004 NOT FROM "Smith"
               S: * SEARCH 3 16 18 21 501 502 503 504 508 611
               S: A300 OK SEARCH completed
               C: A301 UID SEARCH UID $ SMALLER 4096
               S: * SEARCH 17 900 901
               S: A301 OK completed

   3) The following example demonstrates that a failed SEARCH doesn't
      invalidate the search result variable. It also shows that the "$"
      marker can be combined with other message numbers using the OR
      SEARCH criterion.
   Example:    C: B282 SEARCH SINCE 1-Feb-1994 NOT FROM "Smith"
               S: * SEARCH 2 84 882 1102 2056
               S: B282 OK SEARCH completed
               C: B283 SEARCH CHARSET KOI8-R (OR $ 1,3000:3021) TEXT {4}
               C: XXXX
               S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported
               C: B284 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8}
               C: YYYYYYYY
               S: * SEARCH 882 1102 3003 3005 3006
               S: B284 OK completed

        Note: Since this document is restricted to 7-bit ASCII text, it
        is not possible to show actual KOI8-R or UTF-8 data.  The "XXXX"
        and ""YYYYYYYY" are placeholders for what would be 4 and 8
        octets of 8-bit data in an actual transaction.

   3.   Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced
   but not defined below are as defined by [IMAP4].

   Except as noted otherwise, all alphabetic characters are case-

Melnikov                  Expires: August 2005                  [Page 4]

INTERNET DRAFT        Last SEARCH result reference         February 2005

   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

   sequence-set    =/ seq-last-command
                       ; Extend sequence-set to allow for "result of the
                       ; last command" indicator.

   seq-last-command= "$"

4.   Security Considerations

   It is believed that this extension doesn't raise any additional
   security concerns not already discussed in [IMAP4].

   <<However, this extension might require the server to keep additional
   state, that may be used to simplify Deny of Service attack.>>

5.   Acknowledgments

   The author would like to thank Mark Crispin for reminding that this
   document has to be written, as well as for comments and corrections

6.   References

6.1. Normative references

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997.

   [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax
   Specifications: ABNF", RFC 2234, November 1997.

   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
   4rev1", RFC 3501, University of Washington, March 2003.


6.2. Informative references

   [UIDPLUS] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1998.

Melnikov                  Expires: August 2005                  [Page 5]

INTERNET DRAFT        Last SEARCH result reference         February 2005

7.   Author's Addresses

   Alexey Melnikov
   Isode Ltd.
   5 Castle Business Village,
   36 Station Road,
   Hampton, Middlesex,
   TW12 2BX, United Kingdom

   Email: Alexey.Melnikov@isode.com

8.   Full Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

9.   Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

Melnikov                  Expires: August 2005                  [Page 6]

INTERNET DRAFT        Last SEARCH result reference         February 2005


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-

Melnikov                  Expires: August 2005                  [Page 7]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/