idnits 2.17.1 draft-myers-imap-optimize-00.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-03-29) 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 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 115 instances 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 201: '... MUST accept these strings in a case...' 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 10119 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: 13 errors (**), 0 flaws (~~), 3 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-00.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 9, 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 9, 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 109 Internet DRAFT OPTIMIZE-1 July 9, 1996 111 4.2. UID EXPUNGE Command 113 Arguments: message set 115 Data: untagged responses: EXPUNGE 117 Result: OK - expunge completed 118 NO - expunge failure (e.g. permision denied) 119 BAD - command unknown or arguments invalid 121 The UID EXPUNGE command permanently removes from the currently 122 selected mailbox all messages that both have the ted flag set and 123 have a UID that is included in the specified message set. If a 124 message either does not have the ted flag set or is has a UID that 125 is not included in the specified message set, it is not 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 ted between 129 the time that the user requested the expunge operation and the 130 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 ted flag from messages it does not want to remove. The 135 client could alternatively fall back to using the EXPUNGE command, 136 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 (n) {310} 156 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 157 C: From: Fred Foobar 158 C: Subject: afternoon meeting 160 Internet DRAFT OPTIMIZE-1 July 9, 1996 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 199 case-insensitive. The use of upper or lower case characters to 200 define token strings is for editorial clarity only. Implementations 201 MUST accept these strings in a case-insensitive fashion. 203 getuids ::= "GETUIDS" SPACE uniqueid 205 getuids_data ::= "GETUIDS" [ SPACE nz_number SPACE set ] 207 literal ::= "{" number ["+"] "}" CRLF *CHAR8 209 Internet DRAFT OPTIMIZE-1 July 9, 1996 211 ;; Number represents the number of CHAR8 octets 213 resp_code_apnd ::= "APPENDUID" SPACE nz_number SPACE uniqueid 215 resp_code_copy ::= "COPYUID" SPACE nz_number SPACE set SPACE set 217 uid_expunge ::= "UID" SPACE "EXPUNGE" SPACE set 219 6. References 221 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 222 draft-crispin-imap-base-XX.txt, University of Washington, April 1996. 224 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 225 Messages", STD 11, RFC 822. 227 7. Security Considerations 229 There are no known security issues with this extension. 231 8. Author's Address 233 John G. Myers 234 Carnegie-Mellon University 235 5000 Forbes Ave. 236 Pittsburgh PA, 15213-3890 238 Email: jgm+@cmu.edu 240 Internet DRAFT OPTIMIZE-1 July 9, 1996 242 Table of Contents 244 Status of this Memo 245 1. Abstract 246 2. Conventions Used in this Document 247 3. Introduction and Overview 248 4. Features 249 4.1. GETUIDS Command 250 4.2. UID EXPUNGE Command 251 4.3. APPENDUID response code 252 4.4. COPYUID response code 253 5. Formal Syntax 254 6. References 255 7. Security Considerations 256 8. Author's Address