Internet Draft: IMAP Extension for CLEARIDLE M. Wener Document: draft-wener-lemonade-clearidle-00.txt Nokia, Inc. Expires: March 2005 October 2004 IMAP Extension for CLEARIDLE Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Abstract The IMAPRev4 specification supports unsolicited responses being sent to a client at any time. The IDLE specification defines a way for a client to sit in an idle connection waiting to receive these responses. This document clarifies and extends the set of responses that a client may receive while in the idle state. The desire is to allow a client to predict exactly what set of unsolicited responses it can rely on receiving when listening on an idle connection. 1. Introduction and Overview The CLEARIDLE extension is present in any IMAP implementation that returns "CLEARIDLE" as a supported extension in the CAPABILITY response. The current set of IMAP RFCs provide an unambiguous way to deliver unsolicited responses to a client. A client may use these responses to gain information about the current state of the mailboxes on the server. The problem is that the set of responses a client may receive is ambiguous. A client has no way to reliably predict that given a certain state change on the server a response communicating this change will be sent. The IMAP specification allows unsolicited responses to be sent on a client connection at any time. This extension adds predictability to the set of responses sent by a server during an IDLE session. Predictability is accomplished by stating what responses must be sent as the result of a corresponding event on the server. A new extension is used to allow servers to clearly state if this more rigorous definition of IDLE is adhered to. The IDLE command is a legal command in both the Authenticated and Selected state. While in the Selected state it is intuitive that only responses related to the selected mailbox would be returned. It is not as clear what should be returned while in the Authenticated state. This document clarifies this. When a response is received while in the Authenticated state it may be that the response alone would be ambiguous as to which mailbox the response pertained to. When this situation occurs an IMAP URL is appended to the response to clarify which mailbox the response is associated with. 2. IMAP Protocol The CHECKPOINT extension [CHECKPOINT] MUST be supported if CLEARIDLE is supported. The dictates of this extension only apply while an IDLE CHECKPOINT session is active. 2.1 LIST Response Currently the LIST response occurs as the result of a LIST command. This document modifies the syntax of a LIST response and also defines it's occurrence as a legal unsolicited response that could be received on IDLE connections associated with a user. Two new name attributes are defined: \Deleted The mailbox has been deleted and no longer exists. After a LIST response with this attribute is seen the server will no longer show the named folder in any LIST commands. There MUST NOT be any other name attributes sent along with this attribute. \Renamed The mailbox has been renamed. A second LIST response MUST immediately follow indicating the new name. A server MUST send a LIST response on all idle connections if one of the following events occurs on the server: 1) If a new folder is created a LIST response is sent with all name attributes that apply at the time of creation. The name of the folder MUST be fully qualified. Example: S: * LIST (\Noinferiors) "/" ~/NewFolder 2) If a folder is deleted a LIST response is sent with only the \Deleted name attribute. Example: S: * LIST (\Deleted) "/" ~/NewFolder 3) If a folder is renamed two LIST responses are sent. The first indicating the old name and a \Renamed attribute and a second response MUST immediately follow the first indicating the new name. The \Renamed attribute is very similar to the \Deleted attribute. The reason the \Deleted attribute is not used is to allow the client two distinct processing paths. One for a delete and another for a rename. It is likely that in the case of a delete a more thorough removal of the folder would occur. Example: S: * LIST (\Renamed) "/" ~/OldName S: * LIST (\Noinferiors) "/" ~/NewName 2.2 FETCH Response Currently the FETCH response occurs as the result of a FETCH command or as an unsolicited response on an IDLE connection. This document clarifies exactly what form of response should be sent when the specified events occur on the server. There are two forms of the FETCH response to be sent while this extension is in play. The first is if the message flag state changes, and the second is if a new message arrives. The response indicates the current state of the message. Flag State Change An unsolicited FETCH response with flag and uid data MUST be sent on all IDLE connections. Example: S: * 8 FETCH (FLAGS (\Deleted) UID 789) New Message Arrival An unsolicited FETCH response with envelope, body, flag and uid data MUST be sent on all IDLE connections. Example: S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE (...) BODY (...)) 2.3 EXISTS Response The EXISTS response MUST be sent on all IDLE connections if the size of a mailbox changes. This does not include when the size decreases due to an EXPUNGE. 2.4 EXPUNGE Response The EXPUNGE response MUST be sent on all IDLE connections if a message is deleted from a folder. 3 Response Clarification A server supporting the CLEARIDLE extension must send a well defined set of responses depending on which state the server is in. The client must be able to predict that it will receive specific responses on an idle connection given a particular event on the sever. 3.1 Authenticated State If the IDLE command is sent while in the Authenticated state then the following unsolicited responses MUST be sent if the corresponding event occurs on the server. LIST Response RECENT Response EXISTS Response FETCH Response EXPUNGE Response Those that require disambiguation MUST contain an IMAP URL as per section 3.1.1. 3.1.1 Mailbox Identification Syntax While in the Authenticated state there is no way to implicitly determine which mailbox the response applies to. While this is not a problem for some responses such as the LIST response it does pose a problem for responses that are mail message specific. The URL syntax standardized [IMAP-URL] for IMAP MUST be used to disambiguate a response when it is required. The following BNF is used for message specific responses: msgurl = "imap://" iserver "/" imessagepart ;See [IMAP-URL] for "iserver" definition imessagepart = enc_mailbox [uidvalidity] iuid ;See [IMAP-URL] for "enc_mailbox" definition iuid = "/;UID=" nz-number ;See [IMAP4] for "nz-number" definition uidvalidity = ";UIDVALIDITY=" nz-number ;See [IMAP4] for "nz-number" definition msgresponse = "FETCH" / "EXPUNGE" msgres-nocrlf = "*" SP nz-number msgresponse d1response = msgres-nocrlf SP "(" msgurl ")" [SP seqnumpart] CRLF ;See [CHECKPOINT] for "seqnumpart" definition Example: S: * 8 FETCH (FLAGS (\Seen) UID 789) (imap://mail/inbox/;UID=789) The following BNF is used for mailbox specific responses: mbxurl = "imap://" iserver "/" enc_mailbox ;See [IMAP-URL] for "enc_mailbox" definition mbxresponse = "RECENT" / "EXISTS" mbxres-nocrlf = "*" SP number mbxresponse ;See [IMAP4] for "number" definition d2response = mbxres-nocrlf SP "(" mbxurl ")" [SP seqnumpart] CRLF ;See [CHECKPOINT] for "seqnumpart" definition Example: S: * 22 EXISTS (imap://mail/inbox) 3.2 Selected State If the IDLE command is sent while in the Selected state then the following unsolicited responses MUST be sent if the corresponding event occurs on the server. RECENT Response EXISTS Response FETCH Response EXPUNGE Response 4 Author Michael J. Wener Enterprise Mobility Systems Nokia, Inc. EMail: Michael.Wener@Nokia.com 5 Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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. 6 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org." References [IMAP4] Crispin, M., "Internet Message Access Protocol Version 4rev1", RFC 3501, March 2003. [IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. [IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997 [CHECKPOINT] Wener, M., draft-wener-imapext-checkpoint-00.txt