Browse Prior Art Database

IMAP4 IDLE command (RFC2177)

IP.com Disclosure Number: IPCOM000002735D
Original Publication Date: 1997-Jun-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 4 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

B. Leiba: AUTHOR

Related Documents

10.17487/RFC2177: DOI

Abstract

This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Network Working Group B. Leiba Request for Comments: 2177 IBM T.J. Watson Research Center Category: Standards Track June 1997

IMAP4 IDLE command

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

1. Abstract

The Internet Message Access Protocol [IMAP4] requires a client to poll the server for changes to the selected mailbox (new mail, deletions). It’s often more desirable to have the server transmit updates to the client in real time. This allows a user to see new mail immediately. It also helps some real-time applications based on IMAP, which might otherwise need to poll extremely often (such as every few seconds). (While the spec actually does allow a server to push EXISTS responses aysynchronously, a client can’t expect this behaviour and must poll.)

This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it’s ready to accept such real-time updates.

2. Conventions Used in this Document

In examples, "C:" and "S:" indicate lines sent by the client and server respectively.

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2060 [IMAP4].

3. Specification

IDLE Command

Arguments: none

Responses: continuation data will be requested; the client sends the continuation data "DONE" to end the command

Leiba Standards Track [Page 1]

RFC 2177 IMAP4 IDLE command June 1997

Result: OK - IDLE completed after client sent "DONE" NO - failure: the server will not allow the IDLE command at this time BAD - command unknown or arguments invalid

The IDLE command may be used with any IMAP4 server implementation that returns "IDLE" as one of the supported capabilities to the CAPABILITY command. If the server does not advertise the IDLE capability, the client MUST NOT use the IDLE command and must poll for mailbox updates. In particular, the client MUST continue to be able to accept unsolicited untagged responses to ANY command, as specified in the base IMAP specification.

The IDLE command is sent from the client to the server when the client is ready to accept unsolicited mailbox update messages. The server requests a response to the IDLE command using the continuation ("+") response. The IDLE command remains active until the client responds to the continuation, and as long as an IDLE command is active, the server is now free to send untagged EXISTS, EXPUNGE, and other messages at any time.

The IDLE command is terminated by the receipt of a "DONE" continuation from the client; such response satisfies the server’s continuation request. At that point, the server MAY send any remaining queued untagged responses and then MUST immediately send the ta...

Processing...
Loading...