Internet Engineering Task Force M. MagicalTux, Ed. Internet-Draft K.K. Tibanne Intended status: Standards Track June 23, 2010 Expires: December 25, 2010 IMAP4 IDLEPLUS extension draft-magicaltux-imap4-idleplus-00 Abstract This document describes a new extension for IMAP4 servers. This new extension aims to extend the functions provided by the existing IDLE extension (RFC 2177) to better fit needs of current IMAP4 clients by allowing monitoring of multiple folders. Comments are solicited and should be addressed to the author. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 25, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as MagicalTux Expires December 25, 2010 [Page 1] Internet-Draft IMAP4 IDLEPLUS extension June 2010 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . . 3 3. Specifications . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. IDLEPLUS Command . . . . . . . . . . . . . . . . . . . . . 3 3.2. IDLEPLUS Responses . . . . . . . . . . . . . . . . . . . . 5 3.2.1. EXISTS . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. EXPUNGE . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.3. STORED . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 MagicalTux Expires December 25, 2010 [Page 2] Internet-Draft IMAP4 IDLEPLUS extension June 2010 1. Introduction Most modern IMAP4rev1 RFC 3501 [RFC3501] clients support so-called push-imap way to receive emails in realtime in the form of IMAP IDLE RFC 2177 [RFC2177]. Those clients usually want to receive real time notification of new emails or deleted emails in more than one imap folder, which is not supported by IMAP IDLE. To workaround this limitation, those clients will open one connection per monitored folder and cause unneeded load on those servers. A typical user will have INBOX, Draft and Sent folders. This can increase dramatically if the user makes use of folders to filter mails, causing some users to have up to 30 folders (and idle IMAP connections via TCP). This draft proposes a new way for IMAP clients to receive change notifications on many folders without having to keep many open connections to the IMAP server. 1.1. Conventions In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. IMAP Protocol Changes The IDLEPLUS extension is present in any IMAP server implementation that returns "IDLEPLUS" as one of the supported capabilities to the CAPABILITY command. The IDLEPLUS extension defines an additional command. 3. Specifications 3.1. IDLEPLUS Command MagicalTux Expires December 25, 2010 [Page 3] Internet-Draft IMAP4 IDLEPLUS extension June 2010 Arguments: none Responses: continuation data will be requested; the client sends the continuation data "DONE" to end the command Result: OK IDLE completed after client sent "DONE" NO failure: the server will not allow the IDLEPLUS command at this time BAD command unknown or arguments invalid The IDLEPLUS command may be used with any IMAP4 server implementation that returns "IDLEPLUS" as one of the supported capabilities to the CAPABILITY command. If the server does not advertise the IDLEPLUS capability, the client MUST NOT use the IDLEPLUS command and may either poll for mailbox updates or connect multiple times to the IMAP server and use IDLE command from RFC 2177 [RFC2177]. In particular, the client MUST continue to be able to accept unsolicited untagged responses to ANY command, as specified in the base IMAP specification. The IDLEPLUS command is sent from the client to the server when the client is ready to accept unsolicited mailbox update messages. The server requests a response to the IDLE command using the continuation ("+") response. The IDLE command remains active until the client responds to the continuation, and as long as an IDLE command is active, the server is now free to send untagged EXISTS, EXPUNGE, and other messages at any time. Untagged responses by IDLEPLUS are slightly different from those expected by calls to IDLE. Those are detailed in IDLEPLUS Responses (Section 3.2). The IDLEPLUS command is terminated by the receipt of a "DONE" continuation from the client; such response satisfies the server's continuation request. At that point, the server MAY send any remaining queued untagged responses and then MUST immediately send the tagged response to the IDLEPLUS command and prepare to process other commands. As in the base specification, the processing of any new command may cause the sending of unsolicited untagged responses, subject to the ambiguity limitations. The client MUST NOT send a command while the server is waiting for the DONE, since the server will not be able to distinguish a command from a continuation. The server MAY consider a client inactive if it has an IDLEPLUS MagicalTux Expires December 25, 2010 [Page 4] Internet-Draft IMAP4 IDLEPLUS extension June 2010 command running, and if such a server has an inactivity timeout it MAY log the client off implicitly at the end of its timeout period. Because of that, clients using IDLEPLUS are advised to terminate the IDLEPLUS and re-issue it at least every 29 minutes to avoid being logged off. This still allows a client to receive immediate mailbox updates even though it need only "poll" at half hour intervals. 3.2. IDLEPLUS Responses When in IDLEPLUS mode the server will send different kinds of untagged responses to the client. Each untagged response is made of the message UID, the response type and the folder in which the message is stored. The mailbox name MUST NOT contain 8bit characters. Mailbox names containing non-ASCII characters should be encoded with the IMAP modified UTF-7 syntax. The server MUST send untagged response for any activity in any of the user's subscribed folders. It MAY send untagged responses for activity in other folders, in which case the client MUST ignore messages it has no need for. The server SHOULD notify the client about message modified in other namespaces, unless this is technically not possible. In this case the server MUST notify the client of which namespaces cannot be monitored with the "EXCLUDES" tag in the continuation response. While the server has to provide past events to the client when entering IDLEPLUS, it MAY discard elements older than 30 minutes that were not transmitted to the client to avoid keeping too much data in memory. Additionally the server SHOULD start keeping track of those events after the first call of IDLEPLUS to avoid unnecessary load. In each case it is up to the client to interrupt the IDLEPLUS call and fetch informations about the changes (enveloppe of the new message for EXISTS or flags of the message for STORED). 3.2.1. EXISTS The EXISTS untagged response signals the arrival of a new message in the specified mailbox. 3.2.2. EXPUNGE The EXPUNGE untagged response signals the deletion of a message in the specified mailbox. MagicalTux Expires December 25, 2010 [Page 5] Internet-Draft IMAP4 IDLEPLUS extension June 2010 3.2.3. STORED The STORED untagged response signals a message has been changed. This usually means the flags of a given message were changed, for example if the message has been read or deleted (but not expunged yet). Even use of the ".SILENT" store suffix will still cause this untagged response. 3.3. Example C: A001 SELECT INBOX S: * FLAGS (Deleted Seen) S: * 3 EXISTS S: * 0 RECENT S: * OK [UIDVALIDITY 1] S: A001 OK SELECT completed C: A002 IDLEPLUS S: + idling [EXCLUDES #news] ...time passes; new mail arrives... S: * 884 EXISTS "Some Folder" S: * 71 EXISTS INBOX C: DONE S: A002 OK IDLEPLUS terminated ...another client deletes mail 884 from Some Folder C: A003 UID FETCH 71 ALL S: * 4 FETCH (...) S: A003 OK UID FETCH completed C: A004 IDLE S: * 884 EXPUNGE "Some Folder" S: + idling [EXCLUDES #news] 4. Acknowledgements The editor would like to thank anyone helping to make this document into a RFC as this is his first attempt. 5. IANA Considerations The IDLEPLUS protocol keyworld needs to be registered in the imap4- capabilities registry via an IETF Review. 6. Security Considerations It is believed that this extension doesn't add any security MagicalTux Expires December 25, 2010 [Page 6] Internet-Draft IMAP4 IDLEPLUS extension June 2010 considerations that are not already present in the base IMAP protocol [RFC3501] 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. Author's Address Mark Karpeles (editor) K.K. Tibanne Fleur Tsuzuki 102 5-24-30 Kugayama Suginami, Toyko 168-0082 JP Phone: +81 3 4550 1529 Email: mark@tibanne.com MagicalTux Expires December 25, 2010 [Page 7]