idnits 2.17.1 draft-melnikov-imapext-multimailbox-search-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 333. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (April 22, 2008) is 5849 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 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMAP Extensions Working Group B. Leiba 3 Internet-Draft IBM T.J. Watson Research Center 4 Intended status: Standards Track A. Melnikov 5 Expires: October 24, 2008 Isode Limited 6 April 22, 2008 8 IMAP4 Multimailbox SEARCH Extension 9 draft-melnikov-imapext-multimailbox-search-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 24, 2008. 36 Abstract 38 The IMAP4 specification allows the searching only of the selected 39 mailbox. A user often wants to search multiple mailboxes, and a 40 client that wishes to support this must issue a series of SELECT and 41 SEARCH commands, waiting for each to complete before moving on to the 42 next. This extension allows a client to search multiple mailboxes 43 with one command, limiting the round-trips and waiting for various 44 searches to complete. This also introduces mailbox field in ESEARCH 45 responses, allowing a client to pipeline the searches if it chooses. 47 Note 49 A revised version of this draft document will be submitted to the RFC 50 editor as a Proposed Standard for the Internet Community. Discussion 51 and suggestions for improvement are requested, and should be sent to 52 ietf-imapext@imc.org. 54 Table of Contents 56 1. Conventions used in this document . . . . . . . . . . . . . . . 3 58 2. Extended SEARCH/UID SEARCH command . . . . . . . . . . . . . . 3 60 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 70 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 73 Intellectual Property and Copyright Statements . . . . . . . . 9 75 1. Conventions used in this document 77 In examples, "C:" indicates lines sent by a client that is connected 78 to a server. "S:" indicates lines sent by the server to the client. 80 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are 81 used in this document as specified in RFC 2119 [Kwds]. 83 2. Extended SEARCH/UID SEARCH command 85 Arguments: OPTIONAL source options 86 OPTIONAL result options 87 OPTIONAL [CHARSET] specification 88 searching criteria (one or more) 90 Responses: REQUIRED untagged response: SEARCH or ESEARCH 92 Result: OK - search completed 93 NO - search error: cannot search that [CHARSET] 94 or criteria 95 BAD - command unknown or arguments invalid 97 This section further updates definition of the SEARCH command 98 described in section 2.6.1 of [IMAPABNF] (initially described in 99 section 6.4.4 of [RFC3501]. 101 The SEARCH command is extended to allow for optional source and 102 result options. This document does not define any result options. 104 Unless specified otherwise by a description of a result option, 105 presence of a search source option REQUIREs that the server returns 106 ESEARCH responses instead of the corresponding SEARCH responses. 107 Because message numbers are not useful for mailboxes which are not 108 selected, each ESEARCH response MUST return information about UIDs 109 and not message numbers (whether the SEARCH or the UID SEARCH command 110 was issued), in particular it MUST contain the UID indicator. 112 Presence of a source option in absence of a result option implies the 113 "ALL" result option (see [ESEARCH]). 115 [[anchor3: SEARCH with source options is allowed in authenticated 116 state (and not just "selected")!!!]] 118 Source options describe which mailboxes must be searched for 119 messages. (Without the source options only the current mailbox is 120 searched.) Note that a SEARCH/UID SEARCH command with source options 121 doesn't affect which mailbox is currently selected and doesn't 122 require any mailbox to be selected. For each mailbox satisfying the 123 source options, a single ESEARCH response MUST be returned. The 124 ESEARCH response MUST contain the MAILBOX correlator in addition to 125 the TAG correlator. Correlators allow clients to issue several 126 SEARCH/UID SEARCH commands at once (pipelined). The server MAY 127 perform those searches in parallel; or it MAY instead serialize them. 129 The source options, if present, MUST contain one or more mailbox list 130 pattern, any one of them can contain the IMAP mailbox wildcard 131 characters. The patterns can be optionally followed by other search 132 source options. Only one such option is defined by this document: 133 "DEPTH". The option "depth " causes the SEARCH command to 134 traverse the hierarchy "n" levels down (including the current level). 135 Thus, mailbox pattern "xyz*" with "depth 2" and mailbox pattern 136 "xyz/*" with "depth 1" will both match child mailboxes of "xyz", but 137 will not match child mailboxes of those children (of course, the 138 former will also match "xyzabc", while the latter will not). 140 If the server supports the ACL [ACL] extension, then the logged in 141 user is required to have the 'r' right for each mailbox she wants to 142 search. Mailboxes matching the source options for which the logged 143 in user has no 'r' right MUST be ignored by a multimailbox search. 145 [[anchor4: Borrow syntax from the recent 146 draft-ietf-lemonade-imap-notify?]] 148 [[anchor5: Interaction with CONTEXT 149 (draft-cridland-imap-context-05.txt) needs to be defined. Also, 150 UPDATE option draft-ietf-lemonade-imap-notify might have to be 151 prohibited when both CONTEXT and this extension are used.]] 153 3. Example 155 C: tag1 SEARCH IN (("folder1" "folder2/*") (depth 1)) unseen 156 C: tag2 SEARCH IN (("folder1" "folder2/*")) subject "chad" 157 S: * ESEARCH (TAG "tag1" mailbox "folder1") UID ALL 158 4001,4003,4005,4007,4009 159 S: * ESEARCH (TAG "tag1" mailbox "folder1") UID ALL 195001: 160 195004,169788 161 S: * ESEARCH (TAG "tag1" mailbox "folder2/banana") UID ALL 3002,4004 162 S: * ESEARCH (TAG "tag1" mailbox "folder2/peach") UID ALL 921691 163 S: tag1 OK done 164 S: * ESEARCH (TAG "tag2" mailbox "folder2/dubya") UID ALL 165 50003,50006,50009,50012 166 S: tag2 OK done 168 4. Formal Syntax 170 The following syntax specification uses the augmented Backus-Naur 171 Form (BNF) as described in [ABNF]. Terms not defined here are taken 172 from [RFC3501], [LISTEXT] or [IMAPABNF]. 174 [[anchor7: Updates definition in RFC 4466 (added 175 "[search-source-opts]"):]] 177 search = "SEARCH" [search-source-opts] 178 [search-return-opts] SP search-program 180 [[anchor8: Defined in RFC 4466 (updated to reference 181 search-criteria):]] 183 search-program = ["CHARSET" SP charset SP] 184 search-criteria 185 ;; CHARSET argument to SEARCH MUST be 186 ;; registered with IANA. 188 search-source-opts = SP "IN" SP "(" mbox-or-pat [SP "(" scope- 189 options ")"] ")" 191 scope-option = "DEPTH" SP number / 192 scope-option-ext 194 scope-options = scope-option *(SP scope-option) 195 ;; a given option may only appear once 197 scope-option-name = tagged-ext-label 199 scope-option-ext = scope-option-name [SP scope-option-value] 201 scope-option-value= tagged-ext-val 202 ;; This non-terminal shows recommended syntax 203 ;; for future extensions. 205 [[anchor9: Also defined in FILTERS:]] 207 search-criteria = search-key *(SP search-key) 209 [[anchor10: Redefining search-correlator from RFC 4466:]] 211 search-correlator = SP "(" single-correlator *(SP single-correlator) 212 ")" 214 [[anchor11: This is a new non-terminal:]] 216 single-correlator = "TAG" SP tag-string / 217 "MAILBOX" SP astring 219 [[anchor12: The following 2 are borrowed from LISTEXT:]] 221 mbox-or-pat = list-mailbox / patterns 223 patterns = "(" list-mailbox *(SP list-mailbox) ")" 225 5. Security Considerations 227 [[anchor13: TBD]] 229 6. IANA Considerations 231 IMAP4 capabilities are registered by publishing a standards track or 232 IESG approved experimental RFC. The registry is currently located 233 at: 235 http://www.iana.org/assignments/imap4-capabilities 237 This document defines the X-DRAFT-I03-MMBX [[anchor14: Note to RFC 238 Editor: fix before publication]] IMAP capability. IANA is requested 239 to add it to the registry. 241 7. Acknowledgements 243 The authors gratefully acknowledge feedback provided by Peter Coates 244 and Arnt Gulbrandsen. 246 8. Normative References 248 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 249 Specifications: ABNF", RFC 5234, January 2008. 251 [ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 252 RFC 4314. 254 [CHARSET] Freed, N. and J. Postel, "IANA Charset Registration 255 Procedures", RFC 2978, October 2000. 257 [ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH 258 Command for Controlling What Kind of Information Is 259 Returned", RFC 4731, November 2006. 261 [IMAPABNF] 262 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 263 ABNF", RFC 4466, April 2006. 265 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", RFC 2119, March 1997. 268 [LISTEXT] Leiba, B. and A. Melnikov, "IMAP4 LIST Command 269 Extensions", draft-ietf-imapext-list-extensions-18 (work 270 in progress), 2006. 272 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 273 4rev1", RFC 3501, March 2003. 275 Authors' Addresses 277 Barry Leiba 278 IBM T.J. Watson Research Center 279 19 Skyline Drive 280 Hawthorne, NY 10532 281 US 283 Phone: +1 914 784 7941 284 Email: leiba@watson.ibm.com 285 Alexey Melnikov 286 Isode Limited 287 5 Castle Business Village 288 36 Station Road 289 Hampton, Middlesex TW12 2BX 290 UK 292 Email: Alexey.Melnikov@isode.com 293 URI: http://www.melnikov.ca/ 295 Full Copyright Statement 297 Copyright (C) The IETF Trust (2008). 299 This document is subject to the rights, licenses and restrictions 300 contained in BCP 78, and except as set forth therein, the authors 301 retain all their rights. 303 This document and the information contained herein are provided on an 304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 306 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 307 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 308 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 311 Intellectual Property 313 The IETF takes no position regarding the validity or scope of any 314 Intellectual Property Rights or other rights that might be claimed to 315 pertain to the implementation or use of the technology described in 316 this document or the extent to which any license under such rights 317 might or might not be available; nor does it represent that it has 318 made any independent effort to identify any such rights. Information 319 on the procedures with respect to rights in RFC documents can be 320 found in BCP 78 and BCP 79. 322 Copies of IPR disclosures made to the IETF Secretariat and any 323 assurances of licenses to be made available, or the result of an 324 attempt made to obtain a general license or permission for the use of 325 such proprietary rights by implementers or users of this 326 specification can be obtained from the IETF on-line IPR repository at 327 http://www.ietf.org/ipr. 329 The IETF invites any interested party to bring to its attention any 330 copyrights, patents or patent applications, or other proprietary 331 rights that may cover technology that may be required to implement 332 this standard. Please address the information to the IETF at 333 ietf-ipr@ietf.org.