idnits 2.17.1 draft-cridland-imap-context-02.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 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 624. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (May 18, 2007) is 6181 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 (-07) exists of draft-gulbrandsen-imap-notify-03 == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-18 Summary: 3 errors (**), 0 flaws (~~), 4 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 Expires: November 19, 2007 Isode Limited 5 May 18, 2007 7 Contexts for IMAP4 8 draft-cridland-imap-context-02 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 November 19, 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. Protocol Changes . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.2. Context Hint . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.3. Notifications of changes . . . . . . . . . . . . . . . . . 4 55 3.3.1. Refusing to update contexts . . . . . . . . . . . . . 5 56 3.3.2. Common Features of ADDTO and REMOVEFROM . . . . . . . 6 57 3.3.3. ADDTO Return Data Item . . . . . . . . . . . . . . . . 6 58 3.3.4. REMOVEFROM Return Data Item . . . . . . . . . . . . . 7 59 3.3.5. The FREECONTEXT command . . . . . . . . . . . . . . . 7 60 3.4. Partial results . . . . . . . . . . . . . . . . . . . . . 8 61 3.5. Caching results . . . . . . . . . . . . . . . . . . . . . 9 62 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 69 Appendix A. Cookbook . . . . . . . . . . . . . . . . . . . . . . 12 70 A.1. Virtual Mailboxes . . . . . . . . . . . . . . . . . . . . 12 71 A.2. Trash Mailboxes . . . . . . . . . . . . . . . . . . . . . 12 72 A.3. Immediate EXPUNGE notifications . . . . . . . . . . . . . 13 73 A.4. Other uses . . . . . . . . . . . . . . . . . . . . . . . . 13 74 A.5. Resynchronizing Contexts . . . . . . . . . . . . . . . . . 13 75 Appendix B. Server Implementation Notes . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 77 Intellectual Property and Copyright Statements . . . . . . . . . . 15 79 1. Conventions used in this document 81 In examples, "C:" and "S:" indicate lines sent by the client 82 messaging user agent and IMAP4rev1 ([IMAP]) server respectively. 83 Although the examples show a server which supports [ESEARCH], this is 84 not a requirement of this specification. 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [KEYWORDS]. 90 Other capitalised words are typically names of IMAP extensions or 91 commands - these are uppercased for clarity only, and are case- 92 insensitive. 94 [[ Editorial comments are like this. XML2RFC working source is held 95 at http://svn.dave.cridland.net/svn/ietf-drafts/ 96 draft-cridland-imap-contexts.xml ]] 98 2. Introduction 100 Although the basic SEARCH command defined in [IMAP], and as enhanced 101 by [ESEARCH], is relatively compact in its representation, this 102 reduction saves only a certain amount of data, and huge mailboxes 103 might overwhelm the storage available for results on even relatively 104 high-end desktop machines. 106 This memo borrows concepts from [ACAP], providing a windowed view 107 onto search results, as well as bandwidth and round-trip efficient 108 updates. 110 It is intended that the protocol may be easily adapted onto the SORT 111 command specified in [SORT]. 113 3. Protocol Changes 115 3.1. Overview 117 This extension is present in any IMAP4rev1 server which includes the 118 string "CONTEXT", or any string beginning "CONTEXT=", within its 119 advertised capabilities. 121 Such servers also accept three additional return options, and provide 122 three new result data items, and no new responses. The first search 123 return option is CONTEXT, an optional hint that the criteria will be 124 used repeatedly, and is defined in Section 3.2. 126 The second is UPDATE, which causes the server to provide efficient 127 notifications of changes to the results. This is defined in 128 Section 3.3. 130 Finally, the PARTIAL return specifier causes the server to return a 131 subset of the results in set-syntax. This allows for "virtual 132 scrollbars" and other UI conveniences to be achieved without having 133 to preload the entire result set, and is described in Section 3.4. 135 All of the return specifiers have no interaction with either each 136 other or any return specifiers defined in [ESEARCH]. 138 3.2. Context Hint 140 The return option CONTEXT SHOULD be used by a client to indicate that 141 subsequent use of the criteria are likely. Servers MAY ignore this 142 return option, or use it as a hint to maintain a full result set, or 143 index. 145 A client might choose to obtain a count of matching messages prior to 146 obtaining actual results. Here, the client signifies its intention 147 to fetch the results themselves: 149 C: A01 SEARCH RETURN (CONTEXT COUNT) UNDELETED 150 UNKEYWORD $Junk 151 S: * ESEARCH (TAG "A01") COUNT 23765 152 S: A01 OK Search completed. 154 3.3. Notifications of changes 156 The search return option UPDATE, if used by a client, causes the 157 server to issue unsolicited notifications containing updates to the 158 SEARCH results which would be returned by an unmodified SEARCH. 159 These results are carried in ADDTO and REMOVEFROM data items in 160 ESEARCH/ESORT responses. 162 Both ADDTO and REMOVEFROM data items SHOULD be delivered to clients 163 in a timely manner, as and when results change, whether by new 164 messages arriving in the mailbox, metadata such as flags being 165 changed, or messages being expunged. 167 Typically, this would occur at the same time as the FETCH, EXISTS or 168 EXPUNGE responses carrying the source of the change. 170 Updates will cease only when the mailbox is no longer selected, or 171 when the FREECONTEXT command is issued by the client, whichever is 172 sooner. 174 Unlike [ACAP], there is no requirement that a context need be created 175 with CONTEXT to use UPDATE, and in addition, the lack of UPDATE with 176 a CONTEXT does not affect the results caused by later SEARCH commands 177 - there is no snapshot facility. 179 There is no interaction between UPDATE and any other return options; 180 therefore use of RETURN (UPDATE MIN), for example, does not notify 181 about the minimum UID or sequence number, but notifies instead about 182 all changes to the set of matching messages. 184 In particular, this means that a client using UPDATE and PARTIAL on 185 the same search program MAY receive notifications about messages 186 which do not currently interest it. 188 This time, the client will require notifications of updates, and 189 chooses to obtain a count: 191 C: B01 UID SEARCH RETURN (UPDATE COUNT) DELETED 192 KEYWORD $Junk 193 S: * ESEARCH (TAG "B01") COUNT 74 194 S: B01 OK Search completed, will notify. 196 3.3.1. Refusing to update contexts 198 In some cases, the server MAY refuse to provide updates, such as if 199 an internal limit on the number of update contexts is reached. 201 In this case, an untagged NO is generated during processing of the 202 command with a response-code of NOUPDATE. The response-code 203 contains, as argument, the tag of the search command for which the 204 server is refusing to honour the UPDATE request. 206 Other return options specified will still be honoured. 208 Servers MUST provide at least one updating context per client, and 209 SHOULD provide more - see Appendix B for strategies on reducing the 210 impact of additional updating contexts. 212 This time, the client will require notifications of updates, and 213 chooses to obtain a count: 215 C: B02 UID SEARCH RETURN (UPDATE COUNT) $Junk 216 KEYWORD $Junk 217 S: * ESEARCH (TAG "B01") COUNT 74 218 S: * NO [NOUPDATE "B01"] Too many contexts 219 S: B02 OK Search completed, will not notify. 221 3.3.2. Common Features of ADDTO and REMOVEFROM 223 The result update set included in the return data item is specified 224 as UIDs or message numbers, depending on how the UPDATE was 225 specified. If the UPDATE was present in a SEARCH command, the 226 results will be message numbers; in a UID SEARCH command, they will 227 be UIDs. 229 The client MUST process (and the server MUST generate) ADDTO and 230 REMOVEFROM return data items in order, including those within a 231 single ESEARCH response. 233 As with any response aside from EXPUNGE, ESEARCH responses carrying 234 ADDTO and/or REMOVEFROM return data items MAY be sent at any time. 235 In particular, servers MAY send such responses when no command is in 236 progress, during the processing of any command, or when the client is 237 using the IDLE facility described in [IDLE]. Implementors are 238 recommended to read [NOTIFY] as a mechanism for clients to signal 239 servers that they are willing to process responses at any time, and 240 are also recommended to pay close attention to Section 5.3 of [IMAP]. 242 Client implementors SHOULD NOT reuse tags with any command; in this 243 case the tag is used to identify the SEARCH command which created the 244 context. 246 3.3.3. ADDTO Return Data Item 248 The ADDTO return data item contains, as payload, a list containing 249 pairs of a position and a set of result updates to be inserted at the 250 position. For ESEARCH responses, the position MAY be zero, and MAY 251 be ignored by clients. 253 If the position is non-zero, the new results in the update are to be 254 inserted at the given position; meaning that the new results will 255 occupy the indicated start position and all existing results starting 256 from that position are shifted to the position after the insertion. 257 The client MUST update the position numbers of the shifted results. 258 The ADDTO return data item MAY include several new results to be 259 inserted - therefore it is imporant to note that the positions 260 included in a single ADDTO return data item contain positions before 261 the shifting due to other new results take place. 263 [...] 264 S: * 23762 FETCH (FLAGS (\Deleted \Seen)) 265 S: * 23763 FETCH (FLAGS ($Junk \Seen)) 266 S: * ESEARCH (TAG "B01") UID ADDTO (0 32768:32769) 268 Note that this example assumes messages 23762 and 23763 with UIDs 269 32768 and 32769 respectively previously had neither \Deleted nor 270 $Junk set. Also note that only the ADDTO is included, and not the 271 (now changed) COUNT. 273 3.3.4. REMOVEFROM Return Data Item 275 The REMOVEFROM return data item contains a set of results to be 276 removed. The results to be removed are referenced by message number 277 or UID, as appropriate, and need not be in the same order as the 278 results, therefore servers are RECOMMENDED to sort the results into 279 increasing UID (and sequence number) order, to take full advantage of 280 the set-syntax representation. 282 Note that although no position information is included, the positions 283 of any results after those removed will change. 285 Here, a message in the result set is expunged. The REMOVEFROM here 286 is shown to happen without any command in progress, see 287 Section 3.3.2. Note that EXPUNGE responses do not have this 288 property. 290 [...] 291 S: * ESEARCH (TAG "B01") UID REMOVEFROM 32768 292 C: B03 NOOP 293 S: * EXPUNGE 23762 294 S: B03 OK Nothing done. 296 3.3.5. The FREECONTEXT command 298 When a client no longer wishes to receive updates, it may issue the 299 FREECONTEXT command, which will prevent all updates to the contexts 300 named in the arguments from being transmitted by the server. The 301 command takes, as arguments, one or more tags of the commands used to 302 request updates. 304 The server MAY free any resource associated with a context so 305 disabled. 307 C: B04 FREECONTEXT "B01" 308 S: B04 OK No further updates. 310 3.4. Partial results 312 The PARTIAL search return option causes the server to provide in an 313 ESEARCH response the range from the results denoted by the sequence 314 range given as the mandatory argument. The first result is 1, thus 315 the first 500 results would be obtained by a return option of 316 "PARTIAL 1:500", and the second 500 by "PARTIAL 501:1000". This 317 intentionally mirrors message sequence numbers. 319 For SEARCH results, the entire result set MUST be ordered in "mailbox 320 order", that is, in UID or message sequence number order. 322 Where a PARTIAL search return option references results which do not 323 exist, by using a range which starts or ends higher than the COUNT of 324 results, then the server returns those results which are in the set. 325 This yields a PARTIAL return data item which has, as payload, the 326 original range and a potentially missing set of results which may be 327 shorter than the extent of the range. 329 The subset of results are returned in sequence-set syntax, and 330 servers SHOULD order results from a SEARCH for maximum efficiency in 331 this representation. 333 Clients need not request PARTIAL results in any particular order. 335 // Recall from A01 that there are 23764 results. 336 C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED 337 UNKEYWORD $Junk 338 C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED 339 UNKEYWORD $Junk 340 C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED 341 UNKEYWORD $Junk 342 S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...) 343 // 264 results in set syntax elided, 344 // this spans the end of the results. 345 S: A02 OK Completed. 346 S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...) 347 // 500 results in set syntax elided. 348 S: A03 OK Completed. 349 S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL) 350 // No results are present, this is beyond the end of the results. 351 S: A04 OK Completed. 353 3.5. Caching results 355 Server implementations MAY cache results from a search or sort, 356 whether or not hinted to by CONTEXT, in order to make subsequent 357 searches more efficient, perhaps by recommencing a subsequent PARTIAL 358 search where a previous search left off. However servers MUST behave 359 identically whether or not internal caching is taking place, 360 therefore any such cache is required to be updated as changes to the 361 mailbox occur. An alternate strategy would be to discard results 362 when any change occurs to the mailbox. 364 4. Formal Syntax 365 The collected formal syntax. This includes definitions from [IMAP] 366 and [IMAP-ABNF], and uses ABNF as defined in [ABNF]. 368 capability =/ "CONTEXT" / "CONTEXT=" atom 370 command-select =/ "FREECONTEXT" 1*(SP quoted) 371 ;; from [IMAP] 373 addto-position = number 374 ;; Number may be 0 for SEARCH result additions. 375 ;; from [IMAP] 377 modifier-context = "CONTEXT" 379 modifier-partial = "PARTIAL" SP seq-range 380 ;; from [IMAP] 382 modifier-update = "UPDATE" 384 search-return-opt =/ modifier-context / modifier-partial / 385 modifier-update 386 ;; All conform to , from [IMAP-ABNF] 388 resp-text-code =/ "NOUPDATE" SP quoted 389 ;; from [IMAP] 391 ret-data-addto = "ADDTO" 392 SP "(" addto-position SP sequence-set 393 *(SP addto-position SP sequence-set) 394 ")" 395 ;; from [IMAP] 397 ret-data-partial = "PARTIAL" 398 SP "(" seq-range SP partial-results ")" 399 ;; is the requested range. 400 ;; from [IMAP] 402 partial-results = sequence-set / "NIL" 403 ;; from [IMAP] 404 ;; NIL indicates no results correspond to the requested range. 406 ret-data-removefrom = "REMOVEFROM" SP sequence-set 407 ;; from [IMAP] 409 search-return-data =/ ret-data-partial / ret-data-addto / 410 ret-data-removefrom 411 ;; All conform to , from [IMAP-ABNF] 413 5. Security Considerations 415 It is believed that this specification introduces no serious new 416 security considerations. However, implementors are advised to refer 417 to [IMAP]. 419 Creation of contexts, both for UPDATE and PARTIAL, can benefit from 420 storing potentially large result sets on the server. Implementors 421 are advised to take care not to provide a method for denial of 422 service (DoS) attacks based on this; the notes in Appendix B may aid 423 in implementation decisions. Note that a server avoiding storing the 424 results will have much increased I/O, which may also be an avenue for 425 DoS attacks. 427 6. IANA Considerations 429 IMAP4 capabilities are registered by publishing a standards track or 430 IESG approved experimental RFC. The registry is currently located 431 at: 433 http://www.iana.org/assignments/imap4-capabilities 435 This document defines the CONTEXT IMAP capability. IANA is requested 436 to add it to the registry accordingly. 438 7. Acknowledgements 440 Much of the design of this extension can be found in ACAP. Valuable 441 comments, both in agreement and in dissent, were received from Alexey 442 Melnikov, Arnt Gulbrandsen, Cyrus Daboo, Filip Navara, Mark Crispin, 443 Randall Gellens, Zoltan Ordogh and others, and many of these comments 444 have had significant influence on the design or the text. The 445 authors are grateful to all those involved, including those not 446 mentioned here. 448 8. References 450 8.1. Normative References 452 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 453 Specifications: ABNF", RFC 4234, October 2005. 455 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 456 4rev1", RFC 3501, March 2003. 458 [IMAP-ABNF] 459 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 460 ABNF", RFC 4466, April 2006. 462 [KEYWORDS] 463 Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, March 1997. 466 8.2. Informative References 468 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 469 Configuration Access Protocol", RFC 2244, November 1997. 471 [ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH 472 Command for Controlling What Kind of Information Is 473 Returned", RFC 4731, November 2006. 475 [IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 477 [NOTIFY] King, C., "The IMAP NOTIFY Extension", 478 draft-gulbrandsen-imap-notify-03 (work in progress), 479 March 2007. 481 [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 482 PROTOCOL - SORT AND THREAD EXTENSIONS", 483 draft-ietf-imapext-sort-18 (work in progress), 484 November 2006. 486 Appendix A. Cookbook 488 A.1. Virtual Mailboxes 490 It is possible to use the facilities described within this memo to 491 create a facility largely similar to a virtual mailbox, but handled 492 on the client side. 494 Initially, the client SELECTs the real "backing" mailbox. Next, it 495 can switch to a filtered view at any time by issuing a SEARCH RETURN 496 (COUNT UPDATE CONTEXT), and using SEARCH RETURN (PARTIAL x:y) as the 497 user scrolls, feeding the results into a FETCH as required to 498 populate summary views. 500 A.2. Trash Mailboxes 502 Certain contexts are particularly useful for client developers 503 wishing to present something similar to the common trash mailbox 504 metaphor in limited bandwidth. The simple criteria of UNDELETED only 505 matches undeleted messages, and the corresponding DELETED search key 506 can be used to display a per-mailbox trash-like virtual mailbox. 508 A.3. Immediate EXPUNGE notifications 510 The command "SEARCH RETURN (UPDATE) ALL" can be used to create a 511 context which notifies immediately about expunged messages, yet will 512 not affect message sequence numbers until the normal EXPUNGE message 513 can be sent. This may be useful for clients wishing to show this 514 behaviour without losing the benefit of sequence numbering. 516 A.4. Other uses 518 It is entirely possible to simultaneously have two or more UPDATE 519 contexts in operation. This can be used to build a grouped message 520 display in some cases, and also allows for monitoring counts of 521 messages matching certain complex criteria. 523 A.5. Resynchronizing Contexts 525 The creation of a context, and immediate access to it, can all be 526 accomplished in a single round-trip. Therefore, whilst it is 527 possible to elide resynchronization if no changes have occurred, it 528 is simpler in most cases to resynchronize by simply recreating the 529 context. 531 Appendix B. Server Implementation Notes 533 Although a server may cache the results, this is not mandated nor 534 required. UPDATE processing, for example, can be achieved 535 efficiently by comparison of the old flag state (if any) and the new, 536 and PARTIAL can be achieved by re-running the search until the 537 suitable window is required. This is a result of there being no 538 snapshot facility. 540 For example, on a new message, the server can simply test for matches 541 against all current UPDATE context search programs, and for any that 542 match, send the ADDTO return data. 544 Similarly, for a flag change on an existing message, the server can 545 check whether the message matched with its old flags, whether it 546 matches with new flags, and provide ADDTO or REMOVEFROM return data 547 accordingly if these results differ. 549 For PARTIAL requests, the server can perform a full search, 550 discarding results until the lower bound is hit, and stopping the 551 search when sufficient results have been obtained. 553 With some additional state, it is possible to restart PARTIAL 554 searches, thus avoiding performing the initial discard phase. 556 For the best performance, however, caching the full search results is 557 needed, which can allow for faster responses at the expense of 558 memory. One reasonable strategy would be to balance this trade-off 559 at run-time, discarding search results after a suitable timeout, and 560 regenerating them as required. 562 This yields state requirements of storing the search program for any 563 UPDATE contexts, and optionally storing both search program and 564 (updated) results for further contexts as required. 566 Authors' Addresses 568 Dave Cridland 569 Isode Limited 570 5 Castle Business Village 571 36, Station Road 572 Hampton, Middlesex TW12 2BX 573 GB 575 Email: dave.cridland@isode.com 577 Curtis King 578 Isode Limited 579 5 Castle Business Village 580 36, Station Road 581 Hampton, Middlesex TW12 2BX 582 GB 584 Email: cking@mumbo.ca 586 Full Copyright Statement 588 Copyright (C) The IETF Trust (2007). 590 This document is subject to the rights, licenses and restrictions 591 contained in BCP 78, and except as set forth therein, the authors 592 retain all their rights. 594 This document and the information contained herein are provided on an 595 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 596 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 597 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 598 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 599 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 600 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 602 Intellectual Property 604 The IETF takes no position regarding the validity or scope of any 605 Intellectual Property Rights or other rights that might be claimed to 606 pertain to the implementation or use of the technology described in 607 this document or the extent to which any license under such rights 608 might or might not be available; nor does it represent that it has 609 made any independent effort to identify any such rights. Information 610 on the procedures with respect to rights in RFC documents can be 611 found in BCP 78 and BCP 79. 613 Copies of IPR disclosures made to the IETF Secretariat and any 614 assurances of licenses to be made available, or the result of an 615 attempt made to obtain a general license or permission for the use of 616 such proprietary rights by implementers or users of this 617 specification can be obtained from the IETF on-line IPR repository at 618 http://www.ietf.org/ipr. 620 The IETF invites any interested party to bring to its attention any 621 copyrights, patents or patent applications, or other proprietary 622 rights that may cover technology that may be required to implement 623 this standard. Please address the information to the IETF at 624 ietf-ipr@ietf.org. 626 Acknowledgment 628 Funding for the RFC Editor function is provided by the IETF 629 Administrative Support Activity (IASA).