bincimap

Log | Files | Refs | LICENSE

rfc2177.txt (6770B)


      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