Internet Draft: IMAP Extension for CLEARIDLE M. Wener Document: draft-wener-lemonade-clearidle-02.txt Nokia, Inc. Expires: August 2005 February 2005 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 following set of responses are listed as the set needed for client clarification. It is intended that this set be adequate for a client to maintain synchronization of all information except the message body part content. 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. The following attribute is re-used from [LISTEXT]. \NonExistent 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 that may imply the mailbox currently exists. 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 \NonExistent name attribute. Example: S: * LIST (\NonExistent) "/" ~/NewFolder 3) If a folder is renamed a LIST response is sent. The response will contain both the old name and a new name. The old name is in the place of the folder name in a normal LIST response. The new name is communicated via a referral URL. Example: S: * LIST () "/" ~/OldName (REFERRAL imap://mail/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 (\Seen) UID 789) New Message Arrival An unsolicited FETCH response with bodystructure, flag and uid data MUST be sent on all IDLE connections. Example: S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE (...) BODYSTRUCTURE (...)) 2.3 STATUS Response The STATUS 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 any folder and the IDLE command was issued in the Authenticated state. If the IDLE command was issued in the Selected state then only expunges from the currently selected folder are sent. 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 serve for any folder. LIST Response STATUS 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 ")" CRLF Example: S: * 8 FETCH (FLAGS (\Seen) UID 789) (imap://mail/inbox/;UID=789) The following BNF is used for LIST reponses. All LIST responses are as defined in [IMAP4] except in the case of a renamed folder. mbxurl = "imap://" iserver "/" enc_mailbox ;See [IMAP-URL] for "enc_mailbox" definition list-data = "LIST" SP mailbox-list [SP "REFERRAL" SP mbxurl] CRLF ; See [IMAP4] for mailbox-list Example: S: * LIST () "/" ~/OldName REFERRAL (imap://mail/newname) The following BNF is used for mailbox specific responses: status-nocrlf = "STATUS" SP mailbox SP "(" status-att2 *(SP status-att2) ")" status-att2 = "MESSAGES" / "RECENT" Example: S: * STATUS INBOX (MESSAGES 231 RECENT 7) 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. All of the following responses only occur if the response applies to teh currently selected mailbox. STATUS Response FETCH Response EXPUNGE Response LIST Response EXISTS Response RECENT Response 4 Author Michael J. Wener 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 [LISTEXT] Leiba, B., Melnikov, A., IMAP4 LIST Command Extensions draft-ietf-imapext-list-extensions-11