Terry Gray <email@example.com>
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
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
Regarding resynchronization policy:
- There have been no allegations that the IMAP4 UID mechanism is
inadequate on the IMAP developers list.
- 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
- 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
In summary, although the "guide to using IMAP4 in disconnected mode"
would be a helpful addition to implementors, there is ample evidence
that a successful implementation is possible without it, and that the
basic UID facility defined in the base IMAP4 (and IMAP4rev1) specification
- There are some issues here, but there has been no suggestion
that they invalidate the UID definition in the protocol itself.
- 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...)
- 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
- 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
© 1996 University of Washington