[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-melnikov-imapext-multimailbox-search) 00 01 02 03 04 05 06 07 RFC 6237

Message ORGanization Working Group                              B. Leiba
Internet-Draft                                       Huawei Technologies
Updates: 4466 (if approved)                                  A. Melnikov
Intended status: Standards Track                           Isode Limited
Expires: January 8, 2010                                    July 7, 2009


                  IMAP4 Multimailbox SEARCH Extension
                 draft-ietf-morg-multimailbox-search-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 8, 2010.

Copyright Notice

   Copyright (c) 2009 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 (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The IMAP4 specification allows the searching only of the selected
   mailbox.  A user often wants to search multiple mailboxes, and a



Leiba & Melnikov         Expires January 8, 2010                [Page 1]

Internet-Draft     IMAP4 Multimailbox SEARCH Extension         July 2009


   client that wishes to support this must issue a series of SELECT and
   SEARCH commands, waiting for each to complete before moving on to the
   next.  This extension allows a client to search multiple mailboxes
   with one command, limiting the round-trips and waiting for various
   searches to complete, and not requiring disruption of the currently
   selected mailbox.  This also uses MAILBOX and TAG fields in ESEARCH
   responses, allowing a client to pipeline the searches if it chooses.

Note

   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
   morg@ietf.org.


Table of Contents

   1.  Conventions used in this document . . . . . . . . . . . . . . . 3

   2.  Extended SEARCH/UID SEARCH command  . . . . . . . . . . . . . . 3

   3.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

   4.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5

   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6

   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6

   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7

   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7

       Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . 7
















Leiba & Melnikov         Expires January 8, 2010                [Page 2]

Internet-Draft     IMAP4 Multimailbox SEARCH Extension         July 2009


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 RFC 2119 [Kwds].


2.  Extended SEARCH/UID SEARCH command

   Arguments:  OPTIONAL source options
               OPTIONAL result options
               OPTIONAL charset specification (see [CHARSET])
               searching criteria (one or more)

   Responses:  REQUIRED untagged response: SEARCH or ESEARCH

   Result:     OK - search completed
               NO - error: cannot search that charset or criteria
               BAD - command unknown or arguments invalid

   This section further updates definition of the SEARCH command
   described in section 2.6.1 of [IMAPABNF] (initially described in
   section 6.4.4 of [IMAP].

   The SEARCH command is extended to allow for optional source and
   result options.  This document does not define any result options.  A
   server that supports this extension includes "MSEARCH" in its IMAP
   capability string.

   Unless specified otherwise by a description of a result option, in
   the presence of a search source option the server MUST return ESEARCH
   responses instead of the corresponding SEARCH responses.  Because
   message numbers are not useful for mailboxes that are not selected,
   each ESEARCH response MUST return information about UIDs, not message
   numbers, regardless of whether it is in response to a SEARCH or a UID
   SEARCH command.  In particular, the responses MUST contain the UID
   indicator.

   Presence of a source option in absence of a result option implies the
   "ALL" result option (see [ESEARCH]).

   Source options describe which mailboxes must be searched for
   messages.  Note that a SEARCH/UID SEARCH command with source options
   doesn't affect which mailbox, if any, is currently selected,
   regardless of which mailboxes are searched.  For each mailbox



Leiba & Melnikov         Expires January 8, 2010                [Page 3]

Internet-Draft     IMAP4 Multimailbox SEARCH Extension         July 2009


   satisfying the source options, a single ESEARCH response MUST be
   returned if any messages in that mailbox match the search criteria.
   An ESEARCH respoonse SHOULD NOT be returned for mailboxes that
   contain no matching messages.  Each ESEARCH response MUST contain the
   MAILBOX, TAG, and UIDVALIDITY correlators.  Correlators allow clients
   to issue several SEARCH/UID SEARCH commands at once (pipelined).  The
   server MAY perform pipelined searches in parallel; or it MAY instead
   serialize them.

   The source options, if present, MUST contain a mailbox specifier as
   defined in the IMAP NOTIFY extension [NOTIFY], section 6 (using the
   "filter-mailboxes" ABNF item), with the following changes:

   1.  The "selected-delayed" specifier is not valid here.

   2.  A "subtree-one" specifier is added.  The "subtree" specifier
       results in a search of the specified mailbox and all selectable
       mailboxes that are subordinate to it, through an indefinitely
       deep hierarchy.  The "subtree-one" specifier results in a search
       of the specified mailbox and all selectable child mailboxes, one
       hierarchy level down.

   If "subtree" is specified, the server MUST defend against loops in
   the hierarchy (for example, those caused by recursive file-system
   links within the message store).  The server SHOULD do this by
   keeping track of the mailboxes that have been searched, and
   terminating the hierarchy traversal when a repeat is found.  If it
   can not do that, it MAY do it by limiting the hierarchy depth.

   If the source options are not present, the value "selected" is
   assumed -- that is, only the currently selected mailbox is searched.

   If the source options include (or default to) "selected", the IMAP
   session MUST be in "selected" state.  If the source options specify
   other mailboxes and NOT "selected", then the IMAP session MUST be in
   "selected" or "authenticated" state.  If the session is not in a
   correct state, the SEARCH command returns a "BAD" result.

   If the server supports the ACL [ACL] extension, then the logged in
   user is required to have the 'r' right for each mailbox she wants to
   search.  Mailboxes matching the source options for which the logged
   in user has no 'r' right MUST be ignored by a multimailbox search.
   In particular, ESEARCH responses MUST NOT be returned for those
   mailboxes.

   [CONTEXT] [NOTIFY] [[anchor3: Interaction with CONTEXT (RFC 5267)
   needs to be defined.  Also, UPDATE option
   draft-ietf-lemonade-imap-notify might have to be prohibited when both



Leiba & Melnikov         Expires January 8, 2010                [Page 4]

Internet-Draft     IMAP4 Multimailbox SEARCH Extension         July 2009


   CONTEXT and this extension are used.  We might also have to consider
   interaction with ESEARCH, RFC 4731.]]


3.  Example

   C: tag1 SEARCH IN ((mailboxes "folder1" subtree "folder2")) unseen
   C: tag2 SEARCH IN ((mailboxes "folder1" subtree-one "folder2"))
   subject "chad"
   S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL
   4001,4003,4005,4007,4009
   S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 6789023554)
   UID ALL 195001:195004,169788
   S: * ESEARCH (TAG "tag1" MAILBOX "folder2/banana" UIDVALIDITY 503)
   UID ALL 3002,4004
   S: * ESEARCH (TAG "tag1" MAILBOX "folder2/peach" UIDVALIDITY 3) UID
   ALL 921691
   S: tag1 OK done
   S: * ESEARCH (TAG "tag2" MAILBOX "folder2/salmon" UIDVALIDITY
   1111111) UID ALL 50003,50006,50009,50012
   S: tag2 OK done


4.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].  Terms not defined here are taken
   from [IMAP], [NOTIFY], or [IMAPABNF].

   filter-mailboxes-other =/  ("subtree-one" SP one-or-more-mailbox)
           ; Update definition from RFC 5465 [NOTIFY]
           ; Add new "subtree-one" selector.

   filter-mailboxes-selected =  "selected"
           ; Update definition from RFC 5465 [NOTIFY]
           ; We forbid the use of "selected-delayed".

   one-correlator =  ("TAG" SP tag-string) / ("MAILBOX" SP astring) /
           ("UIDVALIDITY" SP nz-number)
           ; Each correlator MUST appear exactly once

   scope-option =  scope-option-name [SP scope-option-value]
           ; No options defined here.  Syntax for future extensions.

   scope-option-name =  tagged-ext-label
           ; No options defined here.  Syntax for future extensions.





