Pileus Git - ~andy/fetchmail/blob - RFC/rfc2177.txt

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