Internet DRAFT - draft-leiba-imap-2177bis
draft-leiba-imap-2177bis
Network Working Group B. Leiba
Internet-Draft IBM T.J. Watson Research Center
Obsoletes: 2177 (if approved) December 7, 2005
Expires: June 10, 2006
IMAP4 IDLE command
draft-leiba-imap-2177bis-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 10, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Internet Message Access Protocol requires a client to poll the
server for changes to the selected mailbox (new mail, deletions).
It's often more desirable to have the server transmit updates to the
client in real time. This allows a user to see new mail immediately.
It also helps some real-time applications based on IMAP, which might
otherwise need to poll extremely often (such as every few seconds).
(While the spec actually does allow a server to push EXISTS responses
asynchronously, a client can't expect this behaviour and must poll.)
Leiba Expires June 10, 2006 [Page 1]
Internet-Draft IMAP4 IDLE command December 2005
This document specifies the syntax of an IDLE command, which will
allow a client to tell the server that it's ready to accept such
real-time updates.
Note
This document is intended to be an update to the existing "IDLE"
extension to the IMAP protocol, available from the RFC repository as
ftp://ftp.isi.edu/in-notes/rfc2177.txt.
This document and other IMAP extensions are being discussed on the
imapext mailing list at mailto:ietf-imapext@imc.org. Subscription
requests can be sent to
mailto:ietf-imapext-request@imc.org?body=subscribe (send an email
message with the word "subscribe" in the body). More information on
the mailing list along with a WWW archive of back messages is
available at http://www.imc.org/ietf-imapext/.
Leiba Expires June 10, 2006 [Page 2]
Internet-Draft IMAP4 IDLE command December 2005
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 4
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Changes since RFC 2177 . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
Leiba Expires June 10, 2006 [Page 3]
Internet-Draft IMAP4 IDLE command December 2005
1. Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [Keywds].
Leiba Expires June 10, 2006 [Page 4]
Internet-Draft IMAP4 IDLE command December 2005
2. Specification
IDLE 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 IDLE command
at this time
BAD - command unknown or arguments invalid
The IDLE command may be used with any IMAP4 server implementation
that returns "IDLE" as one of the supported capabilities to the
CAPABILITY command. If the server does not advertise the IDLE
capability, the client MUST NOT use the IDLE command and must poll
for mailbox updates. In particular, the client MUST continue to be
able to accept unsolicited untagged responses to ANY command (not
just to the IDLE command), as specified in the base IMAP
specification.
The IDLE command is sent from the client to the server when the
client is ready to accept unsolicited messages from the server. 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 ANY untagged responses. IMAP
servers will frequently send unsolicited responses such as these:
o EXISTS, to inform the client about a change in the number of
messages in the currently-selected mailbox.
o EXPUNGE, to inform the client that a message has been expunged.
o FETCH, to inform the client about a change in the status of a
message (usually to convey flag changes).
o RECENT, to inform the client that the number of messages with the
\Recent flag has changed. This response often accompanies EXISTS.
But note again that what the server may send is not limited to that
list -- ANY untagged response may appear.
The IDLE command is terminated by the receipt of a "DONE"
Leiba Expires June 10, 2006 [Page 5]
Internet-Draft IMAP4 IDLE command December 2005
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 "OK" to the IDLE 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. If
the server receives anything other than "DONE" from the client, this
is a protocol violation and the server SHOULD terminate the IDLE
command with a tagged response of "BAD".
The server MAY consider a client inactive if it has an IDLE 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 IDLE are advised to terminate the IDLE 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.
Leiba Expires June 10, 2006 [Page 6]
Internet-Draft IMAP4 IDLE command December 2005
3. Example
The following is an example of an IMAP session using IDLE.
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 IDLE
S: + idling
...time passes; another client sets a flag on message 2...
S: * 2 FETCH (FLAGS (\Seen \Answered \Flagged))
...time passes; new mail arrives...
S: * 4 EXISTS
C: DONE
S: A002 OK IDLE terminated
...another client expunges message 2 now...
C: A003 FETCH 4 ALL
S: * 4 FETCH (...)
S: A003 OK FETCH completed
C: A004 IDLE
S: * 2 EXPUNGE
S: * 3 EXISTS
S: + idling
...time passes; another client expunges message 3...
S: * 3 EXPUNGE
S: * 2 EXISTS
...time passes; new mail arrives...
S: * 3 EXISTS
C: DONE
S: A004 OK IDLE terminated
C: A005 FETCH 3 ALL
S: * 3 FETCH (...)
S: A005 OK FETCH completed
C: A006 IDLE
Leiba Expires June 10, 2006 [Page 7]
Internet-Draft IMAP4 IDLE command December 2005
4. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in [ABNF]. Non-terminals referenced
but not defined below are as defined by [IMAP4].
command_auth =/ idle
; Valid only in Authenticated or Selected state
idle = "IDLE" CRLF "DONE"
Leiba Expires June 10, 2006 [Page 8]
Internet-Draft IMAP4 IDLE command December 2005
5. Changes since RFC 2177
1. Updated references to current versions.
2. Updated ABNF to current syntax.
3. Added example of unsolicited FETCH response.
4. Clarified that ANY response may come from the server during IDLE,
and gave examples of the most common responses.
5. Clarified that anything other than "DONE" is "BAD".
Leiba Expires June 10, 2006 [Page 9]
Internet-Draft IMAP4 IDLE command December 2005
6. Security Considerations
There are no known security issues with this extension.
7. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
[Keywds] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
Author's Address
Barry Leiba
IBM T.J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
US
Phone: +1 914 784 7941
Email: leiba@watson.ibm.com
Leiba Expires June 10, 2006 [Page 10]
Internet-Draft IMAP4 IDLE command December 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Leiba Expires June 10, 2006 [Page 11]