Leiba & Melnikov         Expires January 8, 2010                [Page 5]

Internet-Draft     IMAP4 Multimailbox SEARCH Extension         July 2009


   scope-option-value =  tagged-ext-val
           ; No options defined here.  Syntax for future extensions.

   scope-options =  scope-option *(SP scope-option)
           ; A given option may only appear once
           ; No options defined here.  Syntax for future extensions.

   search =  "SEARCH" [SP search-source-opts] [SP search-return-opts] SP
           search-program
           ; Updates definition in RFC 4466 [IMAPABNF]

   search-correlator =  SP "(" one-correlator *(SP one-correlator) ")"
           ; Updates definition in RFC 4466 [IMAPABNF]

   search-source-opts =  "IN" SP "(" source-mbox [SP "(" scope-options
           ")"] ")"

   source-mbox =  filter-mailboxes *(SP filter-mailboxes)
           ; filter-mailboxes is defined in RFC 5465 [NOTIFY]
           ; See updated definition of filter-mailboxes-other, above.
           ; See updated definition of filter-mailboxes-selected, above.


5.  Security Considerations

   [[anchor5: This needs to be properly written.  Notes from minutes of
   IETF 74, for now...]]

   Chris suggests shared mailboxes could be used to force spam into
   search results by owner of shared mailbox.  Chris wonders about a
   parameter that says search only user's own mailboxes (no shared).
   Cyrus says you can use metadata to tag mailboxes you don't want to
   search, and use search criteria to exclude them.  The "personal"
   selector may work for this, as well.

   Suggestions to add EXCLUDE clause (with a nested search criteria) for
   Trash, e.g.

   Suggestions to use metadata tags to mark those mailboxes that you
   want to (not) search


6.  IANA Considerations

   IMAP4 capabilities are registered by publishing a standards track or
   IESG approved experimental RFC.  The registry is currently located
   here:




Leiba & Melnikov         Expires January 8, 2010                [Page 6]

Internet-Draft     IMAP4 Multimailbox SEARCH Extension         July 2009


      http://www.iana.org/assignments/imap4-capabilities


   This document defines the IMAP capability "MSEARCH", and IANA is
   asked to add it to the registry.


7.  Acknowledgements

   The authors gratefully acknowledge feedback provided by Peter Coates
   and Arnt Gulbrandsen.


8.  Normative References

   [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 5234, January 2008.

   [ACL]      Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
              RFC 4314, December 2005.

   [CHARSET]  Freed, N. and J. Postel, "IANA Charset Registration
              Procedures", RFC 2978, October 2000.

   [CONTEXT]  Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
              July 2008.

   [ESEARCH]  Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
              Command for Controlling What Kind of Information Is
              Returned", RFC 4731, November 2006.

   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 3501, March 2003.

   [IMAPABNF]
              Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
              ABNF", RFC 4466, April 2006.

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

   [NOTIFY]   Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
              NOTIFY Extension", RFC 5465, February 2009.








Leiba & Melnikov         Expires January 8, 2010                [Page 7]

Internet-Draft     IMAP4 Multimailbox SEARCH Extension         July 2009


Authors' Addresses

   Barry Leiba
   Huawei Technologies

   Phone: +1 646 827 0648
   Email: barryleiba@computer.org


   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: Alexey.Melnikov@isode.com
   URI:   http://www.melnikov.ca/

































Leiba & Melnikov         Expires January 8, 2010                [Page 8]


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