imapext-2007
view docs/rfc/rfc4731.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
7 Network Working Group A. Melnikov
8 Request for Comments: 4731 Isode Ltd
9 Category: Standards Track D. Cridland
10 Inventure Systems Ltd
11 November 2006
14 IMAP4 Extension to SEARCH Command for Controlling
15 What Kind of Information Is Returned
17 Status of This Memo
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright Notice
27 Copyright (C) The IETF Trust (2006).
29 Abstract
31 This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands
32 with several result options, which can control what kind of
33 information is returned. The following result options are defined:
34 minimal value, maximal value, all found messages, and number of found
35 messages.
37 Table of Contents
39 1. Introduction ....................................................2
40 2. Conventions Used in This Document ...............................2
41 3. IMAP Protocol Changes ...........................................2
42 3.1. New SEARCH/UID SEARCH Result Options .......................2
43 3.2. Interaction with CONDSTORE extension .......................4
44 4. Formal Syntax ...................................................5
45 5. Security Considerations .........................................6
46 6. IANA Considerations .............................................6
47 7. Normative References ............................................6
48 8. Acknowledgments .................................................6
58 Melnikov & Cridland Standards Track [Page 1]
60 RFC 4731 IMAP4 Extension to SEARCH November 2006
63 1. Introduction
65 [IMAPABNF] extended SEARCH and UID SEARCH commands with result
66 specifiers (also known as result options), which can control what
67 kind of information is returned.
69 A server advertising the ESEARCH capability supports the following
70 result options: minimal value, maximal value, all found messages,
71 and number of found messages. These result options allow clients to
72 get SEARCH results in more convenient forms, while also saving
73 bandwidth required to transport the results, for example, by finding
74 the first unseen message or returning the number of unseen or deleted
75 messages. Also, when a single MIN or a single MAX result option is
76 specified, servers can optimize execution of SEARCHes.
78 2. Conventions Used in This Document
80 In examples, "C:" and "S:" indicate lines sent by the client and
81 server, respectively.
83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
85 document are to be interpreted as described in RFC 2119 [KEYWORDS].
87 3. IMAP Protocol Changes
89 3.1. New SEARCH/UID SEARCH Result Options
91 The SEARCH/UID SEARCH commands are extended to allow for the
92 following result options:
94 MIN
95 Return the lowest message number/UID that satisfies the SEARCH
96 criteria.
98 If the SEARCH results in no matches, the server MUST NOT
99 include the MIN result option in the ESEARCH response; however,
100 it still MUST send the ESEARCH response.
102 MAX
103 Return the highest message number/UID that satisfies the SEARCH
104 criteria.
106 If the SEARCH results in no matches, the server MUST NOT
107 include the MAX result option in the ESEARCH response; however,
108 it still MUST send the ESEARCH response.
114 Melnikov & Cridland Standards Track [Page 2]
116 RFC 4731 IMAP4 Extension to SEARCH November 2006
119 ALL
120 Return all message numbers/UIDs that satisfy the SEARCH
121 criteria. Unlike regular (unextended) SEARCH, the messages are
122 always returned using the sequence-set syntax. A sequence-set
123 representation may be more compact and can be used as is in a
124 subsequent command that accepts sequence-set. Note, the client
125 MUST NOT assume that messages/UIDs will be listed in any
126 particular order.
128 If the SEARCH results in no matches, the server MUST NOT
129 include the ALL result option in the ESEARCH response; however,
130 it still MUST send the ESEARCH response.
132 COUNT
133 Return number of the messages that satisfy the SEARCH criteria.
134 This result option MUST always be included in the ESEARCH
135 response.
137 If one or more result options described above are specified, the
138 extended SEARCH command MUST return a single ESEARCH response
139 [IMAPABNF], instead of the SEARCH response.
141 An extended UID SEARCH command MUST cause an ESEARCH response with
142 the UID indicator present.
144 Note that future extensions to this document can allow servers to
145 return multiple ESEARCH responses for a single extended SEARCH
146 command. These extensions will have to describe how results from
147 multiple ESEARCH responses are to be amalgamated.
149 If the list of result options is empty, that requests the server to
150 return an ESEARCH response instead of the SEARCH response. This is
151 equivalent to "(ALL)".
153 Example: C: A282 SEARCH RETURN (MIN COUNT) FLAGGED
154 SINCE 1-Feb-1994 NOT FROM "Smith"
155 S: * ESEARCH (TAG "A282") MIN 2 COUNT 3
156 S: A282 OK SEARCH completed
158 Example: C: A283 SEARCH RETURN () FLAGGED
159 SINCE 1-Feb-1994 NOT FROM "Smith"
160 S: * ESEARCH (TAG "A283") ALL 2,10:11
161 S: A283 OK SEARCH completed
163 The following example demonstrates finding the first unseen message
164 as returned in the UNSEEN response code on a successful SELECT
165 command:
170 Melnikov & Cridland Standards Track [Page 3]
172 RFC 4731 IMAP4 Extension to SEARCH November 2006
175 Example: C: A284 SEARCH RETURN (MIN) UNSEEN
176 S: * ESEARCH (TAG "A284") MIN 4
177 S: A284 OK SEARCH completed
179 The following example demonstrates that if the ESEARCH UID indicator
180 is present, all data in the ESEARCH response is referring to UIDs;
181 for example, the MIN result specifier will be followed by a UID.
183 Example: C: A285 UID SEARCH RETURN (MIN MAX) 1:5000
184 S: * ESEARCH (TAG "A285") UID MIN 7 MAX 3800
185 S: A285 OK SEARCH completed
187 The following example demonstrates returning the number of deleted
188 messages:
190 Example: C: A286 SEARCH RETURN (COUNT) DELETED
191 S: * ESEARCH (TAG "A286") COUNT 15
192 S: A286 OK SEARCH completed
194 3.2. Interaction with CONDSTORE extension
196 When the server supports both the ESEARCH and the CONDSTORE
197 [CONDSTORE] extension, and the client requests one or more result
198 option described in section 3.1 together with the MODSEQ search
199 criterion in the same SEARCH/UID SEARCH command, then the server MUST
200 return the ESEARCH response containing the MODSEQ result option
201 (described in the following paragraph) instead of the extended SEARCH
202 response described in section 3.5 of [CONDSTORE].
204 If the SEARCH/UID SEARCH command contained a single MIN or MAX result
205 option, the MODSEQ result option contains the mod-sequence for the
206 found message. If the SEARCH/UID SEARCH command contained both MIN
207 and MAX result options and no ALL/COUNT option, the MODSEQ result
208 option contains the highest mod-sequence for the two returned
209 messages. Otherwise the MODSEQ result option contains the highest
210 mod-sequence for all messages being returned.
212 Example: The following example demonstrates how Example 15 from
213 [CONDSTORE] would look in the presence of one or more result option:
215 C: a1 SEARCH RETURN (MIN) MODSEQ "/flags/\\draft"
216 all 620162338
217 S: * ESEARCH (TAG "a1") MIN 2 MODSEQ 917162488
218 S: a1 OK Search complete
220 C: a2 SEARCH RETURN (MAX) MODSEQ "/flags/\\draft"
221 all 620162338
222 S: * ESEARCH (TAG "a2") MAX 23 MODSEQ 907162321
226 Melnikov & Cridland Standards Track [Page 4]
228 RFC 4731 IMAP4 Extension to SEARCH November 2006
231 S: a2 OK Search complete
233 C: a3 SEARCH RETURN (MIN MAX) MODSEQ "/flags/\\draft"
234 all 620162338
235 S: * ESEARCH (TAG "a3") MIN 2 MAX 23 MODSEQ 917162488
236 S: a3 OK Search complete
238 C: a4 SEARCH RETURN (MIN COUNT) MODSEQ "/flags/\\draft"
239 all 620162338
240 S: * ESEARCH (TAG "a4") MIN 2 COUNT 10 MODSEQ 917162500
241 S: a4 OK Search complete
243 4. Formal Syntax
245 The following syntax specification uses the Augmented Backus-Naur
246 Form (ABNF) notation as specified in [ABNF].
248 Non-terminals referenced but not defined below are as defined by
249 [IMAP4], [CONDSTORE], or [IMAPABNF].
251 Except as noted otherwise, all alphabetic characters are case-
252 insensitive. The use of upper or lowercase characters to define
253 token strings is for editorial clarity only. Implementations MUST
254 accept these strings in a case-insensitive fashion.
256 capability =/ "ESEARCH"
258 search-return-data = "MIN" SP nz-number /
259 "MAX" SP nz-number /
260 "ALL" SP sequence-set /
261 "COUNT" SP number
262 ;; conforms to the generic
263 ;; search-return-data syntax defined
264 ;; in [IMAPABNF]
266 search-return-opt = "MIN" / "MAX" / "ALL" / "COUNT"
267 ;; conforms to generic search-return-opt
268 ;; syntax defined in [IMAPABNF]
270 When the CONDSTORE [CONDSTORE] IMAP extension is also supported,
271 the ABNF is updated as follows:
273 search-return-data =/ "MODSEQ" SP mod-sequence-value
274 ;; mod-sequence-value is defined
275 ;; in [CONDSTORE]
282 Melnikov & Cridland Standards Track [Page 5]
284 RFC 4731 IMAP4 Extension to SEARCH November 2006
287 5. Security Considerations
289 In the general case, the IMAP SEARCH/UID SEARCH commands can be CPU
290 and/or IO intensive, and are seen by some as a potential attack point
291 for denial of service attacks, so some sites/implementations even
292 disable them entirely. This is quite unfortunate, as SEARCH command
293 is one of the best examples demonstrating IMAP advantage over POP3.
295 The ALL and COUNT return options don't change how SEARCH is working
296 internally; they only change how information about found messages is
297 returned. MIN and MAX SEARCH result options described in this
298 document can lighten the load on IMAP servers that choose to optimize
299 SEARCHes containing only one or both of them.
301 It is believed that this extension doesn't raise any additional
302 security concerns not already discussed in [IMAP4].
304 6. IANA Considerations
306 IMAP4 capabilities are registered by publishing a standards track RFC
307 or an IESG-approved experimental RFC. The registry is currently
308 located at <http://www.iana.org/assignments/imap4-capabilities>.
310 This document defines the ESEARCH IMAP capability, which IANA added
311 to the registry.
313 7. Normative References
315 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
316 Requirement Levels", BCP 14, RFC 2119, March 1997.
318 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
319 4rev1", RFC 3501, March 2003.
321 [ABNF] Crocker, D. (Ed.) and P. Overell , "Augmented BNF for
322 Syntax Specifications: ABNF", RFC 4234, October 2005.
324 [IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
325 ABNF", RFC 4466, April 2006..
327 [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
328 STORE", RFC 4551, June 2006.
330 8. Acknowledgments
332 Thanks to Michael Wener, Arnt Gulbrandsen, Cyrus Daboo, Mark Crispin,
333 and Pete Maclean for comments and corrections.
338 Melnikov & Cridland Standards Track [Page 6]
340 RFC 4731 IMAP4 Extension to SEARCH November 2006
343 Authors' Addresses
345 Alexey Melnikov
346 Isode Limited
347 5 Castle Business Village
348 36 Station Road
349 Hampton, Middlesex, TW12 2BX
350 UK
352 EMail: Alexey.Melnikov@isode.com
355 Dave A. Cridland
356 Inventure Systems Limited
358 EMail: dave.cridland@inventuresystems.co.uk
359 URL: http://invsys.co.uk/dave/
394 Melnikov & Cridland Standards Track [Page 7]
396 RFC 4731 IMAP4 Extension to SEARCH November 2006
399 Full Copyright Statement
401 Copyright (C) The IETF Trust (2006).
403 This document is subject to the rights, licenses and restrictions
404 contained in BCP 78, and except as set forth therein, the authors
405 retain all their rights.
407 This document and the information contained herein are provided on an
408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
410 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
411 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
412 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
413 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
414 PURPOSE.
416 Intellectual Property
418 The IETF takes no position regarding the validity or scope of any
419 Intellectual Property Rights or other rights that might be claimed to
420 pertain to the implementation or use of the technology described in
421 this document or the extent to which any license under such rights
422 might or might not be available; nor does it represent that it has
423 made any independent effort to identify any such rights. Information
424 on the procedures with respect to rights in RFC documents can be
425 found in BCP 78 and BCP 79.
427 Copies of IPR disclosures made to the IETF Secretariat and any
428 assurances of licenses to be made available, or the result of an
429 attempt made to obtain a general license or permission for the use of
430 such proprietary rights by implementers or users of this
431 specification can be obtained from the IETF on-line IPR repository at
432 http://www.ietf.org/ipr.
434 The IETF invites any interested party to bring to its attention any
435 copyrights, patents or patent applications, or other proprietary
436 rights that may cover technology that may be required to implement
437 this standard. Please address the information to the IETF at
438 ietf-ipr@ietf.org.
440 Acknowledgement
442 Funding for the RFC Editor function is currently provided by the
443 Internet Society.
450 Melnikov & Cridland Standards Track [Page 8]