idnits 2.17.1 draft-myers-imap-optimize-01.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-26) 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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 61 lines 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 are 2 instances 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 199: '...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 (July 1996) is 10147 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 information found for draft-crispin-imap-base-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IMAP4' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Myers 2 Internet Draft Carnegie Mellon 3 Document: draft-myers-imap-optimize-01.txt July 1996 5 IMAP4 OPTIMIZE-1 extension 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a 18 ``working draft'' or ``work in progress''. 20 To learn the current status of any Internet-Draft, please check the 21 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 23 munnari.oz.au. 25 A revised version of this draft document will be submitted to the RFC 26 editor as a Proposed Standard for the Internet Community. Discussion 27 and suggestions for improvement are requested. This document will 28 expire before December 1996. Distribution of this draft is 29 unlimited. 31 Internet DRAFT OPTIMIZE-1 July 22, 1996 33 1. Abstract 35 The OPTIMIZE-1 extension of the Internet Message Access Protocol 36 [IMAP4] provides a set of features intended to reduce the amount of 37 time and resources used by some client operations. The features in 38 OPTIMIZE-1 are primarily intended for disconnected-use clients. 40 2. Conventions Used in this Document 42 In examples, "C:" and "S:" indicate lines sent by the client and 43 server respectively. 45 3. Introduction and Overview 47 The OPTIMIZE-1 extension is present in any IMAP4 server 48 implementation which returns "OPTIMIZE-1" as one of the supported 49 capabilities to the CAPABILITY command. The OPTIMIZE-1 extension 50 contains two additional commands and additional data returned with 51 successful APPEND and COPY commands. 53 Clients that wish to use the features in OPTIMIZE-1 must of course 54 first test for the presence of the extension by issuing a CAPABILITY 55 command. Each of the features in OPTIMIZE-1 are optimizations; 56 clients can provide the same functionality, albeit more slowly, by 57 using commands in the base protocol. With each feature, this 58 document recommends a fallback approach to take when the OPTIMIZE-1 59 extension is not supported by the server. 61 Internet DRAFT OPTIMIZE-1 July 22, 1996 63 4. Features 65 4.1. GETUIDS Command 67 Arguments: starting uid 69 Data: untagged response: GETUIDS 71 Result: OK - getuids completed 72 BAD - command unknown or arguments invalid 74 The GETUIDS command returns information about UIDs contained in 75 the mailbox. One untagged GETUIDS response is returned. 77 If there is no message in the mailbox with a UID greater than or 78 equal to the starting UID, the untagged GETUIDS response contains 79 no arguments. 81 If there exists at least one message with a UID greater than or 82 equal to the starting UID, the untagged GETUIDS response contains 83 the lowest message sequence number with a UID greater than or 84 equal to the starting UID, followed by a message set. The message 85 set must contain the UIDs of every message in the mailbox with a 86 UID greater than or equal to the starting UID. The message set 87 must not contain the symbol '*', the UID of any message which 88 previously existed but has since been deleted, or any UID less 89 than the starting UID or greater than the UID of the last message 90 in the mailbox. The UIDs in the message set must be in strictly 91 ascending order. 93 Upon receiving the untagged GETUIDS response, the client knows 94 that any message in its cache with a UID greater than or equal to 95 the starting UID and not present in a returned message set has 96 been expunged. 98 If the server does not support the OPTIMIZE-1 capability, the 99 client should fall back to using the UID FETCH starting-uid:* UID 100 command, where starting-uid is the starting UID. 102 Example: C: A003 GETUIDS 3475 103 S: * GETUIDS 17 3509:3519,3525,3590:3599 104 S: A003 OK GETUIDS completed 105 C: A004 GETUIDS 4000 106 S: * GETUIDS 107 S: A004 OK GETUIDS completed 108 Internet DRAFT OPTIMIZE-1 July 22, 1996 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. permision 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: * EXPUNGE 3 140 S: * EXPUNGE 3 141 S: * EXPUNGE 3 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 158 Internet DRAFT OPTIMIZE-1 July 22, 1996 160 C: Subject: afternoon meeting 161 C: To: mooch@owatagu.siam.edu 162 C: Message-Id: 163 C: MIME-Version: 1.0 164 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 165 C: 166 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 167 C: 168 S: A003 OK [APPENDUID 38505 3955] APPEND completed 170 4.4. COPYUID response code 172 Successful COPY and UID COPY commands return a COPYUID response code 173 in the tagged OK response whenever at least one message was copied. 174 The COPYUID response code contains as an argument the UIDVALIDITY of 175 the appended-to mailbox, a message set containing the UIDs of the 176 messages copied to the destination mailbox, in the order they were 177 copied, and a message containing the UIDs assigned to the copied 178 messages, in the order they were assigned. Neither of the message 179 sets may contain extraneous UIDs or the symbol '*'. 181 If the server does not support the OPTIMIZE-1 capability, the client 182 can only discover this information by selecting the destination 183 mailbox and issuing FETCH commands. 185 Example: C: A003 COPY 2:4 MEETING 186 S: A003 OK [COPYUID 38505 304,319:320 3956:3958] Done 187 C: A003 UID COPY 305:310 MEETING 188 S: A003 OK Done 190 5. Formal Syntax 192 The following syntax specification uses the augmented Backus-Naur 193 Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. 194 Non-terminals referenced but not defined below are as defined by 195 [IMAP4]. 197 Except as noted otherwise, all alphabetic characters are case- 198 insensitive. The use of upper or lower case characters to define 199 token strings is for editorial clarity only. Implementations MUST 200 accept these strings in a case-insensitive fashion. 202 getuids ::= "GETUIDS" SPACE uniqueid 204 getuids_data ::= "GETUIDS" [ SPACE nz_number SPACE set ] 205 Internet DRAFT OPTIMIZE-1 July 22, 1996 207 literal ::= "{" number ["+"] "}" CRLF *CHAR8 208 ;; Number represents the number of CHAR8 octets 210 resp_code_apnd ::= "APPENDUID" SPACE nz_number SPACE uniqueid 212 resp_code_copy ::= "COPYUID" SPACE nz_number SPACE set SPACE set 214 uid_expunge ::= "UID" SPACE "EXPUNGE" SPACE set 216 6. References 218 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 219 draft-crispin-imap-base-XX.txt, University of Washington, April 1996. 221 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 222 Messages", STD 11, RFC 822. 224 7. Security Considerations 226 There are no known security issues with this extension. 228 8. Author's Address 230 John G. Myers 231 Carnegie-Mellon University 232 5000 Forbes Ave. 233 Pittsburgh PA, 15213-3890 235 Email: jgm+@cmu.edu 236 Internet DRAFT OPTIMIZE-1 July 22, 1996 238 TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss 240 Status of this Memo ............................................... i 241 1. Abstract ..................................................... 2 242 2. Conventions Used in this Document ............................ 2 243 3. Introduction and Overview .................................... 2 244 4. Features ..................................................... 3 245 4.1. GETUIDS Command .............................................. 3 246 4.2. UID EXPUNGE Command .......................................... 4 247 4.3. APPENDUID response code ...................................... 4 248 4.4. COPYUID response code ........................................ 5 249 5. Formal Syntax ................................................ 5 250 6. References ................................................... 6 251 7. Security Considerations ...................................... 6 252 8. Author's Address ............................................. 6