rfc2177.txt
7.03 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
Network Working Group
Request for Comments: 2177
Category: Standards Track
B. Leiba
IBM T.J. Watson Research Center
June 1997
Page 1
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
__________________________________________________________
Page 2
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.
__________________________________________________________
Page 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 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"
__________________________________________________________
Page 4
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
__________________________________________________________