Network Working Group J. Myers Internet Draft Netscape Communications Document: draft-myers-imap-optimize-03.txt December 1997 IMAP4 UIDPLUS extension Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress''. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before December 1996. Distribution of this draft is unlimited. J. Myers [Page i] Internet DRAFT OPTIMIZE-1 December 19, 1997 1. Abstract The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. 2. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 3. Introduction and Overview The UIDPLUS extension is present in any IMAP4 server implementation which returns "UIDPLUS" as one of the supported capabilities to the CAPABILITY command. The UIDPLUS extension contains one additional command and additional data returned with successful APPEND and COPY commands. Clients that wish to use the new command in UIDPLUS must of course first test for the presence of the extension by issuing a CAPABILITY command. Each of the features in UIDPLUS are optimizations; clients can provide the same functionality, albeit more slowly, by using commands in the base protocol. With each feature, this document recommends a fallback approach to take when the UIDPLUS extension is not supported by the server. J. Myers [Page 2] Internet DRAFT OPTIMIZE-1 December 19, 1997 4. Features 4.1. UID EXPUNGE Command Arguments: message set Data: untagged responses: EXPUNGE Result: OK - expunge completed NO - expunge failure (e.g. permission denied) BAD - command unknown or arguments invalid The UID EXPUNGE command permanently removes from the currently selected mailbox all messages that both have the \Deleted flag set and have a UID that is included in the specified message set. If a message either does not have the \Deleted flag set or is has a UID that is not included in the specified message set, it is not affected. This command may be used to ensure that a replayed EXPUNGE command does not remove any messages that have been marked as \Deleted between the time that the user requested the expunge operation and the time the server processes the command. If the server does not support the UIDPLUS capability, the client should fall back to using the STORE command to temporarily remove the \Deleted flag from messages it does not want to remove. The client could alternatively fall back to using the EXPUNGE command, risking the unintended removal of some messages. Example: C: A003 UID EXPUNGE 3000:3002 S: * 3 EXPUNGE S: * 3 EXPUNGE S: * 3 EXPUNGE S: A003 OK UID EXPUNGE completed 4.2. APPENDUID response code Successful APPEND commands return an APPENDUID response code in the tagged OK response. The APPENDUID response code contains as arguments the UIDVALIDITY of the destination mailbox and the UID assigned to the appended message. If the server does not support the UIDPLUS capability, the client can only discover this information by selecting the destination mailbox and issuing FETCH commands. J. Myers [Page 3] Internet DRAFT OPTIMIZE-1 December 19, 1997 Example: C: A003 APPEND saved-messages (\Seen) {310} C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: From: Fred Foobar C: Subject: afternoon meeting C: To: mooch@owatagu.siam.edu C: Message-Id: C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: S: A003 OK [APPENDUID 38505 3955] APPEND completed 4.3. COPYUID response code Successful COPY and UID COPY commands return a COPYUID response code in the tagged OK response whenever at least one message was copied. The COPYUID response code contains as an argument the UIDVALIDITY of the appended-to mailbox, a message set containing the UIDs of the messages copied to the destination mailbox, in the order they were copied, and a message containing the UIDs assigned to the copied messages, in the order they were assigned. Neither of the message sets may contain extraneous UIDs or the symbol '*'. If the server does not support the UIDPLUS capability, the client can only discover this information by selecting the destination mailbox and issuing FETCH commands. Example: C: A003 COPY 2:4 MEETING S: A003 OK [COPYUID 38505 304,319:320 3956:3958] Done C: A003 UID COPY 305:310 MEETING S: A003 OK Done 5. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. Non-terminals referenced but not defined below are as defined by [IMAP4]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. J. Myers [Page 4] Internet DRAFT OPTIMIZE-1 December 19, 1997 resp_code_apnd ::= "APPENDUID" SPACE nz_number SPACE uniqueid resp_code_copy ::= "COPYUID" SPACE nz_number SPACE set SPACE set uid_expunge ::= "UID" SPACE "EXPUNGE" SPACE set 6. References [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822. 7. Security Considerations There are no known security issues with this extension. 8. Author's Address John Gardiner Myers Netscape Communications 501 East Middlefield Road Mail Stop MV-029 Mountain View, CA 94043 Email: jgmyers@netscape.com J. Myers [Page 5] Internet DRAFT OPTIMIZE-1 December 19, 1997 TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss Status of this Memo ............................................... i 1. Abstract ..................................................... 2 2. Conventions Used in this Document ............................ 2 3. Introduction and Overview .................................... 2 4. Features ..................................................... 3 4.1. UID EXPUNGE Command .......................................... 3 4.2. APPENDUID response code ...................................... 3 4.3. COPYUID response code ........................................ 4 5. Formal Syntax ................................................ 4 6. References ................................................... 5 7. Security Considerations ...................................... 5 8. Author's Address ............................................. 5 J. Myers [Page ii]