idnits 2.17.1 draft-cridland-imap-context-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 787. 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 (June 20, 2007) is 6155 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) == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-18 == Outdated reference: A later version (-07) exists of draft-gulbrandsen-imap-notify-06 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 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: December 22, 2007 June 20, 2007 7 Contexts for IMAP4 8 draft-cridland-imap-context-03 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 December 22, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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 [[ Editorial comments are like this. XML2RFC working source is held 104 at http://svn.dave.cridland.net/svn/ietf-drafts/ 105 draft-cridland-imap-context.xml ]] 107 2. Introduction 109 Although the basic SEARCH command defined in [IMAP], and as enhanced 110 by [ESEARCH], is relatively compact in its representation, this 111 reduction saves only a certain amount of data, and huge mailboxes 112 might overwhelm the storage available for results on even relatively 113 high-end desktop machines. 115 The SORT command, defined in [SORT] provides useful features, but is 116 hard to use effectively on changing mailboxes over low-bandwidth 117 connections. 119 This memo borrows concepts from [ACAP], providing a windowed view 120 onto search or sort results, as well as bandwidth and round-trip 121 efficient updates, by providing two extensions, known as "ESORT" and 122 "CONTEXT". 124 3. Extended Sort Syntax 126 Servers implementing the extended SORT provide a suite of extensions 127 to the SORT and UID SORT commands defined in [SORT]. This allows for 128 return options, as used with SEARCH and specified in [IMAP-ABNF], to 129 be used with SORT in a similar manner. 131 The SORT and UID SORT commands are extended by the addition of an 132 optional list of return options which follow a RETURN atom 133 immediately after the command. If this is missing, the server will 134 return results as specified in [SORT]. 136 The extended SORT command always returns results in the requested 137 sort order, but is otherwise identical in its behaviour to the 138 extended SEARCH command defined in [IMAP-ABNF], as extended by 139 [ESEARCH]. In particular, the extended SORT command returns results 140 in an ESEARCH response. 142 3.1. ESORT extension 144 Servers advertising the capability "ESORT" support the return options 145 specified in [ESEARCH], adapted as follows: 146 MIN 147 Return the message number/UID of the lowest sorted message 148 satisfying the search criteria. 150 MAX 151 Return the message number/UID of the highest sorted message 152 satisfying the search criteria. 154 ALL 155 Return all message numbers/UIDs which match the search criteria, 156 in the requested sort order, using a sequence-set. Note the use 157 of ranges described below in Section 3.2. 159 COUNT 160 As [ESEARCH]. 162 3.2. Ranges in Extended Sort results 164 Any ranges given by the server, including those given as part of the 165 sequence-set, in an ESEARCH response resulting from an extended SORT 166 or UID SORT command MUST be ordered in increasing numerical order 167 after expansion, as per usual [IMAP] rules. 169 In particular this means that 10:12 is equivalent to 12:10, and 170 10,11,12. To avoid confusion, servers SHOULD present ranges only 171 when the first seq-number is lower than the second; that is, either 172 of the forms 10:12 or 10,11,12 is acceptable, but 12:10 SHOULD be 173 avoided. 175 3.3. Extended SORT example 177 If the list of return options is present but empty, then the server 178 provides the ALL return data item in an ESEARCH response. This is 179 functionally equivalent to an unextended UID SORT command, but can 180 use a smaller representation: 182 C: E01 UID SORT RETURN () (REVERSE DATE) UTF-8 UNDELETED 183 UNKEYWORD $Junk 184 S: * ESEARCH (TAG "E01") UID ALL 23765,23764,23763,23761,[...] 185 S: E01 OK Sort completed 187 Note that the initial three results MUST NOT be represented as the 188 range 23765:23763. 190 4. Contexts 192 4.1. Overview 194 This extension is present in any IMAP4rev1 server which includes the 195 string "CONTEXT=SEARCH", and/or "CONTEXT=SORT", within its advertised 196 capabilities. 198 In the case of CONTEXT=SEARCH, the server supports the extended 199 SEARCH command syntax described in [IMAP-ABNF], and accepts three new 200 return options. 202 Servers advertising CONTEXT=SORT also advertise the SORT capability, 203 as described in [SORT], support the extended SORT command syntax 204 described in Section 3, and accept in addition three new return 205 options for this extended SORT. 207 These allow for notifications of changes to the results of SEARCH or 208 SORT commands, and also allow for access to partial results. 210 A server advertising the CONTEXT=SEARCH extension will order all 211 SEARCH results, whether from a UID SEARCH or SEARCH command, in 212 mailbox order - that is, by message number and UID. Therefore, the 213 UID SEARCH, SEARCH, UID SORT, or SORT command used - collectively 214 known as the searching command - will always have an order, the 215 requested order, which will be the mailbox order for UID SEARCH and 216 SEARCH commands. 218 All of the return specifiers have no interaction with either each 219 other or any return specifiers defined in [ESEARCH] or Section 3.1, 220 however it is believed that implementations supporting CONTEXT will 221 also support ESEARCH and ESORT. 223 4.2. Context Hint 225 The return option CONTEXT SHOULD be used by a client to indicate that 226 subsequent use of the search criteria are likely. Servers MAY ignore 227 this return option, or use it as a hint to maintain a full result 228 cache, or index. 230 A client might choose to obtain a count of matching messages prior to 231 obtaining actual results. Here, the client signals its intention to 232 fetch the results themselves: 234 C: A01 SEARCH RETURN (CONTEXT COUNT) UNDELETED 235 UNKEYWORD $Junk 236 S: * ESEARCH (TAG "A01") COUNT 23765 237 S: A01 OK Search completed. 239 4.3. Notifications of changes 241 The search return option UPDATE, if used by a client, causes the 242 server to issue unsolicited notifications containing updates to the 243 results which would be returned by an unmodified searching command. 244 These update sets are carried in ADDTO and REMOVEFROM data items in 245 ESEARCH/ESORT responses. 247 These ESEARCH responses carry a search correlator of the searching 248 command, hence clients MUST NOT reuse tags, as already specified in 249 Section 2.2.1 of [IMAP]. An attempt to use UPDATE where a tag is 250 already in use with a previous searching command which itself used 251 UPDATE SHALL result in the server rejecting the searching command 252 with a BAD response. 254 Both ADDTO and REMOVEFROM data items SHOULD be delivered to clients 255 in a timely manner, as and when results change, whether by new 256 messages arriving in the mailbox, metadata such as flags being 257 changed, or messages being expunged. 259 Typically, this would occur at the same time as the FETCH, EXISTS or 260 EXPUNGE responses carrying the source of the change. 262 Updates will cease only when the mailbox is no longer selected, or 263 when the CANCELUPDATE command, defined in Section 4.3.5, is issued by 264 the client, whichever is sooner. 266 Unlike [ACAP], there is no requirement that a context need be created 267 with CONTEXT to use UPDATE, and in addition, the lack of UPDATE with 268 a CONTEXT does not affect the results caused by later searching 269 commands - there is no snapshot facility. 271 There is no interaction between UPDATE and any other return options; 272 therefore use of RETURN (UPDATE MIN), for example, does not notify 273 about the minimum UID or sequence number, but notifies instead about 274 all changes to the set of matching messages. 276 In particular, this means that a client using UPDATE and PARTIAL on 277 the same search program MAY receive notifications about messages 278 which do not currently interest it. 280 This time, the client will require notifications of updates, and 281 chooses to obtain a count: 283 C: B01 UID SEARCH RETURN (UPDATE COUNT) DELETED 284 KEYWORD $Junk 285 S: * ESEARCH (TAG "B01") COUNT 74 286 S: B01 OK Search completed, will notify. 287 // Note that the following is rejected, and has no effect: 288 C: B01 SORT RETURN (UPDATE) FLAGGED 289 S: B01 BAD Tag reuse 291 4.3.1. Refusing to update contexts 293 In some cases, the server MAY refuse to provide updates, such as if 294 an internal limit on the number of update contexts is reached. 296 In this case, an untagged NO is generated during processing of the 297 command with a response-code of NOUPDATE. The response-code 298 contains, as argument, the tag of the search command for which the 299 server is refusing to honour the UPDATE request. 301 Other return options specified will still be honoured. 303 Servers MUST provide at least one updating context per client, and 304 SHOULD provide more - see Appendix B for strategies on reducing the 305 impact of additional updating contexts. Since sorted contexts 306 require a higher implementation cost than unsorted contexts, refusal 307 to provide updates for a SORT command does not imply that SEARCH 308 contexts will also be refused. 310 This time, the client will require notifications of updates, and 311 chooses to obtain a count: 313 C: B02 UID SORT RETURN (UPDATE COUNT) $Junk 314 KEYWORD $Junk 315 S: * ESEARCH (TAG "B02") COUNT 74 316 S: * NO [NOUPDATE "B02"] Too many contexts 317 S: B02 OK Search completed, will not notify. 319 Client handling might be to retry with a UID SEARCH command, or else 320 cancel an existing context; see Section 4.3.5. 322 4.3.2. Common Features of ADDTO and REMOVEFROM 324 The result update set included in the return data item is specified 325 as UIDs or message numbers, depending on how the UPDATE was 326 specified. If the UPDATE was present in a SEARCH or SORT command, 327 the results will be message numbers; in a UID SEARCH or UID SORT 328 command, they will be UIDs. 330 The client MUST process ADDTO and REMOVEFROM return data items in 331 order they appear, including those within a single ESEARCH response. 332 Correspondingly, servers MUST generate ADDTO and REMOVEFROM responses 333 such that the results are maintained in the requested order. 335 As with any response aside from EXPUNGE, ESEARCH responses carrying 336 ADDTO and/or REMOVEFROM return data items MAY be sent at any time. 337 In particular, servers MAY send such responses when no command is in 338 progress, during the processing of any command, or when the client is 339 using the IDLE facility described in [IDLE]. Implementors are 340 recommended to read [NOTIFY] as a mechanism for clients to signal 341 servers that they are willing to process responses at any time, and 342 are also recommended to pay close attention to Section 5.3 of [IMAP]. 344 It is expected that typical server implementations will emit ADDTO 345 when they normally emit the causal FETCH or EXISTS, and similarly 346 emit REMOVEFROM when they would normally emit the causal FETCH or 347 EXPUNGE. 349 4.3.3. ADDTO Return Data Item 351 The ADDTO return data item contains, as payload, a list containing 352 pairs of a position and a set of result updates in the requested 353 order to be inserted at the position. Where the searching command is 354 a SEARCH or UID SEARCH command, the position MAY be zero. Each pair 355 is processed in the order that it appears. 357 If the position is non-zero, the result update is inserted at the 358 given position, meaning that the first result in the set will occupy 359 the new position after insertion, and any prior existing result at 360 that position will be shifted to later positions. 362 Where the position is zero, the client MAY insert the message numbers 363 or UIDs in the result set such that the result set is maintained in 364 mailbox order. In this case, servers are RECOMMENDED to order the 365 result update into mailbox order to produce the shortest 366 representation in set-syntax. 368 [...] 369 S: * 23762 FETCH (FLAGS (\Deleted \Seen)) 370 S: * 23763 FETCH (FLAGS ($Junk \Seen)) 371 S: * ESEARCH (TAG "B01") UID ADDTO (0 32768:32769) 373 Note that this example assumes messages 23762 and 23763 with UIDs 374 32768 and 32769 respectively previously had neither \Deleted nor 375 $Junk set. Also note that only the ADDTO is included, and not the 376 (now changed) COUNT. 378 If the searching command "C01" initially generated a result set of 379 4:5, then the following three responses are equivalent, and yield a 380 result set of 1:5: 382 [...] 383 S: * ESEARCH (TAG "C01") UID ADDTO (1 3 1 2 1 1) 384 S: * ESEARCH (TAG "C01") UID ADDTO (1 3) ADDTO (1 1:2) 385 S: * ESEARCH (TAG "C01") UID ADDTO (1 1:3) 387 The last is the preferred representation. 389 4.3.4. REMOVEFROM Return Data Item 391 The REMOVEFROM return data item contains, as payload, a list 392 containing pairs of a position and a set of result updates in the 393 requested order to be removed starting from the position. Where the 394 searching command is a SEARCH or UID SEARCH command, the position MAY 395 be zero. Each pair is processed in the order that it appears. 397 If the position is non-zero, the results are removed at the given 398 position, meaning that the first result in the set will occupy the 399 given position before removal, and any prior existing result at that 400 position will be shifted to earlier positions. 402 Where the position is zero, the client removes the message numbers or 403 UIDs in the result set wherever they occur, and servers are 404 RECOMMENDED to order the result set in mailbox order to obtain the 405 best benefit from the set-syntax. 407 Note that a REMOVEFROM containing message sequence numbers removed as 408 a result of those messages being expunged MUST be sent prior to the 409 expunge notification itself, in order that those sequence numbers 410 remain valid. 412 Here, a message in the result set is expunged. The REMOVEFROM here 413 is shown to happen without any command in progress, see 414 Section 4.3.2. Note that EXPUNGE responses do not have this 415 property. 417 [...] 418 S: * ESEARCH (TAG "B01") UID REMOVEFROM (0 32768) 419 C: B03 NOOP 420 S: * 23762 EXPUNGE 421 S: B03 OK Nothing done. 423 4.3.5. The CANCELUPDATE command 425 When a client no longer wishes to receive updates, it may issue the 426 CANCELUPDATE command, which will prevent all updates to the contexts 427 named in the arguments from being transmitted by the server. The 428 command takes, as arguments, one or more tags of the commands used to 429 request updates. 431 The server MAY free any resource associated with a context so 432 disabled - however the client is free to issue further searching 433 commands with the same criteria and requested order, including 434 PARTIAL requests. 436 C: B04 CANCELUPDATE "B01" 437 S: B04 OK No further updates. 439 4.4. Partial results 441 The PARTIAL search return option causes the server to provide in an 442 ESEARCH response a subset of the results denoted by the sequence 443 range given as the mandatory argument. The first result is 1, thus 444 the first 500 results would be obtained by a return option of 445 "PARTIAL 1:500", and the second 500 by "PARTIAL 501:1000". This 446 intentionally mirrors message sequence numbers. 448 Only a single PARTIAL search return option may be present in a single 449 command. 451 For SEARCH results, the entire result set MUST be ordered in mailbox 452 order, that is, in UID or message sequence number order. 454 Where a PARTIAL search return option references results which do not 455 exist, by using a range which starts or ends higher than the current 456 number of results, then the server returns those results which are in 457 the set. This yields a PARTIAL return data item which has, as 458 payload, the original range and a potentially missing set of results 459 which may be shorter than the extent of the range. 461 Clients need not request PARTIAL results in any particular order. 462 Because mailboxes may change, clients will often wish to use PARTIAL 463 in combination with UPDATE, especially if the intent is to walk a 464 large set of results; however these return options do not interact - 465 the UPDATE will provide notifications for all matching results. 467 // Recall from A01 that there are 23764 results. 468 C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED 469 UNKEYWORD $Junk 470 C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED 471 UNKEYWORD $Junk 472 C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED 473 UNKEYWORD $Junk 474 S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...) 475 // 264 results in set syntax elided, 476 // this spans the end of the results. 477 S: A02 OK Completed. 478 S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...) 479 // 500 results in set syntax elided. 480 S: A03 OK Completed. 481 S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL) 482 // No results are present, this is beyond the end of the results. 483 S: A04 OK Completed. 485 4.5. Caching results 487 Server implementations MAY cache results from a search or sort, 488 whether or not hinted to by CONTEXT, in order to make subsequent 489 searches more efficient, perhaps by recommencing a subsequent PARTIAL 490 search where a previous search left off. However servers MUST behave 491 identically whether or not internal caching is taking place, 492 therefore any such cache is required to be updated as changes to the 493 mailbox occur. An alternate strategy would be to discard results 494 when any change occurs to the mailbox. 496 5. Formal Syntax 498 The collected formal syntax. This uses ABNF as defined in [ABNF]. 499 It includes definitions from [IMAP], [IMAP-ABNF], and [SORT]. 501 capability =/ "CONTEXT=SEARCH" / "CONTEXT=SORT" / "ESORT" 502 ;; from [IMAP] 504 command-select =/ "CANCELUPDATE" 1*(SP quoted) 505 ;; from [IMAP] 507 addto-position = number 508 ;; Number may be 0 for SEARCH result additions. 509 ;; from [IMAP] 511 modifier-context = "CONTEXT" 513 modifier-partial = "PARTIAL" SP seq-range 514 ;; from [IMAP] 516 modifier-update = "UPDATE" 518 search-return-opt =/ modifier-context / modifier-partial / 519 modifier-update 520 ;; All conform to , from [IMAP-ABNF] 522 resp-text-code =/ "NOUPDATE" SP quoted 523 ;; from [IMAP] 525 ret-data-addto = "ADDTO" 526 SP "(" addto-position SP sequence-set 527 *(SP addto-position SP sequence-set) 528 ")" 529 ;; from [IMAP] 531 ret-data-partial = "PARTIAL" 532 SP "(" seq-range SP partial-results ")" 533 ;; is the requested range. 534 ;; from [IMAP] 536 partial-results = sequence-set / "NIL" 537 ;; from [IMAP] 538 ;; NIL indicates no results correspond to the requested range. 540 ret-data-removefrom = "REMOVEFROM" 541 SP "(" addto-position SP sequence-set 542 *(SP addto-position SP sequence-set) 543 ")" 544 ;; from [IMAP] 546 search-return-data =/ ret-data-partial / ret-data-addto / 547 ret-data-removefrom 548 ;; All conform to , from [IMAP-ABNF] 550 sort =/ extended-sort 551 ;; from [SORT] 553 extended-sort = ["UID" SP] "SORT" search-return-opts 554 SP sort-criteria SP search-criteria 555 ;; from [IMAP-ABNF] 556 ;; and from [SORT] 558 6. Security Considerations 560 It is believed that this specification introduces no serious new 561 security considerations. However, implementors are advised to refer 562 to [IMAP]. 564 Creation of contexts, both for UPDATE and PARTIAL, can benefit from 565 storing potentially large result sets on the server. Implementors 566 are advised to take care not to provide a method for denial of 567 service (DoS) attacks based on this; the notes in Appendix B may aid 568 in implementation decisions. Note that a server avoiding storing the 569 results will have much increased I/O, which may also be an avenue for 570 DoS attacks. 572 7. IANA Considerations 574 IMAP4 capabilities are registered by publishing a standards track or 575 IESG approved experimental RFC. The registry is currently located 576 at: 578 http://www.iana.org/assignments/imap4-capabilities 580 This document defines the ESORT, CONTEXT=SEARCH, and CONTEXT=SORT 581 IMAP capabilities. IANA is requested to add them to the registry 582 accordingly. 584 8. Acknowledgements 586 Much of the design of this extension can be found in ACAP. Valuable 587 comments, both in agreement and in dissent, were received from Alexey 588 Melnikov, Arnt Gulbrandsen, Cyrus Daboo, Filip Navara, Mark Crispin, 589 Peter Coates, Philip Van Hoof, Randall Gellens, Timo Sirainen, Zoltan 590 Ordogh and others, and many of these comments have had significant 591 influence on the design or the text. The authors are grateful to all 592 those involved, including those not mentioned here. 594 9. References 596 9.1. Normative References 598 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 599 Specifications: ABNF", RFC 4234, October 2005. 601 [ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH 602 Command for Controlling What Kind of Information Is 603 Returned", RFC 4731, November 2006. 605 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 606 4rev1", RFC 3501, March 2003. 608 [IMAP-ABNF] 609 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 610 ABNF", RFC 4466, April 2006. 612 [KEYWORDS] 613 Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, March 1997. 616 [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 617 PROTOCOL - SORT AND THREAD EXTENSIONS", 618 draft-ietf-imapext-sort-18 (work in progress), 619 November 2006. 621 9.2. Informative References 623 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 624 Configuration Access Protocol", RFC 2244, November 1997. 626 [IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 628 [NOTIFY] King, C., "The IMAP NOTIFY Extension", 629 draft-gulbrandsen-imap-notify-06 (work in progress), 630 May 2007. 632 Appendix A. Cookbook 634 A.1. Virtual Mailboxes 636 It is possible to use the facilities described within this memo to 637 create a facility largely similar to a virtual mailbox, but handled 638 on the client side. 640 Initially, the client SELECTs the real "backing" mailbox. Next, it 641 can switch to a filtered view at any time by issuing a RETURN (COUNT 642 UPDATE CONTEXT), and using RETURN (PARTIAL x:y) as the user scrolls, 643 feeding the results into a FETCH as required to populate summary 644 views. 646 A typically useful view is UID SORT (DATE) RETURN (...) UTF-8 UNSEEN 647 UNDELETED, which can be used to show the mailbox sorted into 648 INTERNALDATE order, filtered to only show messages which are unread 649 and not yet deleted. 651 A.2. Trash Mailboxes 653 Certain contexts are particularly useful for client developers 654 wishing to present something similar to the common trash mailbox 655 metaphor in limited bandwidth. The simple criteria of UNDELETED only 656 matches undeleted messages, and the corresponding DELETED search key 657 can be used to display a per-mailbox trash-like virtual mailbox. 659 A.3. Immediate EXPUNGE notifications 661 The command "SEARCH RETURN (UPDATE) ALL" can be used to create a 662 context which notifies immediately about expunged messages, yet will 663 not affect message sequence numbers until the normal EXPUNGE message 664 can be sent. This may be useful for clients wishing to show this 665 behaviour without losing the benefit of sequence numbering. 667 A.4. Monitoring counts 669 A client need not maintain any result cache at all, but instead 670 maintain a simple count of messages matching the search criteria. 671 Typically, this would use the SEARCH command, as opposed to UID 672 SEARCH, due to its smaller representation. Such usage might prove 673 useful in monitoring the number of flagged, but unanswered, messages, 674 for example, with "SEARCH RETURN (UPDATE COUNT) FLAGGED UNANSWERED". 676 A.5. Resynchronizing Contexts 678 The creation of a context, and immediate access to it, can all be 679 accomplished in a single round-trip. Therefore, whilst it is 680 possible to elide resynchronization if no changes have occurred, it 681 is simpler in most cases to resynchronize by simply recreating the 682 context. 684 Appendix B. Server Implementation Notes 686 Although a server may cache the results, this is not mandated nor 687 required, especially when the client uses SEARCH or UID SEARCH 688 commands. UPDATE processing, for example, can be achieved 689 efficiently by comparison of the old flag state (if any) and the new, 690 and PARTIAL can be achieved by re-running the search until the 691 suitable window is required. This is a result of there being no 692 snapshot facility. 694 For example, on a new message, the server can simply test for matches 695 against all current UPDATE context search programs, and for any that 696 match, send the ADDTO return data. 698 Similarly, for a flag change on an existing message, the server can 699 check whether the message matched with its old flags, whether it 700 matches with new flags, and provide ADDTO or REMOVEFROM return data 701 accordingly if these results differ. 703 For PARTIAL requests, the server can perform a full search, 704 discarding results until the lower bound is hit, and stopping the 705 search when sufficient results have been obtained. 707 With some additional state, it is possible to restart PARTIAL 708 searches, thus avoiding performing the initial discard phase. 710 For the best performance, however, caching the full search results is 711 needed, which can allow for faster responses at the expense of 712 memory. One reasonable strategy would be to balance this trade-off 713 at run-time, discarding search results after a suitable timeout, and 714 regenerating them as required. 716 This yields state requirements of storing the search program for any 717 UPDATE contexts, and optionally storing both search program and 718 (updated) results for further contexts as required. 720 Note that in the absence of a server-side results cache, it may be 721 impossible to know if an expunged message previously matched unless 722 the original message is still available. Therefore some 723 implementations may be forced into using a results cache in many 724 circumstances. 726 UPDATE contexts created with SORT or UID SORT will almost certainly 727 require some form of results caching, however. 729 Authors' Addresses 731 Dave Cridland 732 Isode Limited 733 5 Castle Business Village 734 36, Station Road 735 Hampton, Middlesex TW12 2BX 736 GB 738 Email: dave.cridland@isode.com 740 Curtis King 741 Isode Limited 742 5 Castle Business Village 743 36, Station Road 744 Hampton, Middlesex TW12 2BX 745 GB 747 Email: cking@mumbo.ca 749 Full Copyright Statement 751 Copyright (C) The IETF Trust (2007). 753 This document is subject to the rights, licenses and restrictions 754 contained in BCP 78, and except as set forth therein, the authors 755 retain all their rights. 757 This document and the information contained herein are provided on an 758 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 759 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 760 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 761 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 762 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 763 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 765 Intellectual Property 767 The IETF takes no position regarding the validity or scope of any 768 Intellectual Property Rights or other rights that might be claimed to 769 pertain to the implementation or use of the technology described in 770 this document or the extent to which any license under such rights 771 might or might not be available; nor does it represent that it has 772 made any independent effort to identify any such rights. Information 773 on the procedures with respect to rights in RFC documents can be 774 found in BCP 78 and BCP 79. 776 Copies of IPR disclosures made to the IETF Secretariat and any 777 assurances of licenses to be made available, or the result of an 778 attempt made to obtain a general license or permission for the use of 779 such proprietary rights by implementers or users of this 780 specification can be obtained from the IETF on-line IPR repository at 781 http://www.ietf.org/ipr. 783 The IETF invites any interested party to bring to its attention any 784 copyrights, patents or patent applications, or other proprietary 785 rights that may cover technology that may be required to implement 786 this standard. Please address the information to the IETF at 787 ietf-ipr@ietf.org. 789 Acknowledgment 791 Funding for the RFC Editor function is provided by the IETF 792 Administrative Support Activity (IASA).