mirror of
https://github.com/uw-imap/imap.git
synced 2024-11-16 10:28:23 +01:00
228 lines
6.6 KiB
Plaintext
228 lines
6.6 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|