|
0
|
1
|
|
|
2
|
|
|
3
|
|
|
4
|
|
|
5
|
|
|
6
|
|
|
7 Network Working Group B. Leiba
|
|
|
8 Request for Comments: 2177 IBM T.J. Watson Research Center
|
|
|
9 Category: Standards Track June 1997
|
|
|
10
|
|
|
11
|
|
|
12 IMAP4 IDLE command
|
|
|
13
|
|
|
14 Status 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
|
|
|
22 1. 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
|
|
|
38 2. 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
|
|
|
47 3. Specification
|
|
|
48
|
|
|
49 IDLE Command
|
|
|
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
|
|
|
58 Leiba Standards Track [Page 1]
|
|
|
59
|
|
|
60 RFC 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
|
|
|
114 Leiba Standards Track [Page 2]
|
|
|
115
|
|
|
116 RFC 2177 IMAP4 IDLE command June 1997
|
|
|
117
|
|
|
118
|
|
|
119 Example: C: A001 SELECT INBOX
|
|
|
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
|
|
|
151 4. 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"
|
|
|
164
|
|
|
165
|
|
|
166
|
|
|
167
|
|
|
168
|
|
|
169
|
|
|
170 Leiba Standards Track [Page 3]
|
|
|
171
|
|
|
172 RFC 2177 IMAP4 IDLE command June 1997
|
|
|
173
|
|
|
174
|
|
|
175 5. References
|
|
|
176
|
|
|
177 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
|
|
|
178 4rev1", RFC 2060, December 1996.
|
|
|
179
|
|
|
180 6. Security Considerations
|
|
|
181
|
|
|
182 There are no known security issues with this extension.
|
|
|
183
|
|
|
184 7. 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
|
|
|
226 Leiba Standards Track [Page 4]
|
|
|
227
|
