Skip to main content

Concluded WG IMAP APPEND Extensions (imapapnd)

Note: The data for concluded WGs is occasionally incorrect.

WG Name IMAP APPEND Extensions
Acronym imapapnd
Area Applications and Real-Time Area (art)
State Concluded
Charter charter-ietf-imapapnd-01 Approved
Document dependencies
Additional resources Issue tracker, Wiki
Personnel Chair S Moonesamy
Area Director Alexey Melnikov
Mailing list Address imapext@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/imapext
Archive https://mailarchive.ietf.org/arch/browse/imapext/

Final Charter for Working Group

The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for transferring email messages between a server
that implements a message store, and a client. It also includes commands
for manipulating the message store -- creating, deleting, and renaming
mailboxes, adding a message to a mailbox, and copying messages from one
mailbox to another.

IMAP (RFC 3501) contains the "literal" syntactic construct for
transferring blocks of data. Sending an IMAP literal string entails
first sending the length of the string, waiting for a response that
accepts a string of that length, then sending the string itself.
This complicates client implementations and resulted in definition
of the "LITERAL+" IMAP extension (RFC 2088), which specifies an
alternative type of literal string that does not require an extra
network round trip (the length and data are sent together). While this
extension is quite commonly supported by servers, some implementations
have it disabled because there is no good way for clients to know
whether a server can accept big messages.

The IMAP APPEND Extensions (imapapnd) working group will produce two
related Standards Track specifications, which are targeted at improving
the current situation:

  • The first is based on draft-jayantheesh-imap-appendlimit-extension,
    and defines a way for servers to announce an APPEND limit for a
    particular server or a particular mailbox.

  • The second is based on draft-melnikov-rfc2088bis, and describes
    implementation choices for servers supporting the LITERAL+ extension,
    as well as defining a new "LITERAL-" extension that has similar
    properties but provides a mechanism allowing servers to avoid
    denials of service by malicious or naive IMAP clients.

As part of the protocol development, implementation experience on both
the client and server side is highly desirable, so that the actual
operational value of this extension can be assessed. The working group
will document the results of this experience on the working group wiki.

No other IMAP extension work is in scope for this working group.

Done milestones

Date Milestone Associated documents
Done Submit IMAP4 non-synchronizing literals draft to the IESG (Proposed Standard)
Done Submit IMAP APPENDLIMIT Extension draft to the IESG (Proposed Standard)