idnits 2.17.1 draft-cridland-imap-context-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 785. 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 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 17, 2008) is 5853 days in the past. Is this intentional? 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 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Cridland 3 Internet-Draft C. King 4 Intended status: Standards Track Isode Limited 5 Expires: October 19, 2008 April 17, 2008 7 Contexts for IMAP4 8 draft-cridland-imap-context-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 19, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 The IMAP4rev1 protocol has powerful search facilities as part of the 42 core protocol, but lacks the ability to create live, updated results 43 which can be easily handled. This memo provides such an extension, 44 and shows how it can be used to provide a facility similar to virtual 45 mailboxes. 47 Table of Contents 49 1. Conventions used in this document . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Extended Sort Syntax . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. ESORT extension . . . . . . . . . . . . . . . . . . . . . 4 53 3.2. Ranges in Extended Sort results . . . . . . . . . . . . . 4 54 3.3. Extended SORT example . . . . . . . . . . . . . . . . . . 5 55 4. Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. Context Hint . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.3. Notifications of changes . . . . . . . . . . . . . . . . . 6 59 4.3.1. Refusing to update contexts . . . . . . . . . . . . . 7 60 4.3.2. Common Features of ADDTO and REMOVEFROM . . . . . . . 8 61 4.3.3. ADDTO Return Data Item . . . . . . . . . . . . . . . . 8 62 4.3.4. REMOVEFROM Return Data Item . . . . . . . . . . . . . 9 63 4.3.5. The CANCELUPDATE command . . . . . . . . . . . . . . . 10 64 4.4. Partial results . . . . . . . . . . . . . . . . . . . . . 10 65 4.5. Caching results . . . . . . . . . . . . . . . . . . . . . 11 66 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 73 Appendix A. Cookbook . . . . . . . . . . . . . . . . . . . . . . 15 74 A.1. Virtual Mailboxes . . . . . . . . . . . . . . . . . . . . 15 75 A.2. Trash Mailboxes . . . . . . . . . . . . . . . . . . . . . 15 76 A.3. Immediate EXPUNGE notifications . . . . . . . . . . . . . 15 77 A.4. Monitoring counts . . . . . . . . . . . . . . . . . . . . 15 78 A.5. Resynchronizing Contexts . . . . . . . . . . . . . . . . . 15 79 Appendix B. Server Implementation Notes . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 81 Intellectual Property and Copyright Statements . . . . . . . . . . 18 83 1. Conventions used in this document 85 In examples, "C:" and "S:" indicate lines sent by the client 86 messaging user agent and IMAP4rev1 ([IMAP]) server respectively. "//" 87 indicates inline comments not part of the protocol exchange. Line 88 breaks are liberally inserted for clarity. Examples are intended to 89 be read in order, such that the state remains from one example to the 90 next. 92 Although the examples show a server which supports [ESEARCH], this is 93 not a strict requirement of this specification. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [KEYWORDS]. 99 Other capitalised words are typically names of IMAP extensions or 100 commands - these are uppercased for clarity only, and are case- 101 insensitive. 103 2. Introduction 105 Although the basic SEARCH command defined in [IMAP], and as enhanced 106 by [ESEARCH], is relatively compact in its representation, this 107 reduction saves only a certain amount of data, and huge mailboxes 108 might overwhelm the storage available for results on even relatively 109 high-end desktop machines. 111 The SORT command, defined in [SORT] provides useful features, but is 112 hard to use effectively on changing mailboxes over low-bandwidth 113 connections. 115 This memo borrows concepts from [ACAP], providing a windowed view 116 onto search or sort results, as well as bandwidth and round-trip 117 efficient updates, by providing two extensions, known as "ESORT" and 118 "CONTEXT". 120 3. Extended Sort Syntax 122 Servers implementing the extended SORT provide a suite of extensions 123 to the SORT and UID SORT commands defined in [SORT]. This allows for 124 return options, as used with SEARCH and specified in [IMAP-ABNF], to 125 be used with SORT in a similar manner. 127 The SORT and UID SORT commands are extended by the addition of an 128 optional list of return options which follow a RETURN atom 129 immediately after the command. If this is missing, the server will 130 return results as specified in [SORT]. 132 The extended SORT command always returns results in the requested 133 sort order, but is otherwise identical in its behaviour to the 134 extended SEARCH command defined in [IMAP-ABNF], as extended by 135 [ESEARCH]. In particular, the extended SORT command returns results 136 in an ESEARCH response. 138 3.1. ESORT extension 140 Servers advertising the capability "ESORT" support the return options 141 specified in [ESEARCH], adapted as follows: 142 MIN 143 Return the message number/UID of the lowest sorted message 144 satisfying the search criteria. 146 MAX 147 Return the message number/UID of the highest sorted message 148 satisfying the search criteria. 150 ALL 151 Return all message numbers/UIDs which match the search criteria, 152 in the requested sort order, using a sequence-set. Note the use 153 of ranges described below in Section 3.2. 155 COUNT 156 As [ESEARCH]. 158 3.2. Ranges in Extended Sort results 160 Any ranges given by the server, including those given as part of the 161 sequence-set, in an ESEARCH response resulting from an extended SORT 162 or UID SORT command MUST be ordered in increasing numerical order 163 after expansion, as per usual [IMAP] rules. 165 In particular this means that 10:12 is equivalent to 12:10, and 166 10,11,12. To avoid confusion, servers SHOULD present ranges only 167 when the first seq-number is lower than the second; that is, either 168 of the forms 10:12 or 10,11,12 is acceptable, but 12:10 SHOULD be 169 avoided. 171 3.3. Extended SORT example 173 If the list of return options is present but empty, then the server 174 provides the ALL return data item in an ESEARCH response. This is 175 functionally equivalent to an unextended UID SORT command, but can 176 use a smaller representation: 178 C: E01 UID SORT RETURN () (REVERSE DATE) UTF-8 UNDELETED 179 UNKEYWORD $Junk 180 S: * ESEARCH (TAG "E01") UID ALL 23765,23764,23763,23761,[...] 181 S: E01 OK Sort completed 183 Note that the initial three results are not represented as the range 184 23765:23763 as mandated in Section 3.2. 186 4. Contexts 188 4.1. Overview 190 The Contexts extension is present in any IMAP4rev1 server which 191 includes the string "CONTEXT=SEARCH", and/or "CONTEXT=SORT", within 192 its advertised capabilities. 194 In the case of CONTEXT=SEARCH, the server supports the extended 195 SEARCH command syntax described in [IMAP-ABNF], and accepts three new 196 return options. 198 Servers advertising CONTEXT=SORT also advertise the SORT capability, 199 as described in [SORT], support the extended SORT command syntax 200 described in Section 3, and accept in addition three new return 201 options for this extended SORT. 203 These allow for notifications of changes to the results of SEARCH or 204 SORT commands, and also allow for access to partial results. 206 A server advertising the CONTEXT=SEARCH extension will order all 207 SEARCH results, whether from a UID SEARCH or SEARCH command, in 208 mailbox order - that is, by message number and UID. Therefore, the 209 UID SEARCH, SEARCH, UID SORT, or SORT command used - collectively 210 known as the searching command - will always have an order, the 211 requested order, which will be the mailbox order for UID SEARCH and 212 SEARCH commands. 214 All of the return specifiers have no interaction with either each 215 other or any return specifiers defined in [ESEARCH] or Section 3.1, 216 however it is believed that implementations supporting CONTEXT will 217 also support ESEARCH and ESORT. 219 4.2. Context Hint 221 The return option CONTEXT SHOULD be used by a client to indicate that 222 subsequent use of the search criteria are likely. Servers MAY ignore 223 this return option, or use it as a hint to maintain a full result 224 cache, or index. 226 A client might choose to obtain a count of matching messages prior to 227 obtaining actual results. Here, the client signals its intention to 228 fetch the results themselves: 230 C: A01 SEARCH RETURN (CONTEXT COUNT) UNDELETED 231 UNKEYWORD $Junk 232 S: * ESEARCH (TAG "A01") COUNT 23765 233 S: A01 OK Search completed. 235 4.3. Notifications of changes 237 The search return option UPDATE, if used by a client, causes the 238 server to issue unsolicited notifications containing updates to the 239 results which would be returned by an unmodified searching command. 240 These update sets are carried in ADDTO and REMOVEFROM data items in 241 ESEARCH/ESORT responses. 243 These ESEARCH responses carry a search correlator of the searching 244 command, hence clients MUST NOT reuse tags, as already specified in 245 Section 2.2.1 of [IMAP]. An attempt to use UPDATE where a tag is 246 already in use with a previous searching command which itself used 247 UPDATE SHALL result in the server rejecting the searching command 248 with a BAD response. 250 Both ADDTO and REMOVEFROM data items SHOULD be delivered to clients 251 in a timely manner, as and when results change, whether by new 252 messages arriving in the mailbox, metadata such as flags being 253 changed, or messages being expunged. 255 Typically, this would occur at the same time as the FETCH, EXISTS or 256 EXPUNGE responses carrying the source of the change. 258 Updates will cease only when the mailbox is no longer selected, or 259 when the CANCELUPDATE command, defined in Section 4.3.5, is issued by 260 the client, whichever is sooner. 262 Unlike [ACAP], there is no requirement that a context need be created 263 with CONTEXT to use UPDATE, and in addition, the lack of UPDATE with 264 a CONTEXT does not affect the results caused by later searching 265 commands - there is no snapshot facility. 267 There is no interaction between UPDATE and any other return options; 268 therefore use of RETURN (UPDATE MIN), for example, does not notify 269 about the minimum UID or sequence number, but notifies instead about 270 all changes to the set of matching messages. In particular, this 271 means that a client using UPDATE and PARTIAL on the same search 272 program could receive notifications about messages which do not 273 currently interest it. 275 This time, the client will require notifications of updates, and 276 chooses to obtain a count: 278 C: B01 UID SEARCH RETURN (UPDATE COUNT) DELETED 279 KEYWORD $Junk 280 S: * ESEARCH (TAG "B01") COUNT 74 281 S: B01 OK Search completed, will notify. 282 // Note that the following is rejected, and has no effect: 283 C: B01 SORT RETURN (UPDATE) FLAGGED 284 S: B01 BAD Tag reuse 286 4.3.1. Refusing to update contexts 288 In some cases, the server MAY refuse to provide updates, such as if 289 an internal limit on the number of update contexts is reached. In 290 such a case, an untagged NO is generated during processing of the 291 command with a response-code of NOUPDATE. The response-code 292 contains, as argument, the tag of the search command for which the 293 server is refusing to honour the UPDATE request. 295 Other return options specified SHALL still be honoured. 297 Servers MUST provide at least one updating context per client, and 298 SHOULD provide more - see Appendix B for strategies on reducing the 299 impact of additional updating contexts. Since sorted contexts 300 require a higher implementation cost than unsorted contexts, refusal 301 to provide updates for a SORT command does not imply that SEARCH 302 contexts will also be refused. 304 This time, the client will require notifications of updates, and 305 chooses to obtain a count: 307 C: B02 UID SORT RETURN (UPDATE COUNT) UTF-8 308 KEYWORD $Junk 309 S: * ESEARCH (TAG "B02") COUNT 74 310 S: * NO [NOUPDATE "B02"] Too many contexts 311 S: B02 OK Search completed, will not notify. 313 Client handling might be to retry with a UID SEARCH command, or else 314 cancel an existing context; see Section 4.3.5. 316 4.3.2. Common Features of ADDTO and REMOVEFROM 318 The result update set included in the return data item is specified 319 as UIDs or message numbers, depending on how the UPDATE was 320 specified. If the UPDATE was present in a SEARCH or SORT command, 321 the results will be message numbers; in a UID SEARCH or UID SORT 322 command, they will be UIDs. 324 The client MUST process ADDTO and REMOVEFROM return data items in the 325 order they appear, including those within a single ESEARCH response. 326 Correspondingly, servers MUST generate ADDTO and REMOVEFROM responses 327 such that the results are maintained in the requested order. 329 As with any response aside from EXPUNGE, ESEARCH responses carrying 330 ADDTO and/or REMOVEFROM return data items MAY be sent at any time. 331 In particular, servers MAY send such responses when no command is in 332 progress, during the processing of any command, or when the client is 333 using the IDLE facility described in [IDLE]. Implementors are 334 recommended to read [NOTIFY] as a mechanism for clients to signal 335 servers that they are willing to process responses at any time, and 336 are also recommended to pay close attention to Section 5.3 of [IMAP]. 338 It is anticipated that typical server implementations will emit ADDTO 339 when they normally emit the causal FETCH or EXISTS, and similarly 340 emit REMOVEFROM when they normally emit the causal FETCH or EXPUNGE. 342 4.3.3. ADDTO Return Data Item 344 The ADDTO return data item contains, as payload, a list containing 345 pairs of a context position and a set of result updates in the 346 requested order to be inserted at the context position. Where the 347 searching command is a SEARCH or UID SEARCH command, the context 348 position MAY be zero. Each pair is processed in the order that it 349 appears. 351 If the context position is non-zero, the result update is inserted at 352 the given context position, meaning that the first result in the set 353 will occupy the new context position after insertion, and any prior 354 existing result at that context position will be shifted to a later 355 context position. 357 Where the context position is zero, the client MAY insert the message 358 numbers or UIDs in the result list such that the result list is 359 maintained in mailbox order. In this case, servers are RECOMMENDED 360 to order the result update into mailbox order to produce the shortest 361 representation in set-syntax. 363 [...] 364 S: * 23762 FETCH (FLAGS (\Deleted \Seen)) 365 S: * 23763 FETCH (FLAGS ($Junk \Seen)) 366 S: * ESEARCH (TAG "B01") UID ADDTO (0 32768:32769) 368 Note that this example assumes messages 23762 and 23763 with UIDs 369 32768 and 32769 respectively previously had neither \Deleted nor 370 $Junk set. Also note that only the ADDTO is included, and not the 371 (now changed) COUNT. 373 If the searching command "C01" initially generated a result list of 374 2734:2735, then the following three responses are equivalent, and 375 yield a result list of 2731:2735: 377 [...] 378 S: * ESEARCH (TAG "C01") UID ADDTO (1 2733 1 2732 1 2731) 379 S: * ESEARCH (TAG "C01") UID ADDTO (1 2733) ADDTO (1 2731:2732) 380 S: * ESEARCH (TAG "C01") UID ADDTO (1 2731:2733) 382 The last is the preferred representation. 384 4.3.4. REMOVEFROM Return Data Item 386 The REMOVEFROM return data item contains, as payload, a list 387 containing pairs of a context position and a set of result updates in 388 the requested order to be removed starting from the context position. 389 Where the searching command is a SEARCH or UID SEARCH command, the 390 context position MAY be zero. Each pair is processed in the order 391 that it appears. 393 If the context position is non-zero, the results are removed at the 394 given context position, meaning that the first result in the set will 395 occupy the given context position before removal, and any prior 396 existing result at that context position will be shifted to an 397 earlier context position. 399 Where the context position is zero, the client removes the message 400 numbers or UIDs in the result list wherever they occur, and servers 401 are RECOMMENDED to order the result list in mailbox order to obtain 402 the best benefit from the set-syntax. 404 Note that a REMOVEFROM containing message sequence numbers removed as 405 a result of those messages being expunged MUST be sent prior to the 406 expunge notification itself, in order that those sequence numbers 407 remain valid. 409 Here, a message in the result list is expunged. The REMOVEFROM here 410 is shown to happen without any command in progress, see 411 Section 4.3.2. Note that EXPUNGE responses do not have this 412 property. 414 [...] 415 S: * ESEARCH (TAG "B01") UID REMOVEFROM (0 32768) 416 C: B03 NOOP 417 S: * 23762 EXPUNGE 418 S: B03 OK Nothing done. 420 4.3.5. The CANCELUPDATE command 422 When a client no longer wishes to receive updates, it may issue the 423 CANCELUPDATE command, which will prevent all updates to the contexts 424 named in the arguments from being transmitted by the server. The 425 command takes, as arguments, one or more tags of the commands used to 426 request updates. 428 The server MAY free any resource associated with a context so 429 disabled - however the client is free to issue further searching 430 commands with the same criteria and requested order, including 431 PARTIAL requests. 433 C: B04 CANCELUPDATE "B01" 434 S: B04 OK No further updates. 436 4.4. Partial results 438 The PARTIAL search return option causes the server to provide in an 439 ESEARCH response a subset of the results denoted by the sequence 440 range given as the mandatory argument. The first result is 1, thus 441 the first 500 results would be obtained by a return option of 442 "PARTIAL 1:500", and the second 500 by "PARTIAL 501:1000". This 443 intentionally mirrors message sequence numbers. 445 A single command MUST NOT contain more than one PARTIAL or ALL search 446 return option - that is, either one PARTIAL, one ALL, or neither of 447 PARTIAL or ALL is allowed. 449 For SEARCH results, the entire result list MUST be ordered in mailbox 450 order, that is, in UID or message sequence number order. 452 Where a PARTIAL search return option references results which do not 453 exist, by using a range which starts or ends higher than the current 454 number of results, then the server returns those results which are in 455 the set. This yields a PARTIAL return data item which has, as 456 payload, the original range and a potentially missing set of results 457 which may be shorter than the extent of the range. 459 Clients need not request PARTIAL results in any particular order. 460 Because mailboxes may change, clients will often wish to use PARTIAL 461 in combination with UPDATE, especially if the intent is to walk a 462 large set of results; however these return options do not interact - 463 the UPDATE will provide notifications for all matching results. 465 // Recall from A01 that there are 23764 results. 466 C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED 467 UNKEYWORD $Junk 468 C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED 469 UNKEYWORD $Junk 470 C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED 471 UNKEYWORD $Junk 472 S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...) 473 // 264 results in set syntax elided, 474 // this spans the end of the results. 475 S: A02 OK Completed. 476 S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...) 477 // 500 results in set syntax elided. 478 S: A03 OK Completed. 479 S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL) 480 // No results are present, this is beyond the end of the results. 481 S: A04 OK Completed. 483 4.5. Caching results 485 Server implementations MAY cache results from a search or sort, 486 whether or not hinted to by CONTEXT, in order to make subsequent 487 searches more efficient, perhaps by recommencing a subsequent PARTIAL 488 search where a previous search left off. However servers MUST behave 489 identically whether or not internal caching is taking place, 490 therefore any such cache is required to be updated as changes to the 491 mailbox occur. An alternate strategy would be to discard results 492 when any change occurs to the mailbox. 494 5. Formal Syntax 496 The collected formal syntax. This uses ABNF as defined in [ABNF]. 497 It includes definitions from [IMAP], [IMAP-ABNF], and [SORT]. 499 capability =/ "CONTEXT=SEARCH" / "CONTEXT=SORT" / "ESORT" 500 ;; from [IMAP] 502 command-select =/ "CANCELUPDATE" 1*(SP quoted) 503 ;; from [IMAP] 505 context-position = number 506 ;; Context position may be 0 for SEARCH result additions. 507 ;; from [IMAP] 509 modifier-context = "CONTEXT" 511 modifier-partial = "PARTIAL" SP seq-range 512 ;; from [IMAP] 514 modifier-update = "UPDATE" 516 search-return-opt =/ modifier-context / modifier-partial / 517 modifier-update 518 ;; All conform to , from [IMAP-ABNF] 520 resp-text-code =/ "NOUPDATE" SP quoted 521 ;; from [IMAP] 523 ret-data-addto = "ADDTO" 524 SP "(" context-position SP sequence-set 525 *(SP context-position SP sequence-set) 526 ")" 527 ;; from [IMAP] 529 ret-data-partial = "PARTIAL" 530 SP "(" seq-range SP partial-results ")" 531 ;; is the requested range. 532 ;; from [IMAP] 534 partial-results = sequence-set / "NIL" 535 ;; from [IMAP] 536 ;; NIL indicates no results correspond to the requested range. 538 ret-data-removefrom = "REMOVEFROM" 539 SP "(" context-position SP sequence-set 540 *(SP context-position SP sequence-set) 541 ")" 542 ;; from [IMAP] 544 search-return-data =/ ret-data-partial / ret-data-addto / 545 ret-data-removefrom 546 ;; All conform to , from [IMAP-ABNF] 548 sort =/ extended-sort 549 ;; from [SORT] 551 extended-sort = ["UID" SP] "SORT" search-return-opts 552 SP sort-criteria SP search-criteria 553 ;; from [IMAP-ABNF] 554 ;; and from [SORT] 556 6. Security Considerations 558 This document defines additional IMAP4 capabilities. As such, it 559 does not change the underlying security considerations of [IMAP]. 560 The authors and reviewers believe that no new security issues are 561 introduced with these additional IMAP4 capabilities. 563 Creation of a large number of contexts may provide an avenue for 564 denial of service attacks by authorized users. Implementors may 565 reduce this by limiting the numbers of contexts possible to create, 566 via the protocol features described in Section 4.3.1; by reducing the 567 impact of contexts by the implementation strategies described in 568 Appendix B; and by logging context creation and usage so that 569 administrative remedies may be applied. 571 7. IANA Considerations 573 IMAP4 capabilities are registered by publishing a standards track or 574 IESG approved experimental RFC. The registry is currently located 575 at: 577 http://www.iana.org/assignments/imap4-capabilities 579 This document defines the ESORT, CONTEXT=SEARCH, and CONTEXT=SORT 580 IMAP capabilities. IANA is requested to add them to the registry 581 accordingly. 583 8. Acknowledgements 585 Much of the design of this extension can be found in ACAP. Valuable 586 comments, both in agreement and in dissent, were received from Alexey 587 Melnikov, Arnt Gulbrandsen, Cyrus Daboo, Filip Navara, Mark Crispin, 588 Peter Coates, Philip Van Hoof, Randall Gellens, Timo Sirainen, Zoltan 589 Ordogh and others, and many of these comments have had significant 590 influence on the design or the text. The authors are grateful to all 591 those involved, including those not mentioned here. 593 9. References 595 9.1. Normative References 597 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 598 Specifications: ABNF", RFC 4234, October 2005. 600 [ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH 601 Command for Controlling What Kind of Information Is 602 Returned", RFC 4731, November 2006. 604 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 605 4rev1", RFC 3501, March 2003. 607 [IMAP-ABNF] 608 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 609 ABNF", RFC 4466, April 2006. 611 [KEYWORDS] 612 Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 616 PROTOCOL - SORT AND THREAD EXTENSIONS", 617 draft-ietf-imapext-sort-20 (work in progress), March 2008. 619 9.2. Informative References 621 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 622 Configuration Access Protocol", RFC 2244, November 1997. 624 [IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 626 [NOTIFY] King, C., "The IMAP NOTIFY Extension", 627 draft-gulbrandsen-imap-notify-07 (work in progress), 628 July 2007. 630 Appendix A. Cookbook 632 A.1. Virtual Mailboxes 634 It is possible to use the facilities described within this memo to 635 create a facility largely similar to a virtual mailbox, but handled 636 on the client side. 638 Initially, the client SELECTs the real "backing" mailbox. Next, it 639 can switch to a filtered view at any time by issuing a RETURN (COUNT 640 UPDATE CONTEXT), and using RETURN (PARTIAL x:y) as the user scrolls, 641 feeding the results into a FETCH as required to populate summary 642 views. 644 A typically useful view is UID SORT (DATE) RETURN (...) UTF-8 UNSEEN 645 UNDELETED, which can be used to show the mailbox sorted into 646 INTERNALDATE order, filtered to only show messages which are unread 647 and not yet deleted. 649 A.2. Trash Mailboxes 651 Certain contexts are particularly useful for client developers 652 wishing to present something similar to the common trash mailbox 653 metaphor in limited bandwidth. The simple criteria of UNDELETED only 654 matches undeleted messages, and the corresponding DELETED search key 655 can be used to display a per-mailbox trash-like virtual mailbox. 657 A.3. Immediate EXPUNGE notifications 659 The command "SEARCH RETURN (UPDATE) ALL" can be used to create a 660 context which notifies immediately about expunged messages, yet will 661 not affect message sequence numbers until the normal EXPUNGE message 662 can be sent. This may be useful for clients wishing to show this 663 behaviour without losing the benefit of sequence numbering. 665 A.4. Monitoring counts 667 A client need not maintain any result cache at all, but instead 668 maintain a simple count of messages matching the search criteria. 669 Typically, this would use the SEARCH command, as opposed to UID 670 SEARCH, due to its smaller representation. Such usage might prove 671 useful in monitoring the number of flagged, but unanswered, messages, 672 for example, with "SEARCH RETURN (UPDATE COUNT) FLAGGED UNANSWERED". 674 A.5. Resynchronizing Contexts 676 The creation of a context, and immediate access to it, can all be 677 accomplished in a single round-trip. Therefore, whilst it is 678 possible to elide resynchronization if no changes have occurred, it 679 is simpler in most cases to resynchronize by simply recreating the 680 context. 682 Appendix B. Server Implementation Notes 684 Although a server may cache the results, this is not mandated nor 685 required, especially when the client uses SEARCH or UID SEARCH 686 commands. UPDATE processing, for example, can be achieved 687 efficiently by comparison of the old flag state (if any) and the new, 688 and PARTIAL can be achieved by re-running the search until the 689 suitable window is required. This is a result of there being no 690 snapshot facility. 692 For example, on a new message, the server can simply test for matches 693 against all current UPDATE context search programs, and for any that 694 match, send the ADDTO return data. 696 Similarly, for a flag change on an existing message, the server can 697 check whether the message matched with its old flags, whether it 698 matches with new flags, and provide ADDTO or REMOVEFROM return data 699 accordingly if these results differ. 701 For PARTIAL requests, the server can perform a full search, 702 discarding results until the lower bound is hit, and stopping the 703 search when sufficient results have been obtained. 705 With some additional state, it is possible to restart PARTIAL 706 searches, thus avoiding performing the initial discard phase. 708 For the best performance, however, caching the full search results is 709 needed, which can allow for faster responses at the expense of 710 memory. One reasonable strategy would be to balance this trade-off 711 at run-time, discarding search results after a suitable timeout, and 712 regenerating them as required. 714 This yields state requirements of storing the search program for any 715 UPDATE contexts, and optionally storing both search program and 716 (updated) results for further contexts as required. 718 Note that in the absence of a server-side results cache, it may be 719 impossible to know if an expunged message previously matched unless 720 the original message is still available. Therefore some 721 implementations may be forced into using a results cache in many 722 circumstances. 724 UPDATE contexts created with SORT or UID SORT will almost certainly 725 require some form of results caching, however. 727 Authors' Addresses 729 Dave Cridland 730 Isode Limited 731 5 Castle Business Village 732 36, Station Road 733 Hampton, Middlesex TW12 2BX 734 GB 736 Email: dave.cridland@isode.com 738 Curtis King 739 Isode Limited 740 5 Castle Business Village 741 36, Station Road 742 Hampton, Middlesex TW12 2BX 743 GB 745 Email: cking@mumbo.ca 747 Full Copyright Statement 749 Copyright (C) The IETF Trust (2008). 751 This document is subject to the rights, licenses and restrictions 752 contained in BCP 78, and except as set forth therein, the authors 753 retain all their rights. 755 This document and the information contained herein are provided on an 756 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 757 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 758 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 759 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 760 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 761 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 763 Intellectual Property 765 The IETF takes no position regarding the validity or scope of any 766 Intellectual Property Rights or other rights that might be claimed to 767 pertain to the implementation or use of the technology described in 768 this document or the extent to which any license under such rights 769 might or might not be available; nor does it represent that it has 770 made any independent effort to identify any such rights. Information 771 on the procedures with respect to rights in RFC documents can be 772 found in BCP 78 and BCP 79. 774 Copies of IPR disclosures made to the IETF Secretariat and any 775 assurances of licenses to be made available, or the result of an 776 attempt made to obtain a general license or permission for the use of 777 such proprietary rights by implementers or users of this 778 specification can be obtained from the IETF on-line IPR repository at 779 http://www.ietf.org/ipr. 781 The IETF invites any interested party to bring to its attention any 782 copyrights, patents or patent applications, or other proprietary 783 rights that may cover technology that may be required to implement 784 this standard. Please address the information to the IETF at 785 ietf-ipr@ietf.org. 787 Acknowledgment 789 Funding for the RFC Editor function is provided by the IETF 790 Administrative Support Activity (IASA).