Synchronization Operations for Disconnected IMAP4 Clients
RFC 4549
Document | Type |
RFC - Informational
(June 2006; No errata)
Was draft-melnikov-imap-disc (individual in app area)
|
|
---|---|---|---|
Author | Alexey Melnikov | ||
Last updated | 2018-12-20 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4549 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
Send notices to | (None) |
Network Working Group A. Melnikov, Ed. Request for Comments: 4549 Isode Ltd. Category: Informational June 2006 Synchronization Operations for Disconnected IMAP4 Clients Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy. This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process. This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients. Melnikov Informational [Page 1] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006 Table of Contents 1. Introduction ....................................................3 1.1. Conventions Used in This Document ..........................3 2. Design Principles ...............................................3 3. Overall Picture of Synchronization ..............................4 4. Mailbox Synchronization Steps and Strategies ....................7 4.1. Checking UID Validity ......................................7 4.2. Synchronizing Local Changes with the Server ................8 4.2.1. Uploading Messages to the Mailbox ...................8 4.2.2. Optimizing "move" and "copy" Operations .............9 4.2.3. Replaying Local Flag Changes .......................14 4.2.4. Processing Mailbox Compression (EXPUNGE) Requests ..15 4.2.5. Closing a Mailbox ..................................17 4.3. Details of "Normal" Synchronization of a Single Mailbox ...18 4.3.1. Discovering New Messages and Changes to Old Messages ...........................................18 4.3.2. Searching for "Interesting" Messages. ..............20 4.3.3. Populating Cache with "Interesting" Messages. ......21 4.3.4. User-Initiated Synchronization .....................22 4.4. Special Case: Descriptor-Only Synchronization .............22 4.5. Special Case: Fast New-Only Synchronization ...............23 4.6. Special Case: Blind FETCH .................................23 5. Implementation Considerations ..................................24 5.1. Error Recovery during Playback ............................26 5.2. Quality of Implementation Issues ..........................28 5.3. Optimizations .............................................28 6. IMAP Extensions That May Help ..................................30 6.1. CONDSTORE Extension .......................................30 7. Security Considerations ........................................33 8. References .....................................................33 8.1. Normative References ......................................33 8.2. Informative References ....................................34 9. Acknowledgements ...............................................34 Melnikov Informational [Page 2] RFC 4549 Synch Ops for Disconnected IMAP4 Clients June 2006 1. Introduction Several recommendations presented in this document are generally applicable to all types of IMAP clients. However, this document tries to concentrate on disconnected mail clients [IMAP-MODEL]. It also suggests some IMAP extensions* that should be implemented by IMAP servers in order to make the life of disconnected clients easier. In particular, the [UIDPLUS] extension was specifically designed to streamline certain disconnected operations, like expunging, uploading, and copying messages (see Sections 4.2.1, 4.2.2.1, and 4.2.4). Readers of this document are also strongly advised to read RFC 2683 [RFC2683]. * Note that the functionality provided by the base IMAP protocol [IMAP4] is sufficient to perform basic synchronization. 1.1. Conventions Used in This Document In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. Long lines in examples are broken for editorial clarity.Show full document text