idnits 2.17.1 draft-myers-imap-optimize-02.txt: ** The Abstract section seems to be numbered 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-19) 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 62 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 200: '...al clarity only. Implementations MUST...' 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 (November 1997) is 9652 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) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 15 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 J. Myers 3 Internet Draft Netscape Communications 4 Document: draft-myers-imap-optimize-02.txt November 1997 6 IMAP4 OPTIMIZE-1 extension 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 19 ``working draft'' or ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 1id-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 A revised version of this draft document will be submitted to the RFC 27 editor as a Proposed Standard for the Internet Community. Discussion 28 and suggestions for improvement are requested. This document will 29 expire before December 1996. Distribution of this draft is 30 unlimited. 32 Internet DRAFT OPTIMIZE-1 November 11, 1997 34 1. Abstract 36 The OPTIMIZE-1 extension of the Internet Message Access Protocol 37 [IMAP4] provides a set of features intended to reduce the amount of 38 time and resources used by some client operations. The features in 39 OPTIMIZE-1 are primarily intended for disconnected-use clients. 41 2. Conventions Used in this Document 43 In examples, "C:" and "S:" indicate lines sent by the client and 44 server respectively. 46 3. Introduction and Overview 48 The OPTIMIZE-1 extension is present in any IMAP4 server 49 implementation which returns "OPTIMIZE-1" as one of the supported 50 capabilities to the CAPABILITY command. The OPTIMIZE-1 extension 51 contains two additional commands and additional data returned with 52 successful APPEND and COPY commands. 54 Clients that wish to use the features in OPTIMIZE-1 must of course 55 first test for the presence of the extension by issuing a CAPABILITY 56 command. Each of the features in OPTIMIZE-1 are optimizations; 57 clients can provide the same functionality, albeit more slowly, by 58 using commands in the base protocol. With each feature, this 59 document recommends a fallback approach to take when the OPTIMIZE-1 60 extension is not supported by the server. 62 Internet DRAFT OPTIMIZE-1 November 11, 1997 64 4. Features 66 4.1. GETUIDS Command 68 Arguments: starting uid 70 Data: untagged response: GETUIDS 72 Result: OK - getuids completed 73 BAD - command unknown or arguments invalid 75 The GETUIDS command returns information about UIDs contained in 76 the mailbox. One untagged GETUIDS response is returned. 78 If there is no message in the mailbox with a UID greater than or 79 equal to the starting UID, the untagged GETUIDS response contains 80 no arguments. 82 If there exists at least one message with a UID greater than or 83 equal to the starting UID, the untagged GETUIDS response contains 84 the lowest message sequence number with a UID greater than or 85 equal to the starting UID, followed by a message set. The message 86 set must contain the UIDs of every message in the mailbox with a 87 UID greater than or equal to the starting UID. The message set 88 must not contain the symbol '*', any UID less than the starting 89 UID, or any UID not present in the mailbox. The UIDs in the 90 message set must be in strictly ascending order. 92 Upon receiving the untagged GETUIDS response, the client knows 93 that any message in its cache with a UID greater than or equal to 94 the starting UID and not present in a returned message set has 95 been expunged. 97 If the server does not support the OPTIMIZE-1 capability, the 98 client should fall back to using the UID FETCH starting-uid:* UID 99 command, where starting-uid is the starting UID. 101 Example: C: A003 GETUIDS 3475 102 S: * GETUIDS 17 3509:3519,3525,3590:3599 103 S: A003 OK GETUIDS completed 104 C: A004 GETUIDS 4000 105 S: * GETUIDS 106 S: A004 OK GETUIDS completed 108 Internet DRAFT OPTIMIZE-1 November 11, 1997 110 4.2. UID EXPUNGE Command 112 Arguments: message set 114 Data: untagged responses: EXPUNGE 116 Result: OK - expunge completed 117 NO - expunge failure (e.g. permission denied) 118 BAD - command unknown or arguments invalid 120 The UID EXPUNGE command permanently removes from the currently 121 selected mailbox all messages that both have the \Deleted flag set 122 and have a UID that is included in the specified message set. If 123 a message either does not have the \Deleted flag set or is has a 124 UID that is not included in the specified message set, it is not 125 affected. 127 This command may be used to ensure that a replayed EXPUNGE command 128 does not remove any messages that have been marked as \Deleted 129 between the time that the user requested the expunge operation and 130 the time the server processes the command. 132 If the server does not support the OPTIMIZE-1 capability, the 133 client should fall back to using the STORE command to temporarily 134 remove the \Deleted flag from messages it does not want to remove. 135 The client could alternatively fall back to using the EXPUNGE 136 command, risking the unintended removal of some messages. 138 Example: C: A003 UID EXPUNGE 3000:3002 139 S: * 3 EXPUNGE 140 S: * 3 EXPUNGE 141 S: * 3 EXPUNGE 142 S: A003 OK UID EXPUNGE completed 144 4.3. APPENDUID response code 146 Successful APPEND commands return an APPENDUID response code in the 147 tagged OK response. The APPENDUID response code contains as 148 arguments the UIDVALIDITY of the destination mailbox and the UID 149 assigned to the appended message. 151 If the server does not support the OPTIMIZE-1 capability, the client 152 can only discover this information by selecting the destination 153 mailbox and issuing FETCH commands. 155 Example: C: A003 APPEND saved-messages (\Seen) {310} 156 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 157 C: From: Fred Foobar 159 Internet DRAFT OPTIMIZE-1 November 11, 1997 161 C: Subject: afternoon meeting 162 C: To: mooch@owatagu.siam.edu 163 C: Message-Id: 164 C: MIME-Version: 1.0 165 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 166 C: 167 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 168 C: 169 S: A003 OK [APPENDUID 38505 3955] APPEND completed 171 4.4. COPYUID response code 173 Successful COPY and UID COPY commands return a COPYUID response code 174 in the tagged OK response whenever at least one message was copied. 175 The COPYUID response code contains as an argument the UIDVALIDITY of 176 the appended-to mailbox, a message set containing the UIDs of the 177 messages copied to the destination mailbox, in the order they were 178 copied, and a message containing the UIDs assigned to the copied 179 messages, in the order they were assigned. Neither of the message 180 sets may contain extraneous UIDs or the symbol '*'. 182 If the server does not support the OPTIMIZE-1 capability, the client 183 can only discover this information by selecting the destination 184 mailbox and issuing FETCH commands. 186 Example: C: A003 COPY 2:4 MEETING 187 S: A003 OK [COPYUID 38505 304,319:320 3956:3958] Done 188 C: A003 UID COPY 305:310 MEETING 189 S: A003 OK Done 191 5. Formal Syntax 193 The following syntax specification uses the augmented Backus-Naur 194 Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. 195 Non-terminals referenced but not defined below are as defined by 196 [IMAP4]. 198 Except as noted otherwise, all alphabetic characters are case- 199 insensitive. The use of upper or lower case characters to define 200 token strings is for editorial clarity only. Implementations MUST 201 accept these strings in a case-insensitive fashion. 203 getuids ::= "GETUIDS" SPACE uniqueid 205 getuids_data ::= "GETUIDS" [ SPACE nz_number SPACE set ] 207 Internet DRAFT OPTIMIZE-1 November 11, 1997 209 resp_code_apnd ::= "APPENDUID" SPACE nz_number SPACE uniqueid 211 resp_code_copy ::= "COPYUID" SPACE nz_number SPACE set SPACE set 213 uid_expunge ::= "UID" SPACE "EXPUNGE" SPACE set 215 6. References 217 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 218 4rev1", RFC 2060, University of Washington, December 1996. 220 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 221 Messages", STD 11, RFC 822. 223 7. Security Considerations 225 There are no known security issues with this extension. 227 8. Author's Address 229 John Gardiner Myers 230 Netscape Communications 231 501 East Middlefield Road 232 Mail Stop MV-029 233 Mountain View, CA 94043 235 Email: jgmyers@netscape.com 237 Internet DRAFT OPTIMIZE-1 November 11, 1997 239 TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss 241 Status of this Memo ............................................... i 242 1. Abstract ..................................................... 2 243 2. Conventions Used in this Document ............................ 2 244 3. Introduction and Overview .................................... 2 245 4. Features ..................................................... 3 246 4.1. GETUIDS Command .............................................. 3 247 4.2. UID EXPUNGE Command .......................................... 3 248 4.3. APPENDUID response code ...................................... 4 249 4.4. COPYUID response code ........................................ 5 250 5. Formal Syntax ................................................ 5 251 6. References ................................................... 6 252 7. Security Considerations ...................................... 6 253 8. Author's Address ............................................. 6