idnits 2.17.1 draft-ietf-imap-disc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1994) is 10898 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Austein 3 Internet Draft: IMAP4 Disconnected Access Epilogue Technology 4 Document: internet-drafts/draft-ietf-imap-disc-00.txt June 1994 6 SYNCHRONIZATION OPERATIONS FOR DISCONNECTED IMAP4 CLIENTS 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 This is a draft document of the IETF IMAP Working Group. A revised 27 version of this draft document will be submitted to the RFC editor as 28 an Informational RFC for the Internet Community. Discussion and 29 suggestions for improvement are requested, and should be sent to 30 imap@CAC.Washington.EDU. This document will expire before 31 31 November 1994. 33 This note attempts to address some of the issues involved in building 34 a disconnected IMAP4 client. In particular, it deals with the issues 35 of what might be called the "driver" portion of the synchronization 36 tool: the portion of the code responsible for issuing the correct set 37 of IMAP4 commands to synchronize the disconnected client in the way 38 that is most likely to make the human who uses the disconnected 39 client happy. 41 This memo is for informational use and does not constitute a 42 standard. Distribution of this memo is unlimited. 44 1. DESIGN PRINCIPLES 46 All mailbox state or content information stored on the disconnected 47 client should be viewed strictly as a cache of the state of the 48 server. The "master" state remains on the server, just as it would 49 with an interactive IMAP4 client. The one exception to this rule is 50 that information about the state of the disconnected client's cache 51 remains on the disconnected client: that is, unlike the equivilent 52 case in the DMSP protocol, the IMAP4 server is not responsible for 53 remembering the state of the disconnected IMAP4 client. 55 We assume that a disconnected client is a client that, for whatever 56 reason, wants to minimize the length of time that it is "on the 57 phone" to the IMAP4 server. Often this will be because the client is 58 using a dialup connection, possibly with very low bandwidth, but 59 sometimes it might just be that the human is in a hurry to catch an 60 airplane, or some other event beyond our control. Whatever the 61 reason, we assume that we must make efficient use of the network 62 connection, both in the usual sense (not generating spurious traffic) 63 and in the sense that we would prefer not to have the connection 64 sitting idle while the client and/or the server is performing 65 strictly local computation or I/O. Another, perhaps simpler way of 66 stating this is that we assume that network connections are 67 "expensive". 69 Practical experience with existing disconnected mail systems 70 (PCMAIL/DMSP) has shown that there is no single synchronization 71 strategy that is appropriate for all cases. Different humans have 72 different preferences, and the same human's preference will vary 73 depending both on external circumstance (how much of a hurry the 74 human is in today) and on the value that the human places on the 75 messages being transfered. The point here is that there is no way 76 that the synchronization program can guess exactly what the human 77 wants to do, so the human will have to provide some guidance. 79 Taken together, the preceeding two principles lead to the conclusion 80 that the synchronization program must make its decisions based on 81 some kind of configuration file provided by the human, but almost 82 certainly should not pause for I/O with the human during the middle 83 of the synchronization process. The human will almost certainly have 84 several different configurations for the synchronization program, for 85 different circumstances. 87 Automated support for helping naive humans write better configuration 88 files would be a good thing, but writing such tools is outside the 89 scope of this discussion. 91 Since a disconnected client has no way of knowing what changes might 92 have occured to the mailbox while it was disconnected, message 93 numbers are not useful to a disconnected client. All disconnected 94 client operations should be performed using UIDs, so that the client 95 can be sure that it and the server are talking about the same 96 messages during the synchronization process. It is permissible, but 97 probably not useful, for a disconnected client to use message numbers 98 once it has obtained a valid current mapping between UIDs and message 99 numbers. 101 2. OVERALL PICTURE OF SYNCHRONIZATION 103 The basic strategy for "normal" synchronization is pretty simple, and 104 closely follows the strategy used by a disconnected DMSP client 105 (terminology explained below): 107 a) Process any "actions" that were pending on the client; 109 b) Fetch the current list of "interesting" mailboxes; 111 c) For each mailbox, fetch the current "descriptors"; 113 d) For each mailbox, fetch the bodies of any "interesting" 114 messages that the client doesn't already have. 116 Explanation: 118 a) "Actions" are queued requests that were made by the human to the 119 client's MUA software while the client was disconnected. Expected 120 requests are commands like COPY, STORE, EXPUNGE, CREATE. FETCH 121 commands may also show up as actions, if the MUA allows the human 122 to explicitly fetch the body of a particular message that was 123 skipped by the normal synchronization process. In general, any 124 IMAP4 command can show up as an action, as can a few things that 125 are not IMAP4 commands at all, such as requests to send a newly 126 composed message via SMTP. 128 The list of actions should be ordered. Eg, if the human deletes 129 message A1 in mailbox A, then expunges mailbox A, then deletes 130 message A2 in mailbox A, the human will expect that message A1 is 131 gone and that message A2 is still present but is now deleted. 133 By processing all the actions before proceeding with 134 synchronization, we avoid having to compensate for the local MUA's 135 changes to the server's state. That is, once we have processed 136 all the pending actions, the steps that the client must take to 137 synchronize itself will be the same no matter where the changes to 138 the server's state originated. 140 b) The set of "interesting" mailboxes pretty much has to be 141 determined by the human. What mailboxes belong to this set may 142 vary between different IMAP4 sessions with the same server, 143 client, and human. 145 c) "Descriptors" is a DMSP term, borrowed here because it's both 146 easier to use and more precise than a specific list of IMAP4 FETCH 147 data items. Conceptually, a message's descriptor is that set of 148 information that allows the synchronization program to decide what 149 protocol actions are necessary to bring the local cache to the 150 desired state for this message; since this decision is really up 151 to the human, this information probably includes a at least a few 152 header fields intended for human consumption. Exactly what will 153 constitute a descriptor depends on the client implementation. At 154 a minimum, the descriptor contains the message's UID and FLAGS. 155 Other likely candidates are the RFC822.SIZE and BODYSTRUCTURE data 156 items and the RFC-822 From:, To:, Date:, Subject:, and Message-ID: 157 header lines. 159 Note that this step is also where the client finds out about 160 changes to the flags of messages that the client already has in 161 its local cache, as well as finding out about messages in the 162 local cache that no longer exist on the server (ie, messages that 163 have been expunged). 165 d) "interesting" messages are those messages that the synchronization 166 program thinks the human wants to have cached locally, based on 167 the configuration file and the data retrieved in step (c). 169 The rest of this discussion will focus primarily on the 170 synchronization issues for a single mailbox. 172 3. DETAILS OF "NORMAL" SYNCHRONIZATION OF A SINGLE MAILBOX 174 The most common form of synchronization is where the human trusts the 175 integrity of the client's copy of the state of a particular mailbox, 176 and simply wants to bring the client's cache up to date so that it 177 accurately reflects the mailbox's current state on the server. 179 Let represent the highest UID that the client knows about 180 in this mailbox. Since UIDs are allocated in strictly ascending 181 order, this is simply the UID of the last message in the mailbox that 182 the client knows about. Let represent 's UID 183 plus one. Let represent a list consisting of all the 184 FETCH data item items that the implementation considers to be part of 185 the descriptor; at a minimum this is just the FLAGS data item. 187 With no further information, the client can issue issue the following 188 two commands: 189 tag1 UID FETCH :* 190 tag2 UID FETCH 1: FLAGS 191 The order here is significant. We want the server to start returning 192 the list of new message descriptors as fast as it can, so that the 193 client can start issuing more FETCH commands, so we start out by 194 asking for the descriptors of all the messages we know the client 195 cannot possibly have cached yet. The second command fetches the 196 information we need to determine what changes may have occurred to 197 messages that the client already has cached. Once the client has 198 issued these two commands, there's nothing more the client can do 199 with this mailbox until the responses to the first command start 200 arriving. A clever synchronization program might use this time to 201 fetch its local cache state from disk, or start the process of 202 synchronizing another mailbox. 204 Once the descriptors start arriving, the client can start issuing 205 appropriate FETCH commands for "interesting" messages or bodyparts 206 thereof. The decision on what is an "interesting" message is up to 207 the client software and the human. One easy criterion that should 208 probably be implemented in any client is whether the message is "too 209 big" for automatic retrieval, where "too big" is a parameter defined 210 in the client's configuration file. 212 It is important to note that fetching a message into the disconnected 213 client's local cache does NOT imply that the human has (or even will) 214 read the message. Thus, the synchronization program for a 215 disconnected client should always be careful to use the .PEEK 216 variants of the FETCH data items that implicitly set the \Seen flag. 218 Once the last descriptor has arrived and the last FETCH command has 219 been issued, the client simply needs to process the incoming fetch 220 items, using them to update the local message cache. 222 In order to avoid deadlock problems, the client must give processing 223 of received messages priority over issuing new FETCH commands during 224 this synchronization process. This may necessitate temporary local 225 queuing of FETCH requests that cannot be issued without causing a 226 deadlock. In order to achive the best use of the "expensive" network 227 connection, the client will almost certainly need to pay careful 228 attention to any flow-control information that it can obtain from the 229 underlying transport connection (usually a TCP connection). 231 4. SPECIAL CASE: DESCRIPTOR-ONLY SYNCHRONIZATION 233 For some mailboxes, fetching the descriptors might be the entire 234 synchronization step. Practical experience with DMSP has shown that 235 a certain class of mailboxes (eg, "archival" mailboxes) are used 236 primarily for long-term storage of important messages that the human 237 wants to have instantly available on demand but does not want 238 cluttering up the disconnected client's cache at any other time. 239 Messages in this kind of mailbox would be fetched exclusively by 240 explicit actions queued by the local MUA. Thus, the only 241 synchronization that is necessary for a mailbox of this kind is 242 fetching the descriptor information that the human will use to 243 identify messages that should be explicitly fetched. 245 Special mailboxes that receive traffic from a high volume, low 246 priority mailing list might also be in this catagory, at least when 247 the human is in a hurry. 249 5. SPECIAL CASE: FAST NEW-ONLY SYNCHRONIZATION 251 In some cases the human might be in such a hurry that s/he doesn't 252 care about changes to old messages, just about new messages. In this 253 case, the client can skip the UID FETCH command that obtains the 254 flags and UIDs for old messages (1:). 256 6. SPECIAL CASE: BLIND FETCH 258 In some cases the human may know (for whatever reason) that s/he 259 always wants to fetch any new messages in a particular mailbox, 260 unconditionally. In this case, the client can just fetch the 261 messages themselves, rather than just the descriptors, by using a 262 command like: 263 tag1 UID FETCH :* (FLAGS RFC822.PEEK) 265 7. SPECIAL CASE: OPTIMIZING "MOVE" OPERATIONS 267 Practical experience with IMAP, DMSP, and other mailbox access 268 protocols that support multiple mailboxes suggests that moving a 269 message from one mailbox to another is an extremely common operation. 270 In IMAP4 a "move" operation is really a combination of a COPY 271 operation and a STORE +FLAGS (\Deleted) operation. This makes good 272 protocol sense for IMAP, but it leaves a simple-minded disconnected 273 client in the silly position of deleting and possibly expunging its 274 cached copy of a message, then fetching an identical copy via the 275 network. 277 Fortunately, there is a relatively easy way around this problem. By 278 including the Message-ID: header and the INTERNALDATE data item as 279 part of the descriptor, the client can check the descriptor of a 280 "new" message against messages that are already in its cache, and 281 avoid fetching the extra copy. Of course, it's possible that the 282 cost of checking to see if the message is already in the local cache 283 may exceed the cost of just fetching it, so this technique should not 284 be used blindly. If the MUA implements a "move" command, it make 285 special provisions to use this technique when it knows that a 286 copy/delete sequence is the result of a "move" command. 288 Since it's theoretically possible for this algorithm to find the 289 wrong message (given sufficiently malignant Message-ID headers), 290 implementors should provide a way to disable this optimization, both 291 permanently and on a message-by-message basis. 293 Security Considerations 295 Security considerations ane not discussed in this memo. 297 Author's Address: 299 Rob Austein 300 Epilogue Technology Corporation 301 268 Main Street, Suite 283 302 North Reading, MA 01864 304 Phone: (617) 245-0804 305 FAX: (617) 245-8122 307 Email: sra@epilogue.com