IMAP APPEND Extensions (imapapnd)

Last modified: 2016-05-19

Chair:

Applications and Real-Time Area Advisor:

Mailing Lists:

General Discussion: imapext@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/imapext
Archive: https://mailarchive.ietf.org/arch/browse/imapext/

Description of 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.

Goals and Milestones

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

Request for Comments

Internet SocietyAMSHome - Tools Team - Datatracker - IASA - IAB - RFC Editor - IANA - IRTF - IETF Trust - ISOC - IETF Journal - Store - Contact Us
Secretariat services provided by Association Management Solutions, LLC (AMS).
Please send problem reports to: ietf-action@ietf.org.