idnits 2.17.1 draft-melnikov-imap-disc-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1195 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 224 instances of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 2002) is 7863 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) == Missing Reference: 'HEADER' is mentioned on line 759, but not defined -- Looks like a reference, but probably isn't: '3' on line 768 -- Looks like a reference, but probably isn't: '4' on line 768 -- Looks like a reference, but probably isn't: '5' on line 768 -- Looks like a reference, but probably isn't: '6' on line 768 -- Looks like a reference, but probably isn't: '7' on line 768 -- Looks like a reference, but probably isn't: '8' on line 768 -- Looks like a reference, but probably isn't: '9' on line 769 -- Looks like a reference, but probably isn't: '10' on line 769 -- Looks like a reference, but probably isn't: '11' on line 769 -- Looks like a reference, but probably isn't: '13' on line 769 -- Looks like a reference, but probably isn't: '14' on line 769 -- Looks like a reference, but probably isn't: '15' on line 769 -- Looks like a reference, but probably isn't: '16' on line 769 -- Looks like a reference, but probably isn't: '21' on line 770 == Missing Reference: 'UNSEEN 12' is mentioned on line 1067, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 1068, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 1071, but not defined ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2359 (ref. 'UIDPLUS') (Obsoleted by RFC 4315) -- No information found for draft-melnikov-imap-condstore-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CONDSTORE' -- No information found for draft-crispin-imap-multiappend-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MULTIAPPEND' -- No information found for draft-melnikov-imap-unselect-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UNSELECT' Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAPEXT Working Group A. Melnikov 2 Internet Draft: IMAP4 Disconnected Access Editor 3 Document: draft-melnikov-imap-disc-02.txt October 2002 5 Synchronization operations for disconnected IMAP4 clients 7 Status of this Memo 9 This document is an Internet Draft and is in full conformance with 10 all provisions of Section 10 of RFC 2026. 12 Internet Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its Areas, and its Working Groups. Note that 14 other groups may also distribute working documents as Internet 15 Drafts. Internet Drafts are draft documents valid for a maximum of 16 six months. Internet Drafts may be updated, replaced, or obsoleted 17 by other documents at any time. It is not appropriate to use 18 Internet Drafts as reference material or to cite them other than as 19 ``work in progress''. 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 This is a draft document based on the expired draft written by 28 the IETF IMAP Working Group. A revised version of this draft document 29 will be submitted to the RFC editor as an Informational RFC for the 30 Internet Community. Discussion and suggestions for improvement are 31 requested, and should be sent to imap@CAC.Washington.EDU. 33 This memo is for informational use and does not constitute a 34 standard. Distribution of this memo is unlimited. 36 1. Abstract 38 This document attempts to address some of the issues involved in building 39 a disconnected IMAP4 client. In particular, it deals with the issues 40 of what might be called the "driver" portion of the synchronization 41 tool: the portion of the code responsible for issuing the correct set 42 of IMAP4 commands to synchronize the disconnected client in the way 43 that is most likely to make the human who uses the disconnected 44 client happy. 46 This note describes different strategies that can be used by disconnected 47 clients as well as shows how to use IMAP protocol in order to minimize the 48 time of synchronization process. 50 2. Conventions Used in this Document 52 In examples, "C:" and "S:" indicate lines sent by the client and 53 server respectively. 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 59 Editorial comments/questions or missing paragraphs are marked in the 60 text with << and >>. 62 3. Design Principles 64 All mailbox state or content information stored on the disconnected 65 client should be viewed strictly as a cache of the state of the 66 server. The "master" state remains on the server, just as it would 67 with an interactive IMAP4 client. The one exception to this rule is 68 that information about the state of the disconnected client's cache 69 (the state includes flag changes while offline and scheduled message uploads) 70 remains on the disconnected client: that is, the IMAP4 server is not 71 responsible for remembering the state of the disconnected IMAP4 client. 73 We assume that a disconnected client is a client that, for whatever 74 reason, wants to minimize the length of time that it is "on the 75 phone" to the IMAP4 server. Often this will be because the client is 76 using a dialup connection, possibly with very low bandwidth, but 77 sometimes it might just be that the human is in a hurry to catch an 78 airplane, or some other event beyond our control. Whatever the 79 reason, we assume that we must make efficient use of the network 80 connection, both in the usual sense (not generating spurious traffic) 81 and in the sense that we would prefer not to have the connection 82 sitting idle while the client and/or the server is performing 83 strictly local computation or I/O. Another, perhaps simpler way of 84 stating this is that we assume that network connections are 85 "expensive". 87 Practical experience with disconnected mail systems has shown that 88 there is no single synchronization strategy that is appropriate 89 for all cases. Different humans have different preferences, 90 and the same human's preference will vary depending both on 91 external circumstance (how much of a hurry the human is in today) 92 and on the value that the human places on the messages being 93 transferred. The point here is that there is no way that 94 the synchronization program can guess exactly what the human 95 wants to do, so the human will have to provide some guidance. 97 Taken together, the preceding two principles lead to the conclusion 98 that the synchronization program must make its decisions based on 99 some kind of guidance provided by the human by selecting the appropriate 100 options in UI or through some sort of configuration file, but almost 101 certainly should not pause for I/O with the human during the middle 102 of the synchronization process. The human will almost certainly have 103 several different configurations for the synchronization program, for 104 different circumstances. 106 Since a disconnected client has no way of knowing what changes might 107 have occurred to the mailbox while it was disconnected, message 108 numbers are not useful to a disconnected client. All disconnected 109 client operations should be performed using UIDs, so that the client 110 can be sure that it and the server are talking about the same 111 messages during the synchronization process. 113 4. Overall picture of synchronization 115 The basic strategy for synchronization is outlined below. 116 Note that the real strategy may vary from one application to another 117 or may depend on a synchronization mode. 119 a) Process any "actions" that were pending on the client that 120 were not associated with any mailbox (in particular sending 121 messages composed offline with SMTP. This is not part of IMAP 122 synchronization, but it is mentioned here for completeness); 124 b) Fetch the current list of "interesting" mailboxes (The disconnected 125 client should allow the user to skip this step completely); 127 c) "Client-to-server synchronization" - for each IMAP "action" that 128 were pending on the client: 130 1) If the action implies opening a new mailbox (any operation 131 that operates on messages) - open the mailbox. Check its UID 132 validity value (see section 5.1 for more details) returned in 133 the UIDVALIDITY response code. If the UIDVALIDITY value returned 134 by the server differs, the client MUST empty the local cache of 135 the mailbox and remove any pending "actions" which refer to UIDs 136 in that mailbox. 138 2) Perform the action. If the action is to delete a mailbox (DELETE), 139 make sure that the mailbox is closed first. 141 d) "Server-to-client synchronization" - for each mailbox that requires 142 synchronization, do the following: 144 1) Check the mailbox UIDVALIDITY (see section 5.1 for more details). 145 with SELECT/EXAMINE/STATUS. 146 If UIDVALIDITY value returned by the server differs, 147 the client MUST 149 * empty the local cache of that mailbox; 150 * remove any pending "actions" which refer to UIDs in 151 that mailbox; 152 * skip step 2-II; 154 2) Fetch the current "descriptors"; 156 I) Discover new messages. 158 II) Discover changes to old messages. 160 3) Fetch the bodies of any "interesting" messages that the client 161 doesn't already have. 163 d) Close all open mailboxes not required for further operations 164 (if staying online) or disconnect all open connections (if going 165 offline). 167 Terms used: 169 "Actions" are queued requests that were made by the human to the 170 client's MUA software while the client was disconnected. 172 Let define "descriptors" as a set of IMAP4 FETCH data items. 173 Conceptually, a message's descriptor is that set of 174 information that allows the synchronization program to decide what 175 protocol actions are necessary to bring the local cache to the 176 desired state for this message; since this decision is really up 177 to the human, this information probably includes a at least a few 178 header fields intended for human consumption. Exactly what will 179 constitute a descriptor depends on the client implementation. At 180 a minimum, the descriptor contains the message's UID and FLAGS. 181 Other likely candidates are the RFC822.SIZE, RFC822.HEADER and 182 BODYSTRUCTURE data items. 184 Comments: 186 1). The list of actions should be ordered. E.g., if the human deletes 187 message A1 in mailbox A, then expunges mailbox A, then deletes 188 message A2 in mailbox A, the human will expect that message A1 is 189 gone and that message A2 is still present but is now deleted. 191 By processing all the actions before proceeding with 192 synchronization, we avoid having to compensate for the local MUA's 193 changes to the server's state. That is, once we have processed 194 all the pending actions, the steps that the client must take to 195 synchronize itself will be the same no matter where the changes to 196 the server's state originated. 198 2). Steps a) and b) can be performed in parallel. Alternatively step a) 199 can be performed after d). 201 3). On step b) the set of "interesting" mailboxes pretty much has to be 202 determined by the human. What mailboxes belong to this set may 203 vary between different IMAP4 sessions with the same server, 204 client, and human. An interesting mailbox can be a mailbox 205 returned by LSUB command. Special mailbox "INBOX" SHOULD always 206 be considered "interesting". 208 4). On step d-2-II) the client also finds out about 209 changes to the flags of messages that the client already has in 210 its local cache, as well as finding out about messages in the 211 local cache that no longer exist on the server (i.e., messages that 212 have been expunged). 214 5). "Interesting" messages are those messages that the synchronization 215 program thinks the human wants to have cached locally, based on 216 the configuration and the data retrieved in step (b). 218 The rest of this discussion will focus primarily on the synchronization 219 issues for a single mailbox. 221 5. Mailbox synchronization steps and strategies 223 5.1. Checking UID Validity 225 The "UID validity" of a mailbox is a number returned in an 226 UIDVALIDITY response code in an OK untagged response at mailbox 227 selection time. The UID validity value changes between sessions when 228 UIDs fail to persist between sessions. 230 Whenever the client selects a mailbox, the client must compare the 231 returned UID validity value with the value stored in the local cache. 232 If the UID validity values differ, the UIDs in the client's cache are 233 no longer valid. The client MUST then empty the local cache of 234 that mailbox and remove any pending "actions" which refer to UIDs in 235 that mailbox. The client MAY also issue a warning to the human. 236 The client MUST NOT cancel any scheduled uploads (i.e. APPENDs) for 237 the mailbox. 239 Note that UIDVALIDITY is not only returned on a mailbox selection. 240 COPYUID and APPENDUID response codes defined in [UIDPLUS] extension 241 (see also 5.2.2) and UIDVALIDITY STATUS response data item also contain 242 a UIDVALIDITY value for some other mailbox. The client SHOULD behave as 243 described in the previous paragraph (but it should act on the other mailbox's 244 cache), no matter how it obtained the UIDVALIDITY value. 246 5.2. Synchronizing local changes with the server 248 5.2.1. Uploading messages to the mailbox 250 There are two most typical examples of operations that will result in message 251 uploads: 253 1) Saving a draft message 254 2) Message copy between remote mailboxes on two different IMAP servers 255 or a local mailbox and a remote mailbox. 257 Message upload is performed with APPEND command. A message scheduled to be 258 uploaded has no UID associated with it, as all UIDs are assigned by the 259 server. The APPEND command will effectively associate a UID with the uploaded 260 message that can be stored in the local cache for a future reference. 261 However [IMAP4] doesn't describe a simple mechanism to discover the message UID 262 by just performing the APPEND command. In order to discover UID the client can 263 do one of the following: 265 1) Remove the uploaded message from cache. After that use the mechanism described 266 in 5.3 to fetch the information about the uploaded message as if it was uploaded 267 by some other client. 269 2) Try to fetch header information as described in 5.2.2 in order to find a message 270 that corresponds to the uploaded message. One strategy of doing that is described 271 in 5.2.2. 273 Case 1) describes a non particularly smart client. 275 C: A003 APPEND Drafts (\Seen $MDNSent) {310} 276 S: + Ready for literal data 277 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 278 C: From: Fred Foobar 279 C: Subject: afternoon meeting 280 C: To: mooch@owatagu.siam.edu 281 C: Message-Id: 282 C: MIME-Version: 1.0 283 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 284 C: 285 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 286 C: 287 S: A003 OK APPEND Completed 289 Fortunately there is a simpler way to discover the message UID in the presence 290 of [UIDPLUS] extension: 292 C: A003 APPEND Drafts (\Seen $MDNSent) {310} 293 S: + Ready for literal data 294 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 295 C: From: Fred Foobar 296 C: Subject: afternoon meeting 297 C: To: mooch@owatagu.siam.edu 298 C: Message-Id: 299 C: MIME-Version: 1.0 300 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 301 C: 302 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 303 C: 304 S: A003 OK APPEND [APPENDUID 1022843275 77712] completed 306 The UID of the appended message is the second parameter of APPENDUID response code. 308 5.2.2. Optimizing "move" and "copy" operations 310 Practical experience with IMAP, and other mailbox access 311 protocols that support multiple mailboxes suggests that moving a 312 message from one mailbox to another is an extremely common operation. 314 5.2.2.1. Moving a message between two mailboxes on the same server 316 In IMAP4 a "move" operation between two mailboxes on the same server 317 is really a combination of a COPY operation and a STORE +FLAGS (\Deleted) 318 operation. This makes good protocol sense for IMAP, but it leaves 319 a simple-minded disconnected client in the silly position of deleting 320 and possibly expunging its cached copy of a message, then fetching 321 an identical copy via the network. 323 However, the presence of UIDPLUS extension support in the server can help: 324 A001 UID COPY 567,414 "Interesting Messages" 325 A001 OK [COPYUID 1022843275 414,567 5:6] Completed 326 This tells the client that the message with UID 414 in the current mailbox 327 was successfully copied to the mailbox "Interesting Messages" and was given 328 the UID 5, and that the message with UID 567 was given the UID 6. 330 In the absence of UIDPLUS extension support in the server the following 331 trick can be used. By including the Message-ID: header and the INTERNALDATE 332 data item as part of the descriptor, the client can check the descriptor of a 333 "new" message against messages that are already in its cache, and 334 avoid fetching the extra copy. Of course, it's possible that the 335 cost of checking to see if the message is already in the local cache 336 may exceed the cost of just fetching it, so this technique should not 337 be used blindly. If the MUA implements a "move" command, it make 338 special provisions to use this technique when it knows that a 339 copy/delete sequence is the result of a "move" command. 341 Since it's theoretically possible for this algorithm to find the 342 wrong message (given sufficiently malignant Message-ID headers), 343 implementors should provide a way to disable this optimization, both 344 permanently and on a message-by-message basis. 346 << Example >> 348 5.2.2.2. Moving a message from a remote mailbox to a local 350 Moving a message from a remote mailbox to a local is done with FETCH 351 (that includes FLAGS and INTERNALDATE) followed by 352 UID STORE +FLAGS.SILENT (\Deleted): 354 C: A003 UID FETCH 123 (RFC822 INTERNALDATE FLAGS) 355 S: * 27 FETCH (UID 123 INTERNALDATE "31-May-2002 05:26:59 -0600" 356 FLAGS (\Seen $MDNSent) RFC822 357 S: ...message body... 358 S: ) 359 S: A003 OK UID FETCH completed 360 C: A004 UID STORE +FLAGS.SILENT (\Deleted) 361 S: A004 STORE completed 363 Note, that there is no reason to fetch the message during synchronization 364 if it already in the client's cache. Also, the client SHOULD preserve 365 delivery date in the local cache. 367 5.2.2.3. Moving a message from a local mailbox to a remote 369 Moving a message from a local mailbox to a remote is done with APPEND: 371 C: A003 APPEND Drafts (\Seen $MDNSent) "31-May-2002 05:26:59 -0600" {310} 372 S: + Ready for literal data 373 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 374 C: From: Fred Foobar 375 C: Subject: afternoon meeting 376 C: To: mooch@owatagu.siam.edu 377 C: Message-Id: 378 C: MIME-Version: 1.0 379 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 380 C: 381 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 382 C: 383 S: A003 OK APPEND [APPENDUID 1022843275 77712] completed 385 The client SHOULD specify delivery date from the local cache in the APPEND. 387 5.2.2.4. Moving a message between two mailbox on two different servers 389 Moving a message between two mailbox on two different servers is a 390 combination of the 5.2.2.2 followed by 5.2.2.3. 392 5.2.2.5. Uploading multiple messages to a remote mailbox with MULTIAPPEND 394 When there is a need to upload multiple messages to a remote mailbox 395 (e.g. as per 5.2.2.3), the presence of certain IMAP extensions may 396 significantly improve performance. One of them is [MULTIAPPEND]. 398 For some mail stores opening a mailbox for appending might be expensive. 399 [MULTIAPPEND] tells the server to open mailbox once (instead of opening 400 and closing it "n" times per "n" messages to be uploaded) and keep it 401 open while a group of messages is being uploaded to the server. 403 Also, if the server supports both [MULTIAPPEND] and [LITERAL+] extensions, 404 the entire upload is accomplished in a single command/response round trip. 406 Note: Client implementors should be aware, that [MULTIAPPEND] performs 407 append of multiple messages atomically. This means, for example, 408 if there is not enough space to save "n"-th message (or the message 409 has invalid structure and is rejected by the server) after successful 410 upload of "n-1" messages, the whole upload operation fails and no 411 message will be saved in the mailbox. Although, this behavior might 412 be desirable in certain situations, it might not be what you want. 413 See also section 6.1 for discussions of error recovery. 415 Note: MULTIAPPEND can be used together with UIDPLUS extension in a way 416 similar to what was described in section 5.2.1. [MULTIAPPEND] 417 extends syntax of APPENDUID response code to allow for multiple 418 message UIDs in the second parameter. 420 Example: 421 An example below demonstrates the use of MULTIAPPEND together with 422 UIDPLUS (synchronization points where the client waits for confirmations 423 from the server are marked with "<--->"): 425 C: A003 APPEND Jan-2002 (\Seen $MDNSent) "31-May-2002 05:26:59 -0600" {310} 426 <---> 427 S: + Ready for literal data 428 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 429 C: From: Fred Foobar 430 C: Subject: afternoon meeting 431 C: To: mooch@owatagu.siam.edu 432 C: Message-Id: 433 C: MIME-Version: 1.0 434 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 435 C: 436 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 437 C: (\Seen) " 1-Jun-2002 22:43:04 -0800" {286} 438 <---> 439 S: + Ready for literal data 440 C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST) 441 C: From: Joe Mooch 442 C: Subject: Re: afternoon meeting 443 C: To: foobar@blurdybloop.com 444 C: Message-Id: 445 C: MIME-Version: 1.0 446 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 447 C: 448 C: 3:30 is fine with me. 449 C: 450 S: A003 OK APPEND [APPENDUID 1022843275 77712,77713] completed 452 The upload takes 3 round trips. 454 Example: 455 The example above was modified for the case when the server supports 456 MULTIAPPEND, LITERAL+ and UIDPLUS. The upload takes only 1 round trip. 458 C: A003 APPEND Jan-2002 (\Seen $MDNSent) "31-May-2002 05:26:59 -0600" {310+} 459 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 460 C: From: Fred Foobar 461 C: Subject: afternoon meeting 462 C: To: mooch@owatagu.siam.edu 463 C: Message-Id: 464 C: MIME-Version: 1.0 465 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 466 C: 467 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 468 C: (\Seen) " 1-Jun-2002 22:43:04 -0800" {286+} 469 C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST) 470 C: From: Joe Mooch 471 C: Subject: Re: afternoon meeting 472 C: To: foobar@blurdybloop.com 473 C: Message-Id: 474 C: MIME-Version: 1.0 475 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 476 C: 477 C: 3:30 is fine with me. 478 C: 479 S: A003 OK APPEND [APPENDUID 1022843275 77712,77713] completed 481 5.2.3. Replaying local flag changes 483 The disconnected client uses STORE command to synchronize local flag state 484 with the server. The disconnected client SHOULD use +FLAGS.SILENT or -FLAGS.SILENT 485 in order to set or unset flags modified by the user while offline. FLAGS 486 form must not be used, as there is a risk that this will overwrite flags 487 on the server that has been changed by some other client. 489 Example: 490 For the message with UID 15, the disconnected client stores the following 491 flags \Seen and $Highest. The flags were modified on the server by some other 492 client: \Seen, \Answered and $Highest. 493 While offline the user requested to remove $Highest flags and to add \Deleted. 494 The flag synchronization sequence for the message should look like: 496 C: A001 UID STORE 15 +FLAGS.SILENT (\Deleted) 497 S: A001 STORE completed 498 C: A002 UID STORE 15 -FLAGS.SILENT ($Highest) 499 S: A002 STORE completed 501 If the disconnected client is able to store an additional binary state 502 information (or a piece of information that can take a value from a predefined 503 set of values) in the local cache of an IMAP mailbox or in a local mailbox 504 (e.g. message priority), and if the server supports storing of arbitrary 505 keywords, the client MUST use keywords to store this state on the server. 507 Example: 508 Imagine a speculative mail client that can mark a message as one of work-related 509 ($Work), personal ($Personal) or spam ($Spam). In order to mark a message as 510 personal the client issues: 512 C: A001 UID STORE 15 +FLAGS.SILENT ($Personal) 513 S: A001 STORE completed 514 C: A002 UID STORE 15 -FLAGS.SILENT ($Work $Spam) 515 S: A002 STORE completed 517 In order to mark the message as neither work, nor personal, not spam, the client 518 issues: 520 C: A003 UID STORE 15 -FLAGS.SILENT ($Personal $Work $Spam) 521 S: A003 STORE completed 523 5.2.4. Processing mailbox compression (expunge) requests 525 A naive disconnected client implementation that supports compressing a mailbox 526 while offline may decide to issue an EXPUNGE command to the server in order 527 to expunge messages marked \Deleted. The problem with this command during 528 synchronization is that it permanently erases all messages with \Deleted flag set, 529 i.e. even those messages that were marked as \Deleted on the server while the user 530 was offline. Doing so will lead the user to an unpleasant surprise. 532 Fortunately [UIDPLUS] extension can help in this case as well. The extension 533 introduces UID EXPUNGE command, that, unlike EXPUNGE, takes a UID set parameter, 534 that lists UIDs of all messages that can be expunged. When processing this command 535 server erases only messages with \Deleted flag listed in the UID list. Thus, 536 a message not listed in the UID set will not be expunged even if it has \Deleted 537 flag set. 539 Example: While offline 3 messages with UIDs 7, 27 and 65 were marked \Deleted 540 when the user requested to compress the open mailbox. Another client marked 541 a message \Deleted on the server (UID 34). During synchronization the 542 disconnected client issues: 544 C: A001 UID EXPUNGE 7,27,65 545 S: * ... EXPUNGE 546 S: * ... EXPUNGE 547 S: * ... EXPUNGE 548 S: A001 UID EXPUNGE completed 550 If another client issues UID SEARCH DELETED command (to find all messages with 551 \Deleted flag) before and after the UID EXPUNGE it will get: 553 Before: 554 C: B001 UID SEARCH DELETED 555 S: * SEARCH 65 34 27 7 556 S: B001 UID SEARCH completed 558 After: 559 C: B002 UID SEARCH DELETED 560 S: * SEARCH 34 561 S: B002 UID SEARCH completed 563 In the absence of [UIDPLUS] extension the following sequence of command can be 564 used as an approximation. Note, that when this sequence is performed, there is a 565 possibility that another client marks additional messages as deleted and these 566 messages will be expunged as well. 568 1). Find all messages marked \Deleted on the server: 570 C: A001 UID SEARCH DELETED 571 S: * SEARCH 65 34 27 7 572 S: A001 UID SEARCH completed 574 2). Find all messages that must not be erased (for the previous example 575 the list will consist of the message with UID 34) 577 3). Temporary remove \Deleted flag on all messages found on the step 2) 579 C: A002 UID STORE 34 -FLAGS.SILENT (\Deleted) 580 S: A002 UID STORE completed 582 4). Expunge the mailbox 584 C: A003 EXPUNGE 585 S: * 20 EXPUNGE 586 S: * 7 EXPUNGE 587 S: * 1 EXPUNGE 588 S: A003 EXPUNGE completed 590 Here message with UID 7 has message number 1; with UID 27 - message 591 number 7 and with UID 65 - message number 20. 593 5). Restore \Deleted flag on all messages found when performing step 2) 595 C: A004 UID STORE 34 +FLAGS.SILENT (\Deleted) 596 S: A004 UID STORE completed 598 5.2.5. Closing a mailbox 600 When the disconnected client has to close a mailbox, it SHOULD NOT use 601 CLOSE command, because CLOSE does a silent EXPUNGE (section 5.2.4 explains 602 why EXPUNGE must not be used by a disconnected client). It is safe to use 603 CLOSE only if the mailbox was opened with EXAMINE. 605 If the mailbox was opened with SELECT, the client can use one of the 606 following commands to implicitly close the mailbox and prevent the silent 607 expunge: 609 1). UNSELECT - This is a command described in [UNSELECT] that works as 610 CLOSE, but doesn't cause the silent EXPUNGE. This command is 611 supported by the server if it reports UNSELECT in its CAPABILITY list. 612 2). SELECT - SELECT causes implicit CLOSE without EXPUNGE. 613 3). If the client intends to issue LOGOUT after closing the mailbox, it may 614 just issue LOGOUT, because LOGOUT causes implicit CLOSE without EXPUNGE 615 as well. 616 4). SELECT - if the client knows a mailbox that doesn't 617 exist or can't be selected, it MAY SELECT it. 619 If the client opened the mailbox with SELECT and just wants to avoid 620 implicit EXPUNGE without closing the mailbox, it may also use the following: 622 5). EXAMINE - reselect the same mailbox in read-only mode. 624 5.3. Details of "Normal" synchronization of a single mailbox 626 The most common form of synchronization is where the human trusts the 627 integrity of the client's copy of the state of a particular mailbox, 628 and simply wants to bring the client's cache up to date so that it 629 accurately reflects the mailbox's current state on the server. 631 5.3.1. Discovering new messages and changes to old messages 633 Let represent the highest UID that the client knows about 634 in this mailbox. Since UIDs are allocated in strictly ascending 635 order, this is simply the UID of the last message in the mailbox that 636 the client knows about. Let represent 's UID 637 plus one. Let represent a list consisting of all the 638 FETCH data item items that the implementation considers to be part of 639 the descriptor; at a minimum this is just the FLAGS data item, but 640 it usually also includes BODYSTRUCTURE and RFC822.SIZE. At this step 641 SHOULD NOT include RFC822. 643 With no further information, the client can issue the following 644 two commands: 645 tag1 UID FETCH :* 646 tag2 UID FETCH 1: FLAGS 648 The first command will request some information about "new" messages 649 (i.e. messages received by the server since the last synchronization). 650 It will also allow the client to build a message number to UID map 651 (only for new messages). The second command allows the client to 652 1) update cached flags for old messages; 653 2) find out which old messages got expunged; 654 3) build a mapping between message numbers and UIDs (for old messages). 656 The order here is significant. We want the server to start returning 657 the list of new message descriptors as fast as it can, so that the 658 client can start issuing more FETCH commands, so we start out by 659 asking for the descriptors of all the messages we know the client 660 cannot possibly have cached yet. The second command fetches the 661 information we need to determine what changes may have occurred to 662 messages that the client already has cached. Note, that the latter 663 command should only be issued if the UIDNEXT value cached by the client 664 differs from the one returned by the server. Once the client has 665 issued these two commands, there's nothing more the client can do 666 with this mailbox until the responses to the first command start 667 arriving. A clever synchronization program might use this time to 668 fetch its local cache state from disk, or start the process of 669 synchronizing another mailbox. 671 Example of the first FETCH: 672 C: A011 UID fetch 131:* (FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE) 673 S: ... 675 The second FETCH command will result in nil or more untagged fetch 676 responses. Each response will have a corresponding UID FETCH data item. 677 All messages that didn't have a matching untagged FETCH response 678 MUST be removed from the local cache. 680 For example, if the had a value 15000 and the local cache 681 contained 3 messages with the UIDs 12, 777 and 14999 respectively, than 682 after receiving the following responses from the server: 684 S: * 1 FETCH (UID 12 FLAGS (\Seen)) 685 S: * 2 FETCH (UID 777 FLAGS (\Answered \Deleted)) 687 the client must remove the message with UID 14999 from its local cache. 689 Note: If the client is not interested in flag changes (i.e. the client 690 only wants to know which old messages are still on the server), the second 691 FETCH command can be substituted with: 692 tag2 UID SEARCH UID 1: 694 This command will generate less traffic. However an implementor should be 695 aware that in order to build the mapping table from message numbers to UIDs 696 the output of the SEARCH command MUST be sorted first, because there is 697 no requirement for a server to return UIDs in SEARCH response in the ascending 698 order. 700 5.3.2. Searching for "interesting" messages. 702 This step is either performed entirely on the client (from the information received 703 in step 5.3.1), after performing additional searches on the server or both. 704 The decision on what is an "interesting" message is up to the client software 705 and the human. One easy criterion that should probably be implemented in any 706 client is whether the message is "too big" for automatic retrieval, where "too big" 707 is a parameter defined in the client's configuration. 709 Another commonly used criteria is the age of a message. For example, the client 710 may choose to download only messages received in the last week (in this case, 711 would be today's date minus 7 days): 713 tag3 UID SEARCH UID SINCE 715 Keep in mind that a date search disregards time and timezone. 716 The client can avoid doing this search if it specified INTERNALDATE in 717 on step 5.3.1. If the client did, it can perform the search itself. 719 At this step the client also decides what kind of information about a particular 720 message to fetch from the server. In particular, even for a message that is considered 721 to be "too big" the client MAY choose to fetch some part(s) of it. For example, 722 if the message is a multipart/mixed containing a text part and a MPEG attachment, 723 there is no reason for the client not to fetch the text part. The decision of which 724 part should or should not be fetched can be based on the information received in 725 BODYSTRUCTURE FETCH response data item (i.e. if BODYSTRUCTURE was included in 726 on step 5.3.1). 728 5.3.3. Populating cache with "interesting" messages. 730 Once the client found out which messages are "interesting", the client 731 can start issuing appropriate FETCH commands for "interesting" messages or 732 bodyparts thereof. 734 It is important to note that fetching a message into the disconnected 735 client's local cache does NOT imply that the human has (or even will) 736 read the message. Thus, the synchronization program for a 737 disconnected client should always be careful to use the .PEEK 738 variants of the FETCH data items that implicitly set the \Seen flag. 740 Once the last descriptor has arrived and the last FETCH command has 741 been issued, the client simply needs to process the incoming fetch 742 items, using them to update the local message cache. 744 In order to avoid deadlock problems, the client must give processing 745 of received messages priority over issuing new FETCH commands during 746 this synchronization process. This may necessitate temporary local 747 queuing of FETCH requests that cannot be issued without causing a 748 deadlock. In order to achieve the best use of the "expensive" network 749 connection, the client will almost certainly need to pay careful 750 attention to any flow-control information that it can obtain from the 751 underlying transport connection (usually a TCP connection). 753 Example: After fetching a message BODYSTRUCTURE the client discovers 754 a complex MIME message. Than it decides to fetch MIME headers 755 of the nested MIME messages and some body parts. 757 C: A011 UID fetch 11 (BODYSTRUCTURE) 758 S: ... 759 C: A012 UID fetch 11 (BODY[HEADER] BODY[1.MIME] BODY[1.1.MIME] 760 BODY[1.2.MIME] BODY[2.MIME] BODY[3.MIME] BODY[4.MIME] BODY[5.MIME] 761 BODY[6.MIME] BODY[7.MIME] BODY[8.MIME] BODY[9.MIME] BODY[10.MIME] 762 BODY[11.MIME] BODY[12.MIME] BODY[13.MIME] BODY[14.MIME] BODY[15.MIME] 763 BODY[16.MIME] BODY[17.MIME] BODY[18.MIME] BODY[19.MIME] BODY[20.MIME] 764 BODY[21.MIME]) 765 S: ... 766 C: A013 UID fetch 11 (BODY[1.1] BODY[1.2]) 767 S: ... 768 C: A014 UID fetch 11 (BODY[3] BODY[4] BODY[5] BODY[6] BODY[7] BODY[8] 769 BODY[9] BODY[10] BODY[11] BODY[13] BODY[14] BODY[15] BODY[16] 770 BODY[21]) 771 S: ... 773 5.3.4. User initiated synchronization 775 After the client finished the main synchronization that was described in 776 5.3.1-5.3.3 the user may optionally request additional synchronization steps 777 while the client is still online. This is not any different from the process 778 described in 5.3.2 and 5.3.3. 780 Typical examples are: 781 1) fetch all messages selected in UI. 782 2) fetch all messages marked as \Flagged on the server. 784 5.4. Special case: descriptor-only synchronization 786 For some mailboxes, fetching the descriptors might be the entire 787 synchronization step. Practical experience with IMAP has shown that 788 a certain class of mailboxes (e.g., "archival" mailboxes) are used 789 primarily for long-term storage of important messages that the human 790 wants to have instantly available on demand but does not want 791 cluttering up the disconnected client's cache at any other time. 792 Messages in this kind of mailbox would be fetched exclusively by 793 explicit actions queued by the local MUA. Thus, the only 794 synchronization that is necessary for a mailbox of this kind is 795 fetching the descriptor information that the human will use to 796 identify messages that should be explicitly fetched. 798 Special mailboxes that receive traffic from a high volume, low 799 priority mailing list might also be in this category, at least when 800 the human is in a hurry. 802 5.5. Special case: fast new-only synchronization 804 In some cases the human might be in such a hurry that s/he doesn't 805 care about changes to old messages, just about new messages. In this 806 case, the client can skip the UID FETCH command that obtains the 807 flags and UIDs for old messages (1:). 809 5.6. Special case: blind FETCH 811 In some cases the human may know (for whatever reason) that s/he 812 always wants to fetch any new messages in a particular mailbox, 813 unconditionally. In this case, the client can just fetch the 814 messages themselves, rather than just the descriptors, by using a 815 command like: 816 tag1 UID FETCH :* (FLAGS RFC822.PEEK) 818 Note, that this example ignores the fact that the messages can 819 be arbitrary long. The disconnected client MUST always check 820 for message size before downloading, unless explicitly told otherwise. 821 A good behaving client should use instead something like the following: 823 1) Issue "tag1 UID FETCH :* (FLAGS RFC822.SIZE)" 824 2) From the message sizes returned in step 1 construct UID set 825 826 3) Issue "tag2 UID FETCH (RFC822.PEEK)" 828 or 830 1) Issue "tag1 UID FETCH :* (FLAGS)" 831 2) Construct UID set from the responses of 1) 832 3) Issue "tag2 SEARCH UID SMALLER " 833 Construct UID set from the result of 834 the SEARCH command. 835 4) Issue "tag3 UID FETCH (RFC822.PEEK)" 837 6. Implementation considerations 839 Below are listed some common implementation problems that should be 840 considered when implementing a disconnected client. 842 golden rules that should be considered when implementing 843 a good disconnected IMAP client. 845 <<*>> 846 1) Don't reorder operations during synchronization. 848 It is not always safe to reorder operations during synchronization, 849 because some operations may have dependencies. So if in doubt, don't do that. 850 The following example demonstrate this: 852 Example 1: The user copies a message out of a mailbox and then deletes 853 the mailbox. 855 C: A001 SELECT Old-Mail 856 S: ... 857 C: A002 UID COPY 111 ToDo 858 S: A002 OK [COPYUID 1022843345 111 94] Copy completed 859 ... 860 C: A015 CLOSE 861 S: A005 OK Completed 862 C: A016 DELETE Old-Mail 863 S: A016 OK Mailbox deletion completed successfully 865 If the client performs DELETE (tag A016) first and COPY (tag A002) second, 866 than the COPY fails. 868 << Describe one case when it is safe to reorder: the disconnected client 869 doesn't allow to perform DELETE and RENAME while offline and EXPUNGE 870 is never used (UID EXPUNGE is used instead or its emulation as described 871 in 5.2.3 >> 873 2) Implementing fake UIDs on the client. 875 A message scheduled to be uploaded has no UID, as UIDs are selected by 876 the server. The client may implement fake UIDs internally in order to 877 reference not yet uploaded messages in further operations. For example, 878 message was scheduled to be uploaded and later marked deleted or copied 879 to another mailbox). However, the client MUST NOT under any circumstances 880 sent these fake UIDs to the server. Also, client implementors should 881 be reminded that according to [IMAP4] an UID is a 32bit unsigned integer 882 excluding 0. So, both 4294967295 and 2147483648 are valid UIDs and 0 and -1 883 are both invalid. Existing disconnected mail clients are known to send 884 "-1" as a message UID to the server during synchronization. 886 6.1. Error recovery during playback 888 Error recovery during synchronization is one of the trickiest parts 889 to get right. Below, we will discuss certain error conditions 890 and suggest possible choices to handle them: 892 1). Lost connection to the server. 894 The client MUST remember the current position in playback log and 895 replay it starting from the interrupted operation (<>) 896 next time it is connected to the same server. 898 2). Copying/appending messages to a mailbox that doesn't exist. 900 The user should be advised about the situation and be given 901 one of the following choices: 902 a). Try to recreate a mailbox; 903 b). Copy/upload messages to another mailbox; 904 c). Skip copy/upload. 905 d). Abort replay. 907 3). Copying/appending messages from, rename or get/change ACLs on 908 a mailbox that doesn't exist: 910 a). Skip operation 911 b). Abort replay 913 4). Message to perform operation on doesn't exist. 915 a). Skip operation 916 b). Abort replay 918 << To be completed later >> 920 Note 1: Several synchronization operations map to multiple IMAP commands 921 (for example "move" described in 5.2.2). The client must guaranty 922 atomicity of each such multistep operation. For example, 923 when performing "move" between two mailboxes on the same server, 924 if the server is unable to copy messages, the client MUST NOT set 925 \Deleted flag on the messages being copied, all the more expunging 926 them. However the client MAY consider that move operation succeeded 927 even if the server was unable to set \Deleted flag on copied messages. 929 Note 2: Many synchronization operations have "data" dependencies. 930 A failed operation should cause all dependent operations to fail as 931 well. The client should check that and MUST NOT try to perform 932 all dependent operations blindly (unless the user corrected the original 933 problem). For example, a message may be scheduled to be appended to 934 a mailbox on the server and than later on the same message may be copied 935 to another mailbox. If the APPEND operation fails, the client must not 936 attempt to copy message later on. (See also Section 6, example 1). 938 6.2. Quality of implementation issues. 940 Below listed some quality of implementation issues for disconnected clients. 941 They will help to write a disconnected client that works correctly, performs 942 synchronization as quickly as possible (and thus can make the user 943 happier as well as save her some money) and minimizes the server load: 945 1) Don't loose information. 947 2) Don't do work unless explicitly asked. Be flexible. Ask all questions 948 BEFORE starting synchronization, if possible. 950 3) Minimize traffic 952 The client MUST NOT issue a command if the client already received 953 the required information from the server. 955 The client MUST make use of UIDPLUS extension if it is supported 956 by the server. 958 4) Minimize number of round trips. 960 Round trips kill performance, especially on links with high latency. 961 Sections 5.2.2.5 and 6.2 give some advices how to minimize number of 962 round trips. 964 5) Perform some synchronization steps in parallel, if possible. 966 Several synchronization steps don't depend on each other and thus can 967 be performed in parallel. Because the server machine is usually more 968 powerful than the client machine and can perform some operations in 969 parallel, this may speed up the total time of synchronization. 971 In order to achieve such parallelization the client will have to open 972 more than one connection to the same server. Client writers should not 973 forget about non-trivial cost associated with establishing a TCP connection 974 and performing an authentication. The disconnected client MUST NOT use 975 a connection per each mailbox. In most cases it is sufficient to have 976 two connections. 978 Any mailbox synchronization MUST start with checking of the UIDVALIDITY 979 as described in section 5.1 of this document. The client MAY use STATUS 980 command to check UID Validity of a non selected mailbox. This is preferable 981 to opening many connections to the same server to perform synchronization 982 of multiple mailboxes simultaneously. As described in section 6.3.10 of 983 [IMAP4], this SHOULD NOT be used on the selected mailbox. 985 6.3. Optimizations 987 Some useful optimizations are described in this section. A disconnected 988 client that supports recommendations listed below will give the user 989 a more pleasant expirience. 991 1) Initial OK or PREATH responses may contain CAPABILITY response code 992 as described in section 7.1 of [IMAP4]. This response code gives 993 the same information as returned by CAPABILITY command. A disconnected 994 client that pays attention to this response code will be able 995 to avoid sending CAPABILITY command and will save a round trip. 997 << Keep mailboxes open during synchronization if possible >> 999 << More to be added later >> 1001 7. IMAP extensions that may help 1003 The following extensions can save traffic and/or number of round trips: 1005 1) The use of [UIDPLUS] is discussed in 5.1, 5.2.1, 5.2.2.1 and 5.2.4. 1007 2) The use of MULTIAPPEND and LITERAL+ extensions for uploading messages 1008 is discussed in 5.2.2.5. 1010 7.1. CONDSTORE extension 1012 An advance disconnected mail client should use [CONDSTORE] extension 1013 when it is supported by the server. The client must cache the value from 1014 HIGHESTMODSEQ OK response code received on mailbox opening and update 1015 it whenever the server sends MODSEQ FETCH data items. 1017 When the client opens the mailbox for synchronization it first compares 1018 UIDVALIDITY as described in step d)1) in section 4. If the cached 1019 UIDVALIDITY value matches the one returned by the server, the client 1020 MUST compare the cached value of HIGHESTMODSEQ with the one returned 1021 by the server. If the cached HIGHESTMODSEQ value also matches the 1022 one returned by the server, then the client MUST NOT fetch flags for 1023 cached messages, as they hasn't changed. If the value on the server 1024 is higher than the cached one, the client MUST use 1025 "SEARCH MODSEQ " to find all messages with flags 1026 changed since the last time the client was online and had the mailbox 1027 opened. 1029 In all cases the client still need to fetch information about new 1030 messages (if requested by the user) and discover which messages got 1031 expunged. 1033 Step d) ("Server-to-client synchronization") in section 4 in the presence 1034 of CONDSTORE extension is amended as follows: 1036 d) "Server-to-client synchronization" - for each mailbox that requires 1037 synchronization, do the following: 1039 1a) Check the mailbox UIDVALIDITY (see section 5.1 for more details). 1040 with SELECT/EXAMINE/STATUS. 1041 If UIDVALIDITY value returned by the server differs, 1042 the client MUST 1044 * empty the local cache of that mailbox; 1045 * remove any pending "actions" which refer to UIDs in 1046 that mailbox; 1047 * skip steps 1b and 2-II; 1049 1b) Check the mailbox HIGHESTMODSEQ. If the cached value is the same 1050 as the one returned by the server, skip fetching message flags 1051 on step 2-II (i.e. the client only has to find out which messages 1052 got expunged). 1054 2) Fetch the current "descriptors"; 1056 I) Discover new messages. 1058 II) Discover changes to old messages. 1060 3) Fetch the bodies of any "interesting" messages that the client 1061 doesn't already have. 1063 Example (HIGHESTMODSEQ value changed on the server while offline): 1064 C: A142 SELECT INBOX 1065 S: * 172 EXISTS 1066 S: * 1 RECENT 1067 S: * OK [UNSEEN 12] Message 12 is first unseen 1068 S: * OK [UIDVALIDITY 3857529045] UIDs valid 1069 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1070 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 1071 S: * OK [HIGHESTMODSEQ 20010715194045007] 1072 S: A142 OK [READ-WRITE] SELECT completed 1073 C: a SEARCH MODSEQ 20010715194032001 1074 S: * SEARCH 2 5 6 7 11 12 18 19 20 23 1075 S: a OK [MODSEQ 2,5:7,11:12,18:20,23 20010917162500] Search complete 1077 8. Security Considerations 1079 Security considerations are not discussed in this memo. 1081 9. References 1083 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 1084 Requirement Levels", RFC 2119, Harvard University, March 1997. 1086 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 1087 4rev1", RFC 2060, University of Washington, December 1996. 1089 [UIDPLUS] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1988. 1091 [LITERAL+] Myers, J. "IMAP4 non-synchronizing literals", RFC 2088, 1092 January 1997. 1094 [CONDSTORE] Melnikov, A., Hole, S., "IMAP Extension for Conditional 1095 STORE operation", Work in progress, 1096 draft-melnikov-imap-condstore-XX.txt, ACI WorldWide/MessagingDirect. 1098 [MULTIAPPEND] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - 1099 MULTIAPPEND EXTENSION", Work in progress, 1100 draft-crispin-imap-multiappend-XX.txt, University of Washington. 1102 [UNSELECT] Melnikov, A., "IMAP UNSELECT command", Work in progress, 1103 draft-melnikov-imap-unselect-XX.txt, MessagingDirect. 1105 << Add missing references: ACL? >> 1107 10. Acknowledgment 1109 This document is a revision of the draft-ietf-imap-disc-01.txt written 1110 by Rob Austein in November 1994. 1112 The editor appreciate comments posted by Mark Crispin to the IMAP mailing 1113 list and the comments and corrections and ideas received from Cyrus Daboo, 1114 John G. Myers and Chris Newman. 1116 The editor would also like to thank the developers of Netscape Messenger 1117 and Mozilla mail clients for providing examples of disconnected mail clients 1118 that served as a base for many recommendations in this document. 1120 11. Editor's Address 1122 Alexey Melnikov 1123 mailto: mel@messagingdirect.com 1125 ACI WorldWide/MessagingDirect 1126 59 Clarendon Road, Watford, 1127 Hertfordshire, United Kingdom, WD17 1FQ 1129 Phone: +44 1923 81 2877 1131 12. Full Copyright Statement 1133 Copyright (C) The Internet Society 2002. All Rights Reserved. 1135 This document and translations of it may be copied and furnished to 1136 others, and derivative works that comment on or otherwise explain it 1137 or assist in its implementation may be prepared, copied, published 1138 and distributed, in whole or in part, without restriction of any 1139 kind, provided that the above copyright notice and this paragraph 1140 are included on all such copies and derivative works. However, this 1141 document itself may not be modified in any way, such as by removing 1142 the copyright notice or references to the Internet Society or other 1143 Internet organizations, except as needed for the purpose of 1144 developing Internet standards in which case the procedures for 1145 copyrights defined in the Internet Standards process must be 1146 followed, or as required to translate it into languages other than 1147 English. 1149 The limited permissions granted above are perpetual and will not be 1150 revoked by the Internet Society or its successors or assigns. 1152 This document and the information contained herein is provided on an 1153 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1154 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1155 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1156 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1157 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.