FM / rfc

/opt/cpanel/ea-libc-client/share/docs/rfc/

/opt/cpanel/ea-libc-client/share/docs/rfc

Name	Size	Mode	Actions
README	2337	0644	edit dl rm
rfc1732.txt	9276	0644	edit dl rm
rfc1733.txt	6205	0644	edit dl rm
rfc2061.txt	5867	0644	edit dl rm
rfc2062.txt	14042	0644	edit dl rm
rfc2087.txt	8542	0644	edit dl rm
rfc2088.txt	4052	0644	edit dl rm
rfc2177.txt	6770	0644	edit dl rm
rfc2180.txt	24750	0644	edit dl rm
rfc2193.txt	16248	0644	edit dl rm
rfc2195.txt	10468	0644	edit dl rm
rfc2221.txt	9251	0644	edit dl rm
rfc2342.txt	19489	0644	edit dl rm
rfc2683.txt	56300	0644	edit dl rm
rfc2971.txt	14670	0644	edit dl rm
rfc3348.txt	11868	0644	edit dl rm
rfc3501.txt	227638	0644	edit dl rm
rfc3502.txt	13379	0644	edit dl rm
rfc3503.txt	16937	0644	edit dl rm
rfc3516.txt	14598	0644	edit dl rm
rfc3656.txt	35509	0644	edit dl rm
rfc3691.txt	8436	0644	edit dl rm
rfc4314.txt	56599	0644	edit dl rm
rfc4315.txt	16629	0644	edit dl rm
rfc4422.txt	73206	0644	edit dl rm
rfc4466.txt	33752	0644	edit dl rm
rfc4467.txt	36714	0644	edit dl rm
rfc4468.txt	28614	0644	edit dl rm
rfc4469.txt	21822	0644	edit dl rm
rfc4505.txt	16599	0644	edit dl rm
rfc4549.txt	75417	0644	edit dl rm
rfc4551.txt	50265	0644	edit dl rm
rfc4616.txt	20270	0644	edit dl rm
rfc4731.txt	15431	0644	edit dl rm
rfc4752.txt	22133	0644	edit dl rm
rfc4790.txt	55591	0644	edit dl rm
rfc4959.txt	12284	0644	edit dl rm
rfc4978.txt	17554	0644	edit dl rm
rfc5032.txt	8921	0644	edit dl rm
rfc5051.txt	14965	0644	edit dl rm
rfc5092.txt	65197	0644	edit dl rm
rfc5161.txt	12220	0644	edit dl rm
rfc5162.txt	51620	0644	edit dl rm
rfc5234.txt	26359	0644	edit dl rm

Edit: /opt/cpanel/ea-libc-client/share/docs/rfc/rfc1733.txt (6205B)

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]

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]

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]

cmd: