home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2177 < prev    next >
Text File  |  1997-07-01  |  7KB  |  228 lines
  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.  
  228.