Mercurial > hgrepos > hgweb.cgi > imapext
comparison docs/rfc/rfc2177.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| -1:000000000000 | 0:ada5e610ab86 |
|---|---|
| 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 |
