Message ORGanization Working Group B. Leiba Internet-Draft Huawei Technologies Updates: 4466 (if approved) A. Melnikov Intended status: Standards Track Isode Limited Expires: August 9, 2010 February 5, 2010 IMAP4 Multimailbox SEARCH Extension draft-ietf-morg-multimailbox-search-02 Abstract The IMAP4 specification allows the searching only of the selected mailbox. A user often wants to search multiple mailboxes, and a 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. 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 Leiba & Melnikov Expires August 9, 2010 [Page 1]
Internet-Draft IMAP4 Multimailbox SEARCH Extension February 2010 http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 9, 2010. Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Leiba & Melnikov Expires August 9, 2010 [Page 2]
Internet-Draft IMAP4 Multimailbox SEARCH Extension February 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . . 4 2. Extensions to SEARCH/UID SEARCH command . . . . . . . . . . 4 2.1. The ESEARCH response . . . . . . . . . . . . . . . . . . . . 5 2.2. Source options -- specifying mailboxes to search . . . . . . 6 3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 Leiba & Melnikov Expires August 9, 2010 [Page 3]
Internet-Draft IMAP4 Multimailbox SEARCH Extension February 2010 1. Introduction The IMAP4 specification allows the searching only of the selected mailbox. A user often wants to search multiple mailboxes, and a 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. The commands can't be pipelined, because the server might run them in parallel, and the untagged SEARCH responses could not then be distinguished from each other. This extension allows a client to search multiple mailboxes with one command, and includes MAILBOX and TAG fields in the ESEARCH response, yielding the following advantages: o A single command limits the number of round-trips needed to search a set of mailboxes. o A single command eliminates the need to wait for one search to complete before starting the next. o A single command allows the server to optimize the search, if it can. o A command that is not dependent upon the selected mailbox eliminates the need to disrupt the selection state, or to open another IMAP connection. o The MAILBOX and TAG fields in the responses allow a client to distinguish which responses go with which search (and which mailbox). A client can safely pipeline these search commands without danger of confusion. 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 RFC 2119 [RFC2119]. 2. Extensions to SEARCH/UID SEARCH command Leiba & Melnikov Expires August 9, 2010 [Page 4]
Internet-Draft IMAP4 Multimailbox SEARCH Extension February 2010 Arguments: OPTIONAL source options OPTIONAL result options OPTIONAL charset specification (see [RFC2978]) 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 [RFC4466] (initially described in section 6.4.4 of [RFC3501] and extended by [RFC4731]). The SEARCH command is extended to allow for optional source and result options. This document does not define any new result options (see Section 3.1 of [RFC4731]). A server that supports this extension includes [[fix-for-pub-1: "X-DRAFT-I03-MMBX" (changes for publication)]] in its IMAP capability string. 2.1. The ESEARCH response Unless specified otherwise by a description of a result option, in the presence of a search source option the server MUST return ESEARCH responses [RFC4731] 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. This is true even if the source options specify that only the selected mailbox be searched. Presence of a source option in absence of a result option implies the "ALL" result option (see Section 3.1 of [RFC4731]). Note that this is not the same as the result from the SEARCH command described in the IMAP base protocol. Source options describe which mailboxes must be searched for messages. A SEARCH/UID SEARCH command with source options does not affect which mailbox, if any, is currently selected, regardless of which mailboxes are searched. For each mailbox 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 [[Barry: Why not MUST NOT ?]] be returned for mailboxes that contain no matching messages. This is true even when result options such as MIN, MAX, Leiba & Melnikov Expires August 9, 2010 [Page 5]
Internet-Draft IMAP4 Multimailbox SEARCH Extension February 2010 and COUNT are specified (see section 3.1 of [RFC4731]), and the values returned (lowest UID matched, highest UID matched, and number of messages matched, respectively) apply to the mailbox reported in that ESEARCH response. Note that it is now possible for a SEARCH command to return NO untagged responses (no SEARCH nor ESEARCH responses), in the case that there are no matches to the search in any of the mailboxes that satisfy the source options. Clients can detect this situation by finding the tagged OK response without having received any matching untagged ESEARCH responses. 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. 2.2. Source options -- specifying mailboxes to search The source options, if present, MUST contain a mailbox specifier as defined in the IMAP NOTIFY extension [RFC5465], 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. The "personal" source option is a particularly convenient way to search all of the current user's mailboxes. Note that there is no way to use wildcard characters to search all mailboxes; the "mailboxes" source option does not do wildcard expansion. If the source options include (or default to) "selected", the IMAP Leiba & Melnikov Expires August 9, 2010 [Page 6]
Internet-Draft IMAP4 Multimailbox SEARCH Extension February 2010 session MUST be in "selected" state. If the source options specify other mailboxes and NOT "selected", then the IMAP session MUST be in either "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 [RFC4314] 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. 3. Open Issues [[Issues: This is a section of To-Do items and considerations before this draft is done. This section will be worked through, emptied, and removed before we send this on.]] The Security Considerations section needs to be written. Interaction with IMAP Contexts [RFC5267] needs to be defined. Suggestion: UPDATE option of IMAP Notify [RFC5465] might have to be prohibited when both Context and this extension are used. [Barry: But why? Isn't this then the equivalent of doing many SEARCH commands with the UPDATE option?] There's a suggestion to add an EXCLUDE clause (with a nested search criteria). For example, one might want to search "personal" but exclude "mailboxes (Trash Spam)". Cyrus suggests you can use metadata to tag mailboxes that you do or don't want to search, and use search criteria to exclude them (good for mailboxes that you NEVER want searched (as Trash and Spam, above)). 4. Examples 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) Leiba & Melnikov Expires August 9, 2010 [Page 7]
Internet-Draft IMAP4 Multimailbox SEARCH Extension February 2010 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 5. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. Terms not defined here are taken from [RFC3501], [RFC5465], or [RFC4466]. filter-mailboxes-other =/ ("subtree-one" SP one-or-more-mailbox) ; Update definition from IMAP Notify [RFC5465] ; Add new "subtree-one" selector. filter-mailboxes-selected = "selected" ; Update definition from IMAP Notify [RFC5465] ; 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. 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 IMAP4 ABNF [RFC4466] search-correlator = SP "(" one-correlator *(SP one-correlator) ")" ; Updates definition in IMAP4 ABNF [RFC4466] Leiba & Melnikov Expires August 9, 2010 [Page 8]
Internet-Draft IMAP4 Multimailbox SEARCH Extension February 2010 search-source-opts = "IN" SP "(" source-mbox [SP "(" scope-options ")"] ")" source-mbox = filter-mailboxes *(SP filter-mailboxes) ; filter-mailboxes is defined in IMAP Notify [RFC5465] ; See updated definition of filter-mailboxes-other, above. ; See updated definition of filter-mailboxes-selected, above. 6. Security Considerations [[Security: This needs to be filled in.]] 7. IANA Considerations IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located here: http://www.iana.org/assignments/imap4-capabilities This document defines the IMAP capability [[fix-for-pub-2: X-DRAFT- I03-MMBX (changes for publication)]], and IANA is asked to add it to the registry. 8. Acknowledgements The authors gratefully acknowledge feedback provided by Timo Sirainen, Peter Coates and Arnt Gulbrandsen. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005. Leiba & Melnikov Expires August 9, 2010 [Page 9]
Internet-Draft IMAP4 Multimailbox SEARCH Extension February 2010 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006. [RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008. [RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP NOTIFY Extension", RFC 5465, February 2009. Authors' Addresses Barry Leiba Huawei Technologies Phone: +1 646 827 0648 Email: barryleiba@computer.org URI: http://internetmessagingtechnology.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 August 9, 2010 [Page 10]
