IMAP4 IDLEPLUS extension
draft-magicaltux-imap4-idleplus-01

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 described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Conventions
2.  IMAP Protocol Changes
3.  Specifications
    3.1.  IDLEPLUS Command
    3.2.  IDLEPLUS Responses
        3.2.1.  EXISTS
        3.2.2.  EXPUNGE
        3.2.3.  STORED
    3.3.  Example
4.  Acknowledgements
5.  IANA Considerations
6.  Security Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address

1.  Introduction

Most modern IMAP4rev1 RFC 3501 (Crispin, M., “INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1,” March 2003.) [RFC3501] clients support so-called push-imap way to receive emails in realtime in the form of IMAP IDLE RFC 2177 (Leiba, B., “IMAP4 IDLE command,” June 1997.) [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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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

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 (Leiba, B., “IMAP4 IDLE command,” June 1997.) [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 (IDLEPLUS Responses).

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

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 considerations that are not already present in the base IMAP protocol (Crispin, M., “INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1,” March 2003.) [RFC3501]

7.  References

7.1. Normative References

7.2. Informative References

Author's Address