Mercurial > hgrepos > hgweb.cgi > imapext
comparison docs/rfc/rfc1733.txt @ 0:ada5e610ab86
imap-2007e
author | yuuji@gentei.org |
---|---|
date | Mon, 14 Sep 2009 15:17:45 +0900 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
-1:000000000000 | 0:ada5e610ab86 |
---|---|
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 |