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]