The RFC Archive
 The RFC Archive   RFC 1733   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 1733

Distributed Electronic Mail Models in IMAP4

Last modified on Tuesday, December 20th, 1994

Permanent link to RFC 1733
Search GitHub Wiki for RFC 1733
Show other RFCs mentioning RFC 1733







Network Working Group                                         M. Crispin
Request for Comments: 1733                      University of Washington
Category: Informational                                  December 1994


              DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4


 Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.


Distributed Electronic Mail Models

   There are three fundamental models of client/server email: offline,
   online, and disconnected use.  IMAP4 can be used in any one of these
   three models.

   The offline model is the most familiar form of client/server email
   today, and is used by protocols such as POP-3 (RFC 1225) and UUCP.
   In this model, a client application periodically connects to a
   server.  It downloads all the pending messages to the client machine
   and deletes these from the server.  Thereafter, all mail processing
   is local to the client.  This model is store-and-forward; it moves
   mail on demand from an intermediate server (maildrop) to a single
   destination machine.

   The online model is most commonly used with remote filesystem
   protocols such as NFS.  In this model, a client application
   manipulates mailbox data on a server machine.  A connection to the
   server is maintained throughout the session.  No mailbox data are
   kept on the client; the client retrieves data from the server as is
   needed.  IMAP4 introduces a form of the online model that requires
   considerably less network bandwidth than a remote filesystem
   protocol, and provides the opportunity for using the server for CPU
   or I/O intensive functions such as parsing and searching.

   The disconnected use model is a hybrid of the offline and online
   models, and is used by protocols such as PCMAIL (RFC 1056).  In this
   model, a client user downloads some set of messages from the server,
   manipulates them offline, then at some later time uploads the
   changes.  The server remains the authoritative repository of the
   messages.  The problems of synchronization (particularly when
   multiple clients are involved) are handled through the means of
   unique identifiers for each message.



Crispin                                                      PAGE 1 top


RFC 1733 IMAP4 - Model December 1994 Each of these models have their own strengths and weaknesses: Feature Offline Online Disc ------- ------- ------ ---- Can use multiple clients NO YES YES Minimum use of server connect time YES NO YES Minimum use of server resources YES NO NO Minimum use of client disk resources NO YES NO Multiple remote mailboxes NO YES YES Fast startup NO YES NO Mail processing when not online YES NO YES Although IMAP4 has its origins as a protocol designed to accommodate the online model, it can support the other two models as well. This makes possible the creation of clients that can be used in any of the three models. For example, a user may wish to switch between the online and disconnected models on a regular basis (e.g. owing to travel). IMAP4 is designed to transmit message data on demand, and to provide the facilities necessary for a client to decide what data it needs at any particular time. There is generally no need to do a wholesale transfer of an entire mailbox or even of the complete text of a message. This makes a difference in situations where the mailbox is large, or when the link to the server is slow. More specifically, IMAP4 supports server-based RFC 822 and MIME processing. With this information, it is possible for a client to determine in advance whether it wishes to retrieve a particular message or part of a message. For example, a user connected to an IMAP4 server via a dialup link can determine that a message has a 2000 byte text segment and a 40 megabyte video segment, and elect to fetch only the text segment. In IMAP4, the client/server relationship lasts only for the duration of the TCP connection. There is no registration of clients. Except for any unique identifiers used in disconnected use operation, the client initially has no knowledge of mailbox state and learns it from the IMAP4 server when a mailbox is selected. This initial transfer is minimal; the client requests additional state data as it needs. As noted above, the choice for the location of mailbox data depends upon the model chosen. The location of message state (e.g. whether or not a message has been read or answered) is also determined by the model, and is not necessarily the same as the location of the mailbox data. For example, in the online model message state can be co- located with mailbox data; it can also be located elsewhere (on the client or on a third agent) using unique identifiers to achieve Crispin PAGE 2 top

RFC 1733 IMAP4 - Model December 1994 common reference across sessions. The latter is particularly useful with a server that exports public data such as netnews and does not maintain per-user state. The IMAP4 protocol provides the generality to implement these different models. This is done by means of server and (especially) client configuration, and not by requiring changes to the protocol or the implementation of the protocol. Security Considerations Security issues are not discussed in this memo. Author's Address: Mark R. Crispin Networks and Distributed Computing, JE-30 University of Washington Seattle, WA 98195 Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU Crispin PAGE 3 top

Distributed Electronic Mail Models in IMAP4 RFC TOTAL SIZE: 6205 bytes PUBLICATION DATE: Tuesday, December 20th, 1994 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 1733: The IETF Trust, Tuesday, December 20th, 1994
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement