Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
RFC 3502
|
Document |
Type |
|
RFC - Proposed Standard
(March 2003; No errata)
|
|
Author |
|
Mark Crispin
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 3502 (Proposed Standard)
|
|
Telechat date |
|
|
|
Responsible AD |
|
Ned Freed
|
|
IESG note |
|
published
|
|
Send notices to |
|
<mcr@wsmr-simtel20.army.mil>
|
Network Working Group M. Crispin
Request for Comments: 3502 University of Washington
Category: Standards Track March 2003
Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes the multiappending extension to the Internet
Message Access Protocol (IMAP) (RFC 3501). This extension provides
substantial performance improvements for IMAP clients which upload
multiple messages at a time to a mailbox on the server.
A server which supports this extension indicates this with a
capability name of "MULTIAPPEND".
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [KEYWORDS].
Introduction
The MULTIAPPEND extension permits uploading of multiple messages with
a single command. When used in conjunction with the [LITERAL+]
extension, the entire upload is accomplished in a single
command/response round trip.
A MULTIAPPEND APPEND operation is atomic; either all messages are
successfully appended, or no messages are appended.
In the base IMAP specification, each message must be appended in a
separate command, and there is no mechanism to "unappend" messages if
an error occurs while appending. Also, some mail stores may require
Crispin Standards Track [Page 1]
RFC 3502 IMAP MULTIAPPEND March 2003
an expensive "open/lock + sync/unlock/close" operation as part of
appending; this can be quite expensive if it must be done on a
per-message basis.
If the server supports both LITERAL+ and pipelining but not
MULTIAPPEND, it may be possible to get some of the performance
advantages of MULTIAPPEND by doing a pipelined "batch" append.
However, it will not work as well as MULTIAPPEND for the following
reasons:
1) Multiple APPEND commands, even as part of a pipelined batch,
are non-atomic by definition. There is no way to revert the
mailbox to the state before the batch append in the event of an
error.
2) It may not be feasible for the server to coalesce pipelined
APPEND operations so as to avoid the "open/lock +
sync/unlock/close" overhead described above. In any case, such
coalescing would be timing dependent and thus potentially
unreliable. In particular, with traditional UNIX mailbox files,
it is assumed that a lock is held only for a single atomic
operation, and many applications disregard any lock that is
older than 5 minutes.
3) If an error occurs, depending upon the nature of the error,
it is possible for additional messages to be appended after the
error. For example, the user wants to append 5 messages, but a
disk quota error occurs with the third message because of its
size. However, the fourth and fifth messages have already been
sent in the pipeline, so the mailbox ends up with the first,
second, fourth, and fifth messages of the batch appended.
6.3.11. APPEND Command
Arguments: mailbox name
one or more messages to upload, specified as:
OPTIONAL flag parenthesized list
OPTIONAL date/time string
message literal
Data: no specific responses for this command
Result: OK - append completed
NO - append error: can't append to that mailbox, error
in flags or date/time or message text,
append cancelled
BAD - command unknown or arguments invalid
Crispin Standards Track [Page 2]
RFC 3502 IMAP MULTIAPPEND March 2003
The APPEND command appends the literal arguments as new messages
to the end of the specified destination mailbox. This argument
SHOULD be in the format of an [RFC-2822] message. 8-bit
characters are permitted in the message. A server implementation
that is unable to preserve 8-bit data properly MUST be able to
reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
content transfer encoding.
Note: There MAY be exceptions, e.g., draft messages, in
which required [RFC-2822] header lines are omitted in the
Show full document text