idnits 2.17.1 draft-leiba-imap-2177bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 262. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 275. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC2177, but the abstract doesn't seem to directly say this. It does mention RFC2177 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 7, 2005) is 6715 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UIDVALIDITY 1' is mentioned on line 173, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Leiba 3 Internet-Draft IBM T.J. Watson Research Center 4 Obsoletes: 2177 (if approved) December 7, 2005 5 Expires: June 10, 2006 7 IMAP4 IDLE command 8 draft-leiba-imap-2177bis-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 10, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 The Internet Message Access Protocol requires a client to poll the 42 server for changes to the selected mailbox (new mail, deletions). 43 It's often more desirable to have the server transmit updates to the 44 client in real time. This allows a user to see new mail immediately. 45 It also helps some real-time applications based on IMAP, which might 46 otherwise need to poll extremely often (such as every few seconds). 47 (While the spec actually does allow a server to push EXISTS responses 48 asynchronously, a client can't expect this behaviour and must poll.) 49 This document specifies the syntax of an IDLE command, which will 50 allow a client to tell the server that it's ready to accept such 51 real-time updates. 53 Note 55 This document is intended to be an update to the existing "IDLE" 56 extension to the IMAP protocol, available from the RFC repository as 57 ftp://ftp.isi.edu/in-notes/rfc2177.txt. 59 This document and other IMAP extensions are being discussed on the 60 imapext mailing list at mailto:ietf-imapext@imc.org. Subscription 61 requests can be sent to 62 mailto:ietf-imapext-request@imc.org?body=subscribe (send an email 63 message with the word "subscribe" in the body). More information on 64 the mailing list along with a WWW archive of back messages is 65 available at http://www.imc.org/ietf-imapext/. 67 Table of Contents 69 1. Conventions used in this document . . . . . . . . . . . . . . 4 71 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 77 5. Changes since RFC 2177 . . . . . . . . . . . . . . . . . . . . 9 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 85 Intellectual Property and Copyright Statements . . . . . . . . 11 87 1. Conventions used in this document 89 In examples, "C:" and "S:" indicate lines sent by the client and 90 server respectively. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to 94 be interpreted as described in [Keywds]. 96 2. Specification 98 IDLE Command 100 Arguments: none 102 Responses: continuation data will be requested; the client sends the 103 continuation data "DONE" to end the command 105 Result: OK - IDLE completed after client sent "DONE" 107 NO - failure: the server will not allow the IDLE command 108 at this time 110 BAD - command unknown or arguments invalid 112 The IDLE command may be used with any IMAP4 server implementation 113 that returns "IDLE" as one of the supported capabilities to the 114 CAPABILITY command. If the server does not advertise the IDLE 115 capability, the client MUST NOT use the IDLE command and must poll 116 for mailbox updates. In particular, the client MUST continue to be 117 able to accept unsolicited untagged responses to ANY command (not 118 just to the IDLE command), as specified in the base IMAP 119 specification. 121 The IDLE command is sent from the client to the server when the 122 client is ready to accept unsolicited messages from the server. The 123 server requests a response to the IDLE command using the continuation 124 ("+") response. The IDLE command remains active until the client 125 responds to the continuation, and as long as an IDLE command is 126 active, the server is now free to send ANY untagged responses. IMAP 127 servers will frequently send unsolicited responses such as these: 129 o EXISTS, to inform the client about a change in the number of 130 messages in the currently-selected mailbox. 132 o EXPUNGE, to inform the client that a message has been expunged. 134 o FETCH, to inform the client about a change in the status of a 135 message (usually to convey flag changes). 137 o RECENT, to inform the client that the number of messages with the 138 \Recent flag has changed. This response often accompanies EXISTS. 140 But note again that what the server may send is not limited to that 141 list -- ANY untagged response may appear. 143 The IDLE command is terminated by the receipt of a "DONE" 144 continuation from the client; such response satisfies the server's 145 continuation request. At that point, the server MAY send any 146 remaining queued untagged responses and then MUST immediately send 147 the tagged response "OK" to the IDLE command and prepare to process 148 other commands. As in the base specification, the processing of any 149 new command may cause the sending of unsolicited untagged responses, 150 subject to the ambiguity limitations. The client MUST NOT send a 151 command while the server is waiting for the DONE, since the server 152 will not be able to distinguish a command from a continuation. If 153 the server receives anything other than "DONE" from the client, this 154 is a protocol violation and the server SHOULD terminate the IDLE 155 command with a tagged response of "BAD". 157 The server MAY consider a client inactive if it has an IDLE command 158 running, and if such a server has an inactivity timeout it MAY log 159 the client off implicitly at the end of its timeout period. Because 160 of that, clients using IDLE are advised to terminate the IDLE and re- 161 issue it at least every 29 minutes to avoid being logged off. This 162 still allows a client to receive immediate mailbox updates even 163 though it need only "poll" at half hour intervals. 165 3. Example 167 The following is an example of an IMAP session using IDLE. 169 C: A001 SELECT INBOX 170 S: * FLAGS (Deleted Seen) 171 S: * 3 EXISTS 172 S: * 0 RECENT 173 S: * OK [UIDVALIDITY 1] 174 S: A001 OK SELECT completed 175 C: A002 IDLE 176 S: + idling 177 ...time passes; another client sets a flag on message 2... 178 S: * 2 FETCH (FLAGS (\Seen \Answered \Flagged)) 179 ...time passes; new mail arrives... 180 S: * 4 EXISTS 181 C: DONE 182 S: A002 OK IDLE terminated 183 ...another client expunges message 2 now... 184 C: A003 FETCH 4 ALL 185 S: * 4 FETCH (...) 186 S: A003 OK FETCH completed 187 C: A004 IDLE 188 S: * 2 EXPUNGE 189 S: * 3 EXISTS 190 S: + idling 191 ...time passes; another client expunges message 3... 192 S: * 3 EXPUNGE 193 S: * 2 EXISTS 194 ...time passes; new mail arrives... 195 S: * 3 EXISTS 196 C: DONE 197 S: A004 OK IDLE terminated 198 C: A005 FETCH 3 ALL 199 S: * 3 FETCH (...) 200 S: A005 OK FETCH completed 201 C: A006 IDLE 203 4. Formal Syntax 205 The following syntax specification uses the augmented Backus-Naur 206 Form (BNF) notation as specified in [ABNF]. Non-terminals referenced 207 but not defined below are as defined by [IMAP4]. 209 command_auth =/ idle 210 ; Valid only in Authenticated or Selected state 212 idle = "IDLE" CRLF "DONE" 214 5. Changes since RFC 2177 216 1. Updated references to current versions. 218 2. Updated ABNF to current syntax. 220 3. Added example of unsolicited FETCH response. 222 4. Clarified that ANY response may come from the server during IDLE, 223 and gave examples of the most common responses. 225 5. Clarified that anything other than "DONE" is "BAD". 227 6. Security Considerations 229 There are no known security issues with this extension. 231 7. Normative References 233 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 234 Specifications: ABNF", RFC 4234, October 2005. 236 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 237 4rev1", RFC 3501, March 2003. 239 [Keywds] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", RFC 2119, March 1997. 242 Author's Address 244 Barry Leiba 245 IBM T.J. Watson Research Center 246 19 Skyline Drive 247 Hawthorne, NY 10532 248 US 250 Phone: +1 914 784 7941 251 Email: leiba@watson.ibm.com 253 Intellectual Property Statement 255 The IETF takes no position regarding the validity or scope of any 256 Intellectual Property Rights or other rights that might be claimed to 257 pertain to the implementation or use of the technology described in 258 this document or the extent to which any license under such rights 259 might or might not be available; nor does it represent that it has 260 made any independent effort to identify any such rights. Information 261 on the procedures with respect to rights in RFC documents can be 262 found in BCP 78 and BCP 79. 264 Copies of IPR disclosures made to the IETF Secretariat and any 265 assurances of licenses to be made available, or the result of an 266 attempt made to obtain a general license or permission for the use of 267 such proprietary rights by implementers or users of this 268 specification can be obtained from the IETF on-line IPR repository at 269 http://www.ietf.org/ipr. 271 The IETF invites any interested party to bring to its attention any 272 copyrights, patents or patent applications, or other proprietary 273 rights that may cover technology that may be required to implement 274 this standard. Please address the information to the IETF at 275 ietf-ipr@ietf.org. 277 Disclaimer of Validity 279 This document and the information contained herein are provided on an 280 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 281 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 282 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 283 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 284 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 285 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 287 Copyright Statement 289 Copyright (C) The Internet Society (2005). This document is subject 290 to the rights, licenses and restrictions contained in BCP 78, and 291 except as set forth therein, the authors retain all their rights. 293 Acknowledgment 295 Funding for the RFC Editor function is currently provided by the 296 Internet Society.