About IMAP News and Events RFCs, Talks, and Papers Other Resources Search

Status of Disconnected Operation in IMAP

One of the important capabilities of IMAP4 is support for "disconnected" operation, wherein an email client may download a cache copy of selected messages, manipulate them while disconnected from the email server, and subsequently resynchronize its cached state with the message store on the server. A question has been raised about the viability of disconnected support in IMAP4, largely because there is an initial draft of a document on how to use IMAP4 facilities for disconnected operation which has not yet been completed.

The purpose of this note is to provide some background on the status of the protocol and the documents relating to disconnected operation. Several years ago there was a decision to have the detailed discussion of "how to use IMAP4 in disconnected mode" be a separate document, rather than part of the base specification. This would be an Informational, rather than standards track RFC. After a first draft was created, the author requested assistance in revising and finishing it, but that hasn't yet happened.

So it's true that the "disconnected usage guide" is not yet ready for prime time; however, the base IMAP4 specification is complete with respect to support for this mode of operation. The key concept for supporting disconnected operation in the protocol is the Unique IDentifier, or UID. Using UIDs, which persist across sessions, the client and server can unambiguously refer to the same message. In response to concerns about whether IMAP disconnected operation is viable at this point in time, the following observations can be made:

1. There have been no allegations that the IMAP4 UID mechanism is inadequate on the IMAP developers list.
2. There are already existence proofs of IMAP mailers supporting disconnected operation with and without IMAP4 UIDs, e.g. Siren Mail and Sun's ROAM client. Note that these have been done without benefit of the usage guide. Some early disconnected clients used Message-IDs for message identification, even though these are known to not be unique.
3. The fact that UIDs play the same role as message-IDs (but in a more reliable way) and that folks have done disconnected clients using both demonstrates that IMAP4 UIDs are sufficient to support disconnected operation.

1. There are some issues here, but there has been no suggestion that they invalidate the UID definition in the protocol itself.
2. Once you have a way to reliably identify a message in a folder across sessions, which is what UIDs give you, then you can think of offline and disconnected operation as two points on a continuum defined by latency between the client and server, and therefore you can differentiate the two modes based on cache management policies. (Some offline mailers even prefetch messages from local disk to minimize perceived latency; an IMAP client in online mode might want to prefetch body-part-zeros for the same reason. One can extend the same line of thought to disconnected...)
3. In the case of private folders there are two resync issues:
   • What if you have multiple pending disconnected sessions with potentially conflicting state-changes? Typical answer: latest state change replayed to the server wins. If it's a state change to a message that has already been expunged, it's ignored. Both these policies seem reasonable and are easy to implement.
   • Resync timing: when you reconnect to a server, you may want to defer some aspects of the state playback if you know that there are a lot of, e.g. saved messages to playback, and you know by waiting you can use a higher-speed link later. This is a quality of implemenation issue.

Back to IMAP Documents

Comments, Questions, Suggestions?
© 1996-2008 University of Washington
Last modified: Wed Jan 9 2008