1 ../imapserver/server.go:137
2
3
4
5
6
7Network Working Group B. Leiba
8Request for Comments: 2177 IBM T.J. Watson Research Center
9Category: Standards Track June 1997
10
11
12 IMAP4 IDLE command
13
14Status of this Memo
15
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
21
221. Abstract
23
24 The Internet Message Access Protocol [IMAP4] requires a client to
25 poll the server for changes to the selected mailbox (new mail,
26 deletions). It's often more desirable to have the server transmit
27 updates to the client in real time. This allows a user to see new
28 mail immediately. It also helps some real-time applications based on
29 IMAP, which might otherwise need to poll extremely often (such as
30 every few seconds). (While the spec actually does allow a server to
31 push EXISTS responses aysynchronously, a client can't expect this
32 behaviour and must poll.)
33
34 This document specifies the syntax of an IDLE command, which will
35 allow a client to tell the server that it's ready to accept such
36 real-time updates.
37
382. Conventions Used in this Document
39
40 In examples, "C:" and "S:" indicate lines sent by the client and
41 server respectively.
42
43 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
44 in this document are to be interpreted as described in RFC 2060
45 [IMAP4].
46
473. Specification
48
49 IDLE Command 9051:3542 ../imapserver/server.go:2821
50
51 Arguments: none
52
53 Responses: continuation data will be requested; the client sends
54 the continuation data "DONE" to end the command
55
56
57
58Leiba Standards Track [Page 1]
59
60RFC 2177 IMAP4 IDLE command June 1997
61
62
63
64 Result: OK - IDLE completed after client sent "DONE"
65 NO - failure: the server will not allow the IDLE
66 command at this time
67 BAD - command unknown or arguments invalid
68
69 The IDLE command may be used with any IMAP4 server implementation
70 that returns "IDLE" as one of the supported capabilities to the
71 CAPABILITY command. If the server does not advertise the IDLE
72 capability, the client MUST NOT use the IDLE command and must poll
73 for mailbox updates. In particular, the client MUST continue to be
74 able to accept unsolicited untagged responses to ANY command, as
75 specified in the base IMAP specification.
76
77 The IDLE command is sent from the client to the server when the
78 client is ready to accept unsolicited mailbox update messages. The
79 server requests a response to the IDLE command using the continuation
80 ("+") response. The IDLE command remains active until the client
81 responds to the continuation, and as long as an IDLE command is
82 active, the server is now free to send untagged EXISTS, EXPUNGE, and
83 other messages at any time.
84
85 The IDLE command is terminated by the receipt of a "DONE"
86 continuation from the client; such response satisfies the server's
87 continuation request. At that point, the server MAY send any
88 remaining queued untagged responses and then MUST immediately send
89 the tagged response to the IDLE command and prepare to process other
90 commands. As in the base specification, the processing of any new
91 command may cause the sending of unsolicited untagged responses,
92 subject to the ambiguity limitations. The client MUST NOT send a
93 command while the server is waiting for the DONE, since the server
94 will not be able to distinguish a command from a continuation.
95
96 The server MAY consider a client inactive if it has an IDLE command
97 running, and if such a server has an inactivity timeout it MAY log
98 the client off implicitly at the end of its timeout period. Because
99 of that, clients using IDLE are advised to terminate the IDLE and
100 re-issue it at least every 29 minutes to avoid being logged off.
101 This still allows a client to receive immediate mailbox updates even
102 though it need only "poll" at half hour intervals.
103
104
105
106
107
108
109
110
111
112
113
114Leiba Standards Track [Page 2]
115
116RFC 2177 IMAP4 IDLE command June 1997
117
118
119 Example: C: A001 SELECT INBOX 9051:3589 ../imapserver/server.go:2822
120 S: * FLAGS (Deleted Seen)
121 S: * 3 EXISTS
122 S: * 0 RECENT
123 S: * OK [UIDVALIDITY 1]
124 S: A001 OK SELECT completed
125 C: A002 IDLE
126 S: + idling
127 ...time passes; new mail arrives...
128 S: * 4 EXISTS
129 C: DONE
130 S: A002 OK IDLE terminated
131 ...another client expunges message 2 now...
132 C: A003 FETCH 4 ALL
133 S: * 4 FETCH (...)
134 S: A003 OK FETCH completed
135 C: A004 IDLE
136 S: * 2 EXPUNGE
137 S: * 3 EXISTS
138 S: + idling
139 ...time passes; another client expunges message 3...
140 S: * 3 EXPUNGE
141 S: * 2 EXISTS
142 ...time passes; new mail arrives...
143 S: * 3 EXISTS
144 C: DONE
145 S: A004 OK IDLE terminated
146 C: A005 FETCH 3 ALL
147 S: * 3 FETCH (...)
148 S: A005 OK FETCH completed
149 C: A006 IDLE
150
1514. Formal Syntax
152
153 The following syntax specification uses the augmented Backus-Naur
154 Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
155 Non-terminals referenced but not defined below are as defined by
156 [IMAP4].
157
158 command_auth ::= append / create / delete / examine / list / lsub /
159 rename / select / status / subscribe / unsubscribe
160 / idle
161 ;; Valid only in Authenticated or Selected state
162
163 idle ::= "IDLE" CRLF "DONE" 9051:6594 ../imapserver/server.go:2824
164
165
166
167
168
169
170Leiba Standards Track [Page 3]
171
172RFC 2177 IMAP4 IDLE command June 1997
173
174
1755. References
176
177 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
178 4rev1", RFC 2060, December 1996.
179
1806. Security Considerations
181
182 There are no known security issues with this extension.
183
1847. Author's Address
185
186 Barry Leiba
187 IBM T.J. Watson Research Center
188 30 Saw Mill River Road
189 Hawthorne, NY 10532
190
191 Email: leiba@watson.ibm.com
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226Leiba Standards Track [Page 4]
227
228