idnits 2.17.1 draft-leiba-imap-search-multiple-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 46: '...The mailbox URLs MUST be relative URLs...' RFC 2119 keyword, line 47: '...d does not do referrals. The URLs MAY...' RFC 2119 keyword, line 52: '...ait for all responses. The server MAY...' RFC 2119 keyword, line 53: '... in parallel; it MAY instead serialize...' RFC 2119 keyword, line 64: '...ria. The server MUST NOT return a SEA...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2003) is 7501 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2192 (ref. 'IMAPURL') (Obsoleted by RFC 5092) -- Possible downref: Non-RFC (?) normative reference: ref. 'Keywords' Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Leiba 2 Internet Draft IBM T.J. Watson Research Center 3 Document: draft-leiba-imap-search-multiple-01.txt March 2003 4 Expires September 2003 5 IMAP4 SEARCHM Command for Multiple Mailboxes 6 Status of this Document 7 This document is an Internet-Draft and is in full conformance with 8 all provisions of Section 10 of RFC2026. Internet-Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its areas, 10 and its working groups. Note that other groups may also distribute 11 working documents as Internet-Drafts. 12 Internet-Drafts are draft documents valid for a maximum of six months 13 and may be updated, replaced, or obsoleted by other documents at any 14 time. It is inappropriate to use Internet-Drafts as reference 15 material or to cite them other than as "work in progress." 16 The list of current Internet-Drafts can be accessed at 17 http://www.ietf.org/ietf/1id-abstracts.txt 18 The list of Internet-Draft Shadow Directories can be accessed at 19 http://www.ietf.org/shadow.html. 20 A revised version of this draft document will be submitted to the RFC 21 editor as an Proposed Standard for the Internet Community. 22 Discussion and suggestions for improvement are requested, and should 23 be sent to ietf-imapext@imc.org. This document will expire before 30 24 September 2003. Distribution of this memo is unlimited. 25 1. Abstract 26 The IMAP4 specification allows the searching only of the selected 27 mailbox. A user often wants to search multiple mailboxes, and a 28 client that wishes to support this must issue a series of SELECT and 29 SEARCH commands, waiting for each to complete before moving on to the 30 next. This extension allows a client to search multiple mailboxes 31 with one command, limiting the round-trips and waiting for various 32 searches to complete. This also introduces named searches, allowing 33 a client to pipeline the searches if it chooses. 35 Internet DRAFT IMAP4 SEARCHM for Multiple Mailboxes February 2001 36 2. Conventions used in this document 37 In examples, "C:" indicates lines sent by a client that is connected 38 to a server. "S:" indicates lines sent by the server to the client. 39 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are 40 used in this document as specified in RFC 2119 [Keywords]. 41 3. The SEARCHM command 42 The basic syntax if the SEARCHM command (see the formal grammar for 43 the exact syntax) is 44 tag SEARCHM "search-name" (options) (list of mailbox URLs) 45 (search criteria) 46 The mailbox URLs MUST be relative URLs that point to IMAP mailboxes 47 on this server; this command does not do referrals. The URLs MAY 48 contain the IMAP mailbox wildcard characters. The search criteria 49 are the same as those specified in [IMAP]. 50 The search name is used to related the SEARCHM responses to the 51 search performed, allowing the client to send multiple SEARCHM 52 commands without having to wait for all responses. The server MAY 53 perform those searches in parallel; it MAY instead serialize them. 54 The options control the operation of the SEARCHM command. There is 55 one option defined by this document: "depth". The option "depth(n)" 56 causes the SEARCHM command to traverse the hierarchy "n" levels down 57 (including the current level). Thus, "xyz*" with depth(2) and 58 "xyz/*" with depth(1) will both match child mailboxes of "xyz", but 59 will not match child mailboxes of those children (of course, the 60 former will also match "xyzabc", while the latter will not). 61 Other options may be defined by extensions. 62 The server returns one untagged SEARCHM response for each mailbox 63 that matches one or more of the URLs and that has messages that match 64 the search criteria. The server MUST NOT return a SEARCHM response 65 that lists no message numbers. There are also no errors that come 66 from unmatched mailbox URLs. 67 The command "UID SEARCHM" behaves in an analogous way to "UID SEARCH" 68 (see [IMAP]), returning UIDs instead of message numbers. 70 Internet DRAFT IMAP4 SEARCHM for Multiple Mailboxes February 2001 71 4. Example 72 C: tag1 SEARCHM "unseen" (depth(1)) ("folder1" "folder2/*") (unseen) 73 C: tag2 SEARCHM "chad" () ("folder1" "folder2/*") (subject "chad") 74 S: * SEARCHM "unseen" "folder1" (1 3 5 7 9) 75 S: * SEARCHM "chad" "folder1" (1 2 3 4 8) 76 S: * SEARCHM "unseen" "folder2/banana" (2 4) 77 S: * SEARCHM "unseen" "folder2/peach" (691) 78 S: tag1 OK done 79 S: * SEARCHM "chad" "folder2/dubya" (3 6 9 12) 80 S: tag2 OK done 81 5. Formal Grammar 82 Items not defined here are defined in the formal grammar of [IMAP]. 83 mailbox_list ::= 1#mailbox_URL 84 mailbox_URL ::= ??? 85 ;; relative URL -- see [IMAPURL] 86 ;; may contain list_wildcards 87 searchm ::= "SEARCHM" SPACE search_name 88 SPACE "(" search_options ")" 89 SPACE "(" mailbox_list ")" 90 SPACE "(" search_criteria ")" 91 search_criteria ::= ["CHARSET" SPACE astring SPACE] 1#search_key 92 search_name ::= string 93 search_option ::= "DEPTH(" number ")" 94 search_options ::= 0#search_option 95 ;; a given option may only appear once 96 6. Security Considerations 97 This document describes an IMAP4 command similar to the SEARCH 98 command, and has the same security considerations as that command. 99 Those considerations are described in [IMAP]. 100 7. References 101 [IMAP]; Crispin, M.; "Internet Message Access Protocol - Version 102 4rev1"; RFC 2060; University of Washington; December 1996. 103 [IMAPURL]; Newman, C.; "IMAP URL Scheme"; RFC 2192; Innosoft; 104 September 1997. 105 [Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate 107 Internet DRAFT IMAP4 SEARCHM for Multiple Mailboxes February 2001 108 Requirement Levels"; RFC 2119; Harvard University; March 1997. 109 8. Author's Address 110 Barry Leiba 111 IBM T.J. Watson Research Center 112 30 Saw Mill River Road 113 Hawthorne, NY 10532 114 Phone: 1-914-784-7941 115 Email: leiba@watson.ibm.com