home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1733 < prev    next >
Text File  |  1994-12-20  |  6KB  |  172 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         M. Crispin
  8. Request for Comments: 1733                      University of Washington
  9. Category: Informational                                    December 1994
  10.  
  11.  
  12.               DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21.  
  22. Distributed Electronic Mail Models
  23.  
  24.    There are three fundamental models of client/server email: offline,
  25.    online, and disconnected use.  IMAP4 can be used in any one of these
  26.    three models.
  27.  
  28.    The offline model is the most familiar form of client/server email
  29.    today, and is used by protocols such as POP-3 (RFC 1225) and UUCP.
  30.    In this model, a client application periodically connects to a
  31.    server.  It downloads all the pending messages to the client machine
  32.    and deletes these from the server.  Thereafter, all mail processing
  33.    is local to the client.  This model is store-and-forward; it moves
  34.    mail on demand from an intermediate server (maildrop) to a single
  35.    destination machine.
  36.  
  37.    The online model is most commonly used with remote filesystem
  38.    protocols such as NFS.  In this model, a client application
  39.    manipulates mailbox data on a server machine.  A connection to the
  40.    server is maintained throughout the session.  No mailbox data are
  41.    kept on the client; the client retrieves data from the server as is
  42.    needed.  IMAP4 introduces a form of the online model that requires
  43.    considerably less network bandwidth than a remote filesystem
  44.    protocol, and provides the opportunity for using the server for CPU
  45.    or I/O intensive functions such as parsing and searching.
  46.  
  47.    The disconnected use model is a hybrid of the offline and online
  48.    models, and is used by protocols such as PCMAIL (RFC 1056).  In this
  49.    model, a client user downloads some set of messages from the server,
  50.    manipulates them offline, then at some later time uploads the
  51.    changes.  The server remains the authoritative repository of the
  52.    messages.  The problems of synchronization (particularly when
  53.    multiple clients are involved) are handled through the means of
  54.    unique identifiers for each message.
  55.  
  56.  
  57.  
  58. Crispin                                                         [Page 1]
  59.  
  60. RFC 1733                     IMAP4 - Model                 December 1994
  61.  
  62.  
  63.    Each of these models have their own strengths and weaknesses:
  64.  
  65.       Feature                               Offline Online  Disc
  66.       -------                               ------- ------  ----
  67.       Can use multiple clients               NO      YES     YES
  68.       Minimum use of server connect time     YES     NO      YES
  69.       Minimum use of server resources        YES     NO      NO
  70.       Minimum use of client disk resources   NO      YES     NO
  71.       Multiple remote mailboxes              NO      YES     YES
  72.       Fast startup                           NO      YES     NO
  73.       Mail processing when not online        YES     NO      YES
  74.  
  75.    Although IMAP4 has its origins as a protocol designed to accommodate
  76.    the online model, it can support the other two models as well.  This
  77.    makes possible the creation of clients that can be used in any of the
  78.    three models.  For example, a user may wish to switch between the
  79.    online and disconnected models on a regular basis (e.g. owing to
  80.    travel).
  81.  
  82.    IMAP4 is designed to transmit message data on demand, and to provide
  83.    the facilities necessary for a client to decide what data it needs at
  84.    any particular time.  There is generally no need to do a wholesale
  85.    transfer of an entire mailbox or even of the complete text of a
  86.    message.  This makes a difference in situations where the mailbox is
  87.    large, or when the link to the server is slow.
  88.  
  89.    More specifically, IMAP4 supports server-based RFC 822 and MIME
  90.    processing.  With this information, it is possible for a client to
  91.    determine in advance whether it wishes to retrieve a particular
  92.    message or part of a message.  For example, a user connected to an
  93.    IMAP4 server via a dialup link can determine that a message has a
  94.    2000 byte text segment and a 40 megabyte video segment, and elect to
  95.    fetch only the text segment.
  96.  
  97.    In IMAP4, the client/server relationship lasts only for the duration
  98.    of the TCP connection.  There is no registration of clients.  Except
  99.    for any unique identifiers used in disconnected use operation, the
  100.    client initially has no knowledge of mailbox state and learns it from
  101.    the IMAP4 server when a mailbox is selected.  This initial transfer
  102.    is minimal; the client requests additional state data as it needs.
  103.  
  104.    As noted above, the choice for the location of mailbox data depends
  105.    upon the model chosen.  The location of message state (e.g. whether
  106.    or not a message has been read or answered) is also determined by the
  107.    model, and is not necessarily the same as the location of the mailbox
  108.    data.  For example, in the online model message state can be co-
  109.    located with mailbox data; it can also be located elsewhere (on the
  110.    client or on a third agent) using unique identifiers to achieve
  111.  
  112.  
  113.  
  114. Crispin                                                         [Page 2]
  115.  
  116. RFC 1733                     IMAP4 - Model                 December 1994
  117.  
  118.  
  119.    common reference across sessions.  The latter is particularly useful
  120.    with a server that exports public data such as netnews and does not
  121.    maintain per-user state.
  122.  
  123.    The IMAP4 protocol provides the generality to implement these
  124.    different models.  This is done by means of server and (especially)
  125.    client configuration, and not by requiring changes to the protocol or
  126.    the implementation of the protocol.
  127.  
  128.  
  129. Security Considerations
  130.  
  131.    Security issues are not discussed in this memo.
  132.  
  133.  
  134. Author's Address:
  135.  
  136.    Mark R. Crispin
  137.    Networks and Distributed Computing, JE-30
  138.    University of Washington
  139.    Seattle, WA  98195
  140.  
  141.    Phone: (206) 543-5762
  142.  
  143.    EMail: MRC@CAC.Washington.EDU
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Crispin                                                         [Page 3]
  171.  
  172.