As per Relevance of the word provides, we have this rfc below:
Network Working Group M.
Request for Comments: 1733 University of
Category: Informational December 1994
DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
Distributed Electronic Mail
There are three fundamental models of client/server email: offline
online, and disconnected use. IMAP4 can be used in any one of
three models
The offline model is the most familiar form of client/server
today, and is used by protocols such as POP-3 (RFC 1225) and UUCP
In this model, a client application periodically connects to
server. It downloads all the pending messages to the client
and deletes these from the server. Thereafter, all mail
is local to the client. This model is store-and-forward; it
mail on demand from an intermediate server (maildrop) to a
destination machine
The online model is most commonly used with remote
protocols such as NFS. In this model, a client
manipulates mailbox data on a server machine. A connection to
server is maintained throughout the session. No mailbox data
kept on the client; the client retrieves data from the server as
needed. IMAP4 introduces a form of the online model that
considerably less network bandwidth than a remote
protocol, and provides the opportunity for using the server for
or I/O intensive functions such as parsing and searching
The disconnected use model is a hybrid of the offline and
models, and is used by protocols such as PCMAIL (RFC 1056). In
model, a client user downloads some set of messages from the server
manipulates them offline, then at some later time uploads
changes. The server remains the authoritative repository of
messages. The problems of synchronization (particularly
multiple clients are involved) are handled through the means
unique identifiers for each message
Crispin [Page 1]
RFC 1733 IMAP4 - Model December 1994
Each of these models have their own strengths and weaknesses
Feature Offline Online
------- ------- ------ ----
Can use multiple clients NO YES
Minimum use of server connect time YES NO
Minimum use of server resources YES NO
Minimum use of client disk resources NO YES
Multiple remote mailboxes NO YES
Fast startup NO YES
Mail processing when not online YES NO
Although IMAP4 has its origins as a protocol designed to
the online model, it can support the other two models as well.
makes possible the creation of clients that can be used in any of
three models. For example, a user may wish to switch between
online and disconnected models on a regular basis (e.g. owing
travel).
IMAP4 is designed to transmit message data on demand, and to
the facilities necessary for a client to decide what data it needs
any particular time. There is generally no need to do a
transfer of an entire mailbox or even of the complete text of
message. This makes a difference in situations where the mailbox
large, or when the link to the server is slow
More specifically, IMAP4 supports server-based RFC 822 and
processing. With this information, it is possible for a client
determine in advance whether it wishes to retrieve a
message or part of a message. For example, a user connected to
IMAP4 server via a dialup link can determine that a message has
2000 byte text segment and a 40 megabyte video segment, and elect
fetch only the text segment
In IMAP4, the client/server relationship lasts only for the
of the TCP connection. There is no registration of clients.
for any unique identifiers used in disconnected use operation,
client initially has no knowledge of mailbox state and learns it
the IMAP4 server when a mailbox is selected. This initial
is minimal; the client requests additional state data as it needs
As noted above, the choice for the location of mailbox data
upon the model chosen. The location of message state (e.g.
or not a message has been read or answered) is also determined by
model, and is not necessarily the same as the location of the
data. For example, in the online model message state can be co
located with mailbox data; it can also be located elsewhere (on
client or on a third agent) using unique identifiers to
Crispin [Page 2]
RFC 1733 IMAP4 - Model December 1994
common reference across sessions. The latter is particularly
with a server that exports public data such as netnews and does
maintain per-user state
The IMAP4 protocol provides the generality to implement
different models. This is done by means of server and (especially
client configuration, and not by requiring changes to the protocol
the implementation of the protocol
Security
Security issues are not discussed in this memo
Author's Address
Mark R.
Networks and Distributed Computing, JE-30
University of
Seattle, WA 98195
Phone: (206) 543-5762
EMail: MRC@CAC.Washington.
Crispin [Page 3]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
