228 lines
6.6 KiB
Text
228 lines
6.6 KiB
Text
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group B. Leiba
|
|||
|
|
Request for Comments: 2177 IBM T.J. Watson Research Center
|
|||
|
|
Category: Standards Track June 1997
|
|||
|
|
|
|||
|
|
|
|||
|
|
IMAP4 IDLE command
|
|||
|
|
|
|||
|
|
Status of this Memo
|
|||
|
|
|
|||
|
|
This document specifies an Internet standards track protocol for the
|
|||
|
|
Internet community, and requests discussion and suggestions for
|
|||
|
|
improvements. Please refer to the current edition of the "Internet
|
|||
|
|
Official Protocol Standards" (STD 1) for the standardization state
|
|||
|
|
and status of this protocol. Distribution of this memo is unlimited.
|
|||
|
|
|
|||
|
|
1. Abstract
|
|||
|
|
|
|||
|
|
The Internet Message Access Protocol [IMAP4] 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 aysynchronously, a client can't expect this
|
|||
|
|
behaviour and must poll.)
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
2. 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", "SHOULD", "SHOULD NOT", and "MAY"
|
|||
|
|
in this document are to be interpreted as described in RFC 2060
|
|||
|
|
[IMAP4].
|
|||
|
|
|
|||
|
|
3. Specification
|
|||
|
|
|
|||
|
|
IDLE Command
|
|||
|
|
|
|||
|
|
Arguments: none
|
|||
|
|
|
|||
|
|
Responses: continuation data will be requested; the client sends
|
|||
|
|
the continuation data "DONE" to end the command
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Leiba Standards Track [Page 1]
|
|||
|
|
|
|||
|
|
RFC 2177 IMAP4 IDLE command June 1997
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
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, 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 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.
|
|||
|
|
|
|||
|
|
The IDLE 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 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.
|
|||
|
|
|
|||
|
|
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 Standards Track [Page 2]
|
|||
|
|
|
|||
|
|
RFC 2177 IMAP4 IDLE command June 1997
|
|||
|
|
|
|||
|
|
|
|||
|
|
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 IDLE
|
|||
|
|
S: + idling
|
|||
|
|
...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
|
|||
|
|
|
|||
|
|
4. Formal Syntax
|
|||
|
|
|
|||
|
|
The following syntax specification uses the augmented Backus-Naur
|
|||
|
|
Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
|
|||
|
|
Non-terminals referenced but not defined below are as defined by
|
|||
|
|
[IMAP4].
|
|||
|
|
|
|||
|
|
command_auth ::= append / create / delete / examine / list / lsub /
|
|||
|
|
rename / select / status / subscribe / unsubscribe
|
|||
|
|
/ idle
|
|||
|
|
;; Valid only in Authenticated or Selected state
|
|||
|
|
|
|||
|
|
idle ::= "IDLE" CRLF "DONE"
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Leiba Standards Track [Page 3]
|
|||
|
|
|
|||
|
|
RFC 2177 IMAP4 IDLE command June 1997
|
|||
|
|
|
|||
|
|
|
|||
|
|
5. References
|
|||
|
|
|
|||
|
|
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
|
|||
|
|
4rev1", RFC 2060, December 1996.
|
|||
|
|
|
|||
|
|
6. Security Considerations
|
|||
|
|
|
|||
|
|
There are no known security issues with this extension.
|
|||
|
|
|
|||
|
|
7. Author's Address
|
|||
|
|
|
|||
|
|
Barry Leiba
|
|||
|
|
IBM T.J. Watson Research Center
|
|||
|
|
30 Saw Mill River Road
|
|||
|
|
Hawthorne, NY 10532
|
|||
|
|
|
|||
|
|
Email: leiba@watson.ibm.com
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Leiba Standards Track [Page 4]
|
|||
|
|
|