idnits 2.17.00 (12 Aug 2021) /tmp/idnits40671/draft-leiba-imap-idle-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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.) ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 73: '...lity, the client MUST NOT use the IDLE...' RFC 2119 keyword, line 74: '...icular, the client MUST continue to be...' RFC 2119 keyword, line 88: '...oint, the server MAY send any remainin...' RFC 2119 keyword, line 89: '...sponses and then MUST immediately send...' RFC 2119 keyword, line 97: '... The server MAY consider a client in...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 1997) is 9219 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 section? 'IMAP4' on line 155 looks like a reference -- Missing reference section? 'UIDVALIDITY 1' on line 109 looks like a reference -- Missing reference section? 'RFC-822' on line 142 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 5 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 Document: draft-leiba-imap-idle-01.txt February 1997 6 IMAP4 IDLE command 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the RFC 27 editor as a Proposed Standard for the Internet Community. Discussion 28 and suggestions for improvement are requested. This document will 29 expire before August 1997. Distribution of this draft is unlimited. 31 1. Abstract 33 The Internet Message Access Protocol [IMAP4] requires a client to poll 34 the server for changes to the selected mailbox (new mail, deletions). 35 It's often more desirable to have the server transmit updates to the 36 client in real time. This allows a user to see new mail immediately. 37 It also helps some real-time applications based on IMAP, which might 38 otherwise need to poll extremely often (such as every few seconds). 39 (While the spec actually does allow a server to push EXISTS responses 40 aysynchronously, a client can't expect this behaviour and must poll.) 42 Internet DRAFT IDLE February 26, 1997 44 This document specifies the syntax of an IDLE command, which will 45 allow a client to tell the server that it's ready to accept such 46 real-time updates. 48 2. Conventions Used in this Document 50 In examples, "C:" and "S:" indicate lines sent by the client and 51 server respectively. 53 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in 54 this document are to be interpreted as described in RFC 2060 [IMAP4]. 56 3. Specification 58 IDLE Command 60 Arguments: none 62 Responses: continuation data will be requested; the client sends 63 the continuation data "DONE" to end the command 65 Result: OK - IDLE completed after client sent "DONE" 66 NO - failure: the server will not allow the IDLE 67 command at this time 68 BAD - command unknown or arguments invalid 70 The IDLE command may be used with any IMAP4 server implementation 71 that returns "IDLE" as one of the supported capabilities to the 72 CAPABILITY command. If the server does not advertise the IDLE 73 capability, the client MUST NOT use the IDLE command and must poll 74 for mailbox updates. In particular, the client MUST continue to be 75 able to accept unsolicited untagged responses to ANY command, as 76 specified in the base IMAP specification. 78 The IDLE command is sent from the client to the server when the 79 client is ready to accept unsolicited mailbox update messages. The 80 server requests a response to the IDLE command using the continuation 81 ("+") response. The IDLE command remains active until the client 82 responds to the continuation, and as long as an IDLE command is 83 active, the server is now free to send untagged EXISTS, EXPUNGE, and 84 other messages at any time. 86 The IDLE command is terminated by the receipt of a "DONE" continuation 87 from the client; such response satisfies the server's continuation 88 request. At that point, the server MAY send any remaining queued 89 untagged responses and then MUST immediately send the tagged 90 response to the IDLE command and prepare to process other commands. 91 As in the base specification, the processing of any new command may 92 cause the sending of unsolicited untagged responses, subject to the 93 ambiguity limitations. 95 Internet DRAFT IDLE February 26, 1997 97 The server MAY consider a client inactive if it has an IDLE command 98 running, and if such a server has an inactivity timeout it MAY log 99 the client off implicitly at the end of its timeout period. Because 100 of that, clients using IDLE are advised to terminate the IDLE and 101 re-issue it at least every 29 minutes to avoid being logged off. 102 This still allows a client to receive immediate mailbox updates even 103 though it need only "poll" at half hour intervals. 105 Example: C: A001 SELECT INBOX 106 S: * FLAGS (\Deleted \Seen) 107 S: * 3 EXISTS 108 S: * 0 RECENT 109 S: * OK [UIDVALIDITY 1] 110 S: A001 OK SELECT completed 111 C: A002 IDLE 112 S: + idling 113 ...time passes; new mail arrives... 114 S: * 4 EXISTS 115 C: DONE 116 S: A002 OK IDLE terminated 117 ...another client expunges message 2 now... 118 C: A003 FETCH 4 ALL 119 S: * 4 FETCH (...) 120 S: A003 OK FETCH completed 121 C: A004 IDLE 122 S: * 2 EXPUNGE 123 S: * 3 EXISTS 124 S: + idling 125 ...time passes; another client expunges message 3... 126 S: * 3 EXPUNGE 127 S: * 2 EXISTS 128 ...time passes; new mail arrives... 129 S: * 3 EXISTS 130 C: DONE 131 S: A004 OK IDLE terminated 132 C: A005 FETCH 3 ALL 133 S: * 3 FETCH (...) 134 S: A005 OK FETCH completed 135 C: A006 IDLE 137 Internet DRAFT IDLE February 26, 1997 139 4. Formal Syntax 141 The following syntax specification uses the augmented Backus-Naur 142 Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. 143 Non-terminals referenced but not defined below are as defined by 144 [IMAP4]. 146 command_auth ::= append / create / delete / examine / list / lsub / 147 rename / select / status / subscribe / unsubscribe 148 / idle 149 ;; Valid only in Authenticated or Selected state 151 idle ::= "IDLE" CRLF "DONE" 153 5. References 155 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 156 4rev1", RFC 2060 158 6. Security Considerations 160 There are no known security issues with this extension. 162 7. Author's Address 164 Barry Leiba 165 IBM T.J. Watson Research Center 166 30 Saw Mill River Road 167 Hawthorne, NY 10532 169 Email: leiba@watson.ibm.com