rfc2359.txt (10862B)
1 2 3 4 5 6 7 Network Working Group J. Myers 8 Request for Comments: 2359 Netscape Communications 9 Category: Standards Track June 1998 10 11 12 IMAP4 UIDPLUS extension 13 14 Status of this Memo 15 16 This document specifies an Internet standards track protocol for the 17 Internet community, and requests discussion and suggestions for 18 improvements. Please refer to the current edition of the "Internet 19 Official Protocol Standards" (STD 1) for the standardization state 20 and status of this protocol. Distribution of this memo is unlimited. 21 22 Copyright Notice 23 24 Copyright (C) The Internet Society (1998). All Rights Reserved. 25 26 IESG NOTE 27 28 The IMAP extension described here assumes a particular means of using 29 IMAP to support disconnected operation. However, this means of 30 supporting disconnected operation is not yet documented. Also, there 31 are multiple theories about how best to do disconnected operation in 32 IMAP, and as yet, there is no consensus on which one should be 33 adopted as a standard. 34 35 This document is being approved as a Proposed Standard because it 36 does not appear to have technical flaws in itelf. However, approval 37 of this document as a Proposed Standard should not be considered an 38 IETF endorsement of any particular means of doing disconnected 39 operation in IMAP. 40 41 Table of Contents 42 43 1. Abstract .............................................. 2 44 2. Conventions Used in this Document ..................... 2 45 3. Introduction and Overview ............................. 2 46 4. Features .............................................. 2 47 4.1. UID EXPUNGE Command ................................... 2 48 4.2. APPENDUID response code ............................... 3 49 4.3. COPYUID response code ................................. 4 50 5. Formal Syntax ......................................... 4 51 6. References ............................................ 4 52 7. Security Considerations ............................... 5 53 8. Author's Address ...................................... 5 54 9. Full Copyright Statement .............................. 6 55 56 57 58 Myers Standards Track [Page 1] 59 60 RFC 2359 IMAP4 UIDPLUS extension June 1998 61 62 63 1. Abstract 64 65 The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] 66 provides a set of features intended to reduce the amount of time and 67 resources used by some client operations. The features in UIDPLUS 68 are primarily intended for disconnected-use clients. 69 70 2. Conventions Used in this Document 71 72 In examples, "C:" and "S:" indicate lines sent by the client and 73 server respectively. 74 75 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 76 in this document are to be interpreted as defined in "Key words for 77 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 78 79 3. Introduction and Overview 80 81 The UIDPLUS extension is present in any IMAP4 server implementation 82 which returns "UIDPLUS" as one of the supported capabilities to the 83 CAPABILITY command. The UIDPLUS extension contains one additional 84 command and additional data returned with successful APPEND and COPY 85 commands. 86 87 Clients that wish to use the new command in UIDPLUS must of course 88 first test for the presence of the extension by issuing a CAPABILITY 89 command. Each of the features in UIDPLUS are optimizations; clients 90 can provide the same functionality, albeit more slowly, by using 91 commands in the base protocol. With each feature, this document 92 recommends a fallback approach to take when the UIDPLUS extension is 93 not supported by the server. 94 95 4. Features 96 97 4.1. UID EXPUNGE Command 98 99 Arguments: message set 100 101 Data: untagged responses: EXPUNGE 102 103 Result: OK - expunge completed 104 NO - expunge failure (e.g. permission denied) 105 BAD - command unknown or arguments invalid 106 107 108 109 110 111 112 113 114 Myers Standards Track [Page 2] 115 116 RFC 2359 IMAP4 UIDPLUS extension June 1998 117 118 119 The UID EXPUNGE command permanently removes from the currently 120 selected mailbox all messages that both have the \Deleted flag set 121 and have a UID that is included in the specified message set. If 122 a message either does not have the \Deleted flag set or is has a 123 UID that is not included in the specified message set, it is not 124 affected. 125 126 This command may be used to ensure that a replayed EXPUNGE command 127 does not remove any messages that have been marked as \Deleted 128 between the time that the user requested the expunge operation and 129 the time the server processes the command. 130 131 If the server does not support the UIDPLUS capability, the client 132 should fall back to using the STORE command to temporarily remove 133 the \Deleted flag from messages it does not want to remove. The 134 client could alternatively fall back to using the EXPUNGE command, 135 risking the unintended removal of some messages. 136 137 Example: C: A003 UID EXPUNGE 3000:3002 138 S: * 3 EXPUNGE 139 S: * 3 EXPUNGE 140 S: * 3 EXPUNGE 141 S: A003 OK UID EXPUNGE completed 142 143 4.2. APPENDUID response code 144 145 Successful APPEND commands return an APPENDUID response code in the 146 tagged OK response. The APPENDUID response code contains as 147 arguments the UIDVALIDITY of the destination mailbox and the UID 148 assigned to the appended message. 149 150 If the server does not support the UIDPLUS capability, the client can 151 only discover this information by selecting the destination mailbox 152 and issuing FETCH commands. 153 154 Example: C: A003 APPEND saved-messages (\Seen) {310} 155 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 156 C: From: Fred Foobar <foobar@Blurdybloop.COM> 157 C: Subject: afternoon meeting 158 C: To: mooch@owatagu.siam.edu 159 C: Message-Id: <B27397-0100000@Blurdybloop.COM> 160 C: MIME-Version: 1.0 161 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 162 C: 163 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 164 C: 165 S: A003 OK [APPENDUID 38505 3955] APPEND completed 166 167 168 169 170 Myers Standards Track [Page 3] 171 172 RFC 2359 IMAP4 UIDPLUS extension June 1998 173 174 175 4.3. COPYUID response code 176 177 Successful COPY and UID COPY commands return a COPYUID response code 178 in the tagged OK response whenever at least one message was copied. 179 The COPYUID response code contains as an argument the UIDVALIDITY of 180 the appended-to mailbox, a message set containing the UIDs of the 181 messages copied to the destination mailbox, in the order they were 182 copied, and a message containing the UIDs assigned to the copied 183 messages, in the order they were assigned. Neither of the message 184 sets may contain extraneous UIDs or the symbol '*'. 185 186 If the server does not support the UIDPLUS capability, the client can 187 only discover this information by selecting the destination mailbox 188 and issuing FETCH commands. 189 190 Example: C: A003 COPY 2:4 MEETING 191 S: A003 OK [COPYUID 38505 304,319:320 3956:3958] Done 192 C: A003 UID COPY 305:310 MEETING 193 S: A003 OK Done 194 195 5. Formal Syntax 196 197 The following syntax specification uses the augmented Backus-Naur 198 Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. 199 Non-terminals referenced but not defined below are as defined by 200 [IMAP4]. 201 202 Except as noted otherwise, all alphabetic characters are case- 203 insensitive. The use of upper or lower case characters to define 204 token strings is for editorial clarity only. Implementations MUST 205 accept these strings in a case-insensitive fashion. 206 207 resp_code_apnd ::= "APPENDUID" SPACE nz_number SPACE uniqueid 208 209 resp_code_copy ::= "COPYUID" SPACE nz_number SPACE set SPACE set 210 211 uid_expunge ::= "UID" SPACE "EXPUNGE" SPACE set 212 213 6. References 214 215 [IMAP4] Crispin, M., "Internet Message Access Protocol - 216 Version 4rev1", RFC 2060, December 1996. 217 218 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 221 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 222 Text Messages", STD 11, RFC 822, August 1982. 223 224 225 226 Myers Standards Track [Page 4] 227 228 RFC 2359 IMAP4 UIDPLUS extension June 1998 229 230 231 7. Security Considerations 232 233 There are no known security issues with this extension. 234 235 8. Author's Address 236 237 John Gardiner Myers 238 Netscape Communications 239 501 East Middlefield Road 240 Mail Stop MV-029 241 Mountain View, CA 94043 242 243 EMail: jgmyers@netscape.com 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 Myers Standards Track [Page 5] 283 284 RFC 2359 IMAP4 UIDPLUS extension June 1998 285 286 287 9. Full Copyright Statement 288 289 Copyright (C) The Internet Society (1998). All Rights Reserved. 290 291 This document and translations of it may be copied and furnished to 292 others, and derivative works that comment on or otherwise explain it 293 or assist in its implementation may be prepared, copied, published 294 and distributed, in whole or in part, without restriction of any 295 kind, provided that the above copyright notice and this paragraph are 296 included on all such copies and derivative works. However, this 297 document itself may not be modified in any way, such as by removing 298 the copyright notice or references to the Internet Society or other 299 Internet organizations, except as needed for the purpose of 300 developing Internet standards in which case the procedures for 301 copyrights defined in the Internet Standards process must be 302 followed, or as required to translate it into languages other than 303 English. 304 305 The limited permissions granted above are perpetual and will not be 306 revoked by the Internet Society or its successors or assigns. 307 308 This document and the information contained herein is provided on an 309 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 310 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 311 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 312 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 313 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 Myers Standards Track [Page 6] 339