idnits 2.17.00 (12 Aug 2021) /tmp/idnits37829/draft-leiba-imap-search-multiple-00.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. == 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 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 63: '...The mailbox URLs MUST be relative URLs...' RFC 2119 keyword, line 64: '...d does not do referrals. The URLs MAY...' RFC 2119 keyword, line 70: '...ait for all responses. The server MAY...' RFC 2119 keyword, line 71: '... in parallel; it MAY instead serialize...' RFC 2119 keyword, line 85: '...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 (August 2001) is 7583 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: 9 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Leiba 3 Internet Draft IBM T.J. Watson Research Center 4 Document: draft-leiba-imap-search-multiple-00.txt February 2001 5 Expires August 2001 7 IMAP4 SEARCHM Command for Multiple Mailboxes 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 A revised version of this draft document will be submitted to the RFC 29 editor as an Proposed Standard for the Internet Community. 30 Discussion and suggestions for improvement are requested, and should 31 be sent to ietf-imapext@imc.org. This document will expire before 31 32 August 2001. Distribution of this memo is unlimited. 34 1. Abstract 36 The IMAP4 specification allows the searching only of the selected 37 mailbox. A user often wants to search multiple mailboxes, and a 38 client that wishes to support this must issue a series of SELECT and 39 SEARCH commands, waiting for each to complete before moving on to the 40 next. This extension allows a client to search multiple mailboxes 41 with one command, limiting the round-trips and waiting for various 42 searches to complete. This also introduces named searches, allowing 43 a client to pipeline the searches if it chooses. 45 Internet DRAFT IMAP4 SEARCHM for Multiple Mailboxes February 2001 47 2. Conventions used in this document 49 In examples, "C:" indicates lines sent by a client that is connected 50 to a server. "S:" indicates lines sent by the server to the client. 52 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are 53 used in this document as specified in RFC 2119 [Keywords]. 55 3. The SEARCHM command 57 The basic syntax if the SEARCHM command (see the formal grammar for 58 the exact syntax) is 60 tag SEARCHM "search-name" (options) (list of mailbox URLs) 61 (search criteria) 63 The mailbox URLs MUST be relative URLs that point to IMAP mailboxes 64 on this server; this command does not do referrals. The URLs MAY 65 contain the IMAP mailbox wildcard characters. The search criteria 66 are the same as those specified in [IMAP]. 68 The search name is used to related the SEARCHM responses to the 69 search performed, allowing the client to send multiple SEARCHM 70 commands without having to wait for all responses. The server MAY 71 perform those searches in parallel; it MAY instead serialize them. 73 The options control the operation of the SEARCHM command. There is 74 one option defined by this document: "depth". The option "depth(n)" 75 causes the SEARCHM command to traverse the hierarchy "n" levels down 76 (including the current level). Thus, "xyz*" with depth(2) and 77 "xyz/*" with depth(1) will both match child mailboxes of "xyz", but 78 will not match child mailboxes of those children (of course, the 79 former will also match "xyzabc", while the latter will not). 81 Other options may be defined by extensions. 83 The server returns one untagged SEARCHM response for each mailbox 84 that matches one or more of the URLs and that has messages that match 85 the search criteria. The server MUST NOT return a SEARCHM response 86 that lists no message numbers. There are also no errors that come 87 from unmatched mailbox URLs. 89 The command "UID SEARCHM" behaves in an analogous way to "UID SEARCH" 90 (see [IMAP]), returning UIDs instead of message numbers. 92 B. Leiba Expires August 2001 [Page 93 2] 95 Internet DRAFT IMAP4 SEARCHM for Multiple Mailboxes February 2001 97 4. Example 99 C: tag1 SEARCHM "unseen" (depth(1)) ("folder1" "folder2/*") (unseen) 100 C: tag2 SEARCHM "chad" () ("folder1" "folder2/*") (subject "chad") 101 S: * SEARCHM "unseen" "folder1" (1 3 5 7 9) 102 S: * SEARCHM "chad" "folder1" (1 2 3 4 8) 103 S: * SEARCHM "unseen" "folder2/banana" (2 4) 104 S: * SEARCHM "unseen" "folder2/peach" (691) 105 S: tag1 OK done 106 S: * SEARCHM "chad" "folder2/dubya" (3 6 9 12) 107 S: tag2 OK done 109 5. Formal Grammar 111 Items not defined here are defined in the formal grammar of [IMAP]. 113 mailbox_list ::= 1#mailbox_URL 114 mailbox_URL ::= ??? 115 ;; relative URL -- see [IMAPURL] 116 ;; may contain list_wildcards 117 searchm ::= "SEARCHM" SPACE search_name 118 SPACE "(" search_options ")" 119 SPACE "(" mailbox_list ")" 120 SPACE "(" search_criteria ")" 121 search_criteria ::= ["CHARSET" SPACE astring SPACE] 1#search_key 122 search_name ::= string 123 search_option ::= "DEPTH(" number ")" 124 search_options ::= 0#search_option 125 ;; a given option may only appear once 127 6. Security Considerations 129 This document describes an IMAP4 command similar to the SEARCH 130 command, and has the same security considerations as that command. 131 Those considerations are described in [IMAP]. 133 7. References 135 [IMAP]; Crispin, M.; "Internet Message Access Protocol - Version 136 4rev1"; RFC 2060; University of Washington; December 1996. 138 [IMAPURL]; Newman, C.; "IMAP URL Scheme"; RFC 2192; Innosoft; 139 September 1997. 141 [Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate 143 Internet DRAFT IMAP4 SEARCHM for Multiple Mailboxes February 2001 145 Requirement Levels"; RFC 2119; Harvard University; March 1997. 147 8. Author's Address 149 Barry Leiba 150 IBM T.J. Watson Research Center 151 30 Saw Mill River Road 152 Hawthorne, NY 10532 154 Phone: 1-914-784-7941 155 Email: leiba@watson.ibm.com 157 B. Leiba Expires