Network Working Group M. Konold Internet-Draft Erfrakon Partnerschaftsgesellschaft Intended status: Informational November 22, 2006 Expires: December 20, 2006 IMAP4 IDLEPLUS extension draft-konold-imap-idleplus-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 20, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 0. 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 IDLEPLUS command, which will allow a client to tell the server that it's ready to accept such real-time updates. The addition to the older RFC 2177 is that the updates are not limited to the currently selected folder but are sent for all folders and all client visible namespaces. The folder name is postfixed to the familiar messages from RFC 2177. 1. Change History (to be removed prior to publication as an RFC) Version 03 Introduced command uid mailbox uidvalidity syntax. Add support for FLAGS. Version 02 Add note about not missing notifications when using a single connection. Version 01 Add support for notifications about folder changes. Add support for folder state changes e.g. read-only. Version 00 Initial version derived from RFC 2177. 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 IDLEPLUS Command Arguments: none Responses: continuation data will be requested; the client sends the continuation data "DONE" to end the command Konold Internet-Draft [Page 1] draft IMAP4 IDLEPLUS command November 2006 Result: OK - IDLEPLUS completed after client sent "DONE" NO - failure: the server will not allow the IDLEPLUS command at this time BAD - command unknown or arguments invalid The IDLEPLUS command may be used with any IMAP4 server implementation that returns "IDLEPLUS" as one of the supported capabilities to the CAPABILITY command. If the server does not advertise the IDLEPLUS capability, the client MUST NOT use the IDLEPLUS 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 IDLEPLUS 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 IDLEPLUS command using the continuation ("+") response. The IDLEPLUS command remains active until the client responds to the continuation, and as long as an IDLEPLUS command is active, the server is now free to send untagged EXISTS, EXPUNGE, and other messages at any time. Especially the IDLEPLUS capable server also informs about CREATE, DELETE and RENAME operations of folders. The IDLEPLUS 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 tagged response to the IDLEPLUS command and prepare to process other commands. As in the base specification, the processing of any new command may cause the sending of unsolicited untagged responses, subject to the ambiguity limitations. The client MUST NOT send a command while the server is waiting for the DONE, since the server will not be able to distinguish a command from a continuation. The server MAY consider a client inactive if it has an IDLEPLUS command running, and if such a server has an inactivity timeout it MAY log the client off implicitly at the end of its timeout period. Because of that, clients using IDLEPLUS are advised to terminate the IDLEPLUS and re-issue it at least every 29 minutes to avoid being logged off. This still allows a client to receive immediate mailbox updates even though it need only "poll" at half hour intervals. In order to avoid the poll at half hour intervals the client may send another IDLEPLUS command before the older is timed out. In order to receive notifications out-of band a client may make sure that always an IDLEPLUS connection in addition to the normal imap data connection is established. Please note that an additional connection is not required in order not to miss any notifications. This is due to the fact that the server queues the events until the client is idle. Defining how to control which user accessible folders are subject to announcing updates to the clients using IDLEPLUS is beyond the scope of this document. Clients may enable and disable IDLEPLUS messages for specific folders using [METADATA] folder annotations. On the other hand clients may list the currently exposed folders using [LIST-EXTENDED]. Servers without the [METADATA] or [LIST-EXTENDED] capability may choose to consider all folders to be subject to IDLEPLUS update messages. The default is that the subscribed mailboxes as returned by the LSUB command are subject to announcing updates to the clients using IDLEPLUS. For efficiency reasons servers may replace the original imap server with an idleplus server in case the connection is in IDLEPLUS mode. Konold Internet-Draft [Page 2] draft IMAP4 IDLEPLUS command November 2006 Example: C: A001 SELECT INBOX S: * FLAGS (Deleted Seen) S: * 3 EXISTS S: * 0 RECENT S: * OK [UIDVALIDITY 1] S: A001 OK SELECT completed C: A002 IDLEPLUS S: + idling ...time passes; new mail arrives in INBOX, UIDVALIDITY is postfixed S: * 4 EXISTS INBOX 1 C: DONE S: A002 OK IDLEPLUS terminated ...another client expunges message 2 with uid 333 now in INBOX C: A003 FETCH 4 ALL S: * 4 FETCH (...) S: A003 OK FETCH completed C: A004 IDLEPLUS S: + idling ... the expunge message is using the UID 333 not the message sequence number! S: * EXPUNGE 333 INBOX 1 S: * 3 EXISTS ...time passes; another client expunges message 3... S: * EXPUNGE 334 INBOX 1 S: * 2 EXISTS INBOX 1 ...time passes; new mail arrives... S: * 3 EXISTS INBOX 1 C: DONE S: A004 OK IDLEPLUS terminated C: A005 FETCH 3 ALL S: * 3 FETCH (...) S: A005 OK FETCH completed ... INBOX is still the selected folder C: A006 IDLEPLUS S: + idling ...time passes; another client expunges message 2 with uid 11 in INBOX/subfolder S: * EXPUNGE 11 INBOX/subfolder 2 S: * 1 EXISTS INBOX/subfolder 2 ...time passes; new mail arrives in INBOX/subfolder S: * 2 EXISTS INBOX/subfolder 2 C: DONE S: A006 OK IDLEPLUS terminated C: A007 SELECT INBOX/subfolder S: * FLAGS (Deleted Seen) S: * 2 EXISTS S: * 1 RECENT S: * OK [UIDVALIDITY 3] S: A007 OK SELECT completed C: A008 FETCH 2 ALL S: * 2 FETCH (...) S: A009 OK FETCH completed ... INBOX/subfolder is still the selected folder C: A010 IDLEPLUS S: + idling ... time passes; another client renames INBOX/subfolder with uidvalitity 3 to INXBOX/anotherfolder with uidvalidity 4 S: * RENAME INBOX/subfolder 3 INBOX/anotherfolder 4 ... time passes; another client deletes INBOX/anotherfolder S: * DELETE INBOX/anotherfolder 4 ... time passes; another client (re)creates INBOX/subfolder S: * CREATE INBOX/subfolder 5 ... time passes; another client sets ACLs so that INBOX/subfolder is read only to logged in user S: * READ-ONLY INBOX/subfolder 5 ... time passes; another client sets ACLs so that INBOX/subfolder is read-write to logged in user S: * READ-WRITE INBOX/subfolder 5 ... time passes; another client but same user subscribed to INBOX/somefolder S: * SUBSCRIBE INBOX/somefolder 6 S: * 3 EXISTS INBOX/somefolder 6 S: * 0 RECENT INBOX/somefolder 6 ... time passed; another client deleted all three messages in somefolder S: * STORE 444:445:449 INBOX/somefolder 6 +FLAGS (\Deleted) ... time passed; server sends an out-of-band alert which shall be presented to the user as soon as possible S: * OK [ALERT] System shutdown in 10 minutes C: DONE C: A011 LOGOUT S: * BYE IMAP4rev1 server terminating connection S: A011 OK LOGOUT completed 4. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. Non-terminals referenced but not defined below are as defined by [IMAP4]. command_auth ::= append / create / delete / examine / list / lsub / rename / select / status / subscribe / idle / unsubscribe / idleplus ;; Valid only in Authenticated or Selected state idleplus ::= "IDLEPLUS" CRLF "DONE" Konold Internet-Draft [Page 3] draft IMAP4 IDLEPLUS command November 2006 5. References [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. [IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997 [METADATA] Daboo, C., "IMAP METADATA Extension", draft-daboo-imap-annotatemore-10, October 19, 2006 [LIST-EXTENDED] Leiba, B., Melnikov, A., "IMAP4 LIST Command Extensions", draft-ietf-imapext-list-extensions-18, September 21, 2006 6. Security Considerations There are no known security issues with this extension. 7. Author's Address Martin Konold erfrakon Partnerschaftsgesellschaft Adolfstrasse 23 70569 Stuttgart Germany Email: martin.konold@erfrakon.de 8. Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Konold Internet-Draft [Page 4] draft IMAP4 IDLEPLUS command November 2006