rfc1733.txt (6205B)
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