Network Working Group J. Myers
Internet Draft Carnegie Mellon
Document: draft-myers-imap-optimize-00.txt July 1996
IMAP4 OPTIMIZE-1 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 July 9, 1996
1. Abstract
The OPTIMIZE-1 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
OPTIMIZE-1 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.
3. Introduction and Overview
The OPTIMIZE-1 extension is present in any IMAP4 server
implementation which returns "OPTIMIZE-1" as one of the supported
capabilities to the CAPABILITY command. The OPTIMIZE-1 extension
contains two additional commands and additional data returned with
successful APPEND and COPY commands.
Clients that wish to use the features in OPTIMIZE-1 must of course
first test for the presence of the extension by issuing a CAPABILITY
command. Each of the features in OPTIMIZE-1 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 OPTIMIZE-1
extension is not supported by the server.
J. Myers [Page 2]
Internet DRAFT OPTIMIZE-1 July 9, 1996
4. Features
4.1. GETUIDS Command
Arguments: starting uid
Data: untagged response: GETUIDS
Result: OK - getuids completed
BAD - command unknown or arguments invalid
The GETUIDS command returns information about UIDs contained in
the mailbox. One untagged GETUIDS response is returned.
If there is no message in the mailbox with a UID greater than or
equal to the starting UID, the untagged GETUIDS response contains
no arguments.
If there exists at least one message with a UID greater than or
equal to the starting UID, the untagged GETUIDS response contains
the lowest message sequence number with a UID greater than or
equal to the starting UID, followed by a message set. The message
set must contain the UIDs of every message in the mailbox with a
UID greater than or equal to the starting UID. The message set
must not contain the symbol '*', the UID of any message which
previously existed but has since been deleted, or any UID less
than the starting UID or greater than the UID of the last message
in the mailbox. The UIDs in the message set must be in strictly
ascending order.
Upon receiving the untagged GETUIDS response, the client knows
that any message in its cache with a UID greater than or equal to
the starting UID and not present in a returned message set has
been expunged.
If the server does not support the OPTIMIZE-1 capability, the
client should fall back to using the UID FETCH starting-uid:* UID
command, where starting-uid is the starting UID.
Example: C: A003 GETUIDS 3475
S: * GETUIDS 17 3509:3519,3525,3590:3599
S: A003 OK GETUIDS completed
C: A004 GETUIDS 4000
S: * GETUIDS
S: A004 OK GETUIDS completed
J. Myers [Page 3]
Internet DRAFT OPTIMIZE-1 July 9, 1996
4.2. UID EXPUNGE Command
Arguments: message set
Data: untagged responses: EXPUNGE
Result: OK - expunge completed
NO - expunge failure (e.g. permision denied)
BAD - command unknown or arguments invalid
The UID EXPUNGE command permanently removes from the currently
selected mailbox all messages that both have the ted flag set and
have a UID that is included in the specified message set. If a
message either does not have the ted 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 ted 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 OPTIMIZE-1 capability, the
client should fall back to using the STORE command to temporarily
remove the ted 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: * EXPUNGE 3
S: * EXPUNGE 3
S: * EXPUNGE 3
S: A003 OK UID EXPUNGE completed
4.3. 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 OPTIMIZE-1 capability, the client
can only discover this information by selecting the destination
mailbox and issuing FETCH commands.
Example: C: A003 APPEND saved-messages (n) {310}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
J. Myers [Page 4]
Internet DRAFT OPTIMIZE-1 July 9, 1996
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.COM>
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.4. 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 OPTIMIZE-1 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.
getuids ::= "GETUIDS" SPACE uniqueid
getuids_data ::= "GETUIDS" [ SPACE nz_number SPACE set ]
literal ::= "{" number ["+"] "}" CRLF *CHAR8
J. Myers [Page 5]
Internet DRAFT OPTIMIZE-1 July 9, 1996
;; Number represents the number of CHAR8 octets
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 4",
draft-crispin-imap-base-XX.txt, University of Washington, April 1996.
[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 G. Myers
Carnegie-Mellon University
5000 Forbes Ave.
Pittsburgh PA, 15213-3890
Email: jgm+@cmu.edu
J. Myers [Page 6]
Internet DRAFT OPTIMIZE-1 July 9, 1996
Table of Contents
Status of this Memo
1. Abstract
2. Conventions Used in this Document
3. Introduction and Overview
4. Features
4.1. GETUIDS Command
4.2. UID EXPUNGE Command
4.3. APPENDUID response code
4.4. COPYUID response code
5. Formal Syntax
6. References
7. Security Considerations
8. Author's Address
J. Myers [Page ii]