Network Working Group Y. Lu Internet Draft ZTE Corporation Intended status: Proposed Standard November 21, 2011 Expires: May 2012 IMAP4 Extension for Multi-Account Situations draft-lu-imap-multi-account-01.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and 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 May 21, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Lu Expires May 21, 2012 [Page 1] Internet-Draft IMAP4 Multi-Account Extension November 2011 Simultaneous authentication of multiple mail accounts belonging to a single user is an attractive feature but is not supported in the current Internet Message Access Protocol [RFC3501]. This document introduces an extension of the Internet Message Access Protocol, Version 4rev1 (IMAP4rev1). With this extension, when a client is authenticated with one of its user identifiers, all the other associated user identifiers (if present) are also regarded as authenticated ones. Furthermore, this document specifies the syntax of LISTA and SELECTA commands for the IMAP4rev1 protocol. With LISTA command, a client can obtain a list of all the identifiers authenticated for the user. With SELECTA command, a client can select one of the user's authenticated identifiers and then gain access to all the mailboxes belonging to that identifier, without having to log out and re-log in with that identifier. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. Specification..................................................3 3.1. Authentication of Associated Identifiers..................3 3.2. LISTA Command.............................................3 3.3. SELECTA Command...........................................4 4. Security Considerations........................................5 5. IANA Considerations............................................5 6. References.....................................................5 7. Acknowledgments................................................5 1. Introduction In practice, it's often desirable for a user to have multiple email accounts. However, according to the current Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) [RFC3501], if a user needs to access an account after he/she has been authenticated for a different one, he/she has to first log out of the current account and then be re-authenticated for the desired one. For the sake of a better user experience, this document introduces an extension of the IMAP4rev1 protocol. With this extension, a user can have multiple user identifiers associated with each other. Once one of the user's identifiers is successfully authenticated, all the other associated identifiers will also be treated as authenticated ones for the succeeding transactions. Furthermore, this document introduces LISTA and SELECTA commands into the IMAP4rev1 protocol. With LISTA command, a client can obtain a Lu Expires May 21, 2012 [Page 2] Internet-Draft IMAP4 Multi-Account Extension November 2011 list of all the authenticated identifiers bound to a certain identifier. With SELECTA command, a client, in an authenticated state, can select one of the user's authenticated identifiers and work on the mailboxes belonging to that selected identifier. Before implementing this command, it is assumed that the client has already been authenticated with multiple associated identifiers. The purpose of this SELECTA command is to allow the client to access the mailboxes or folders belonging to different user identifiers without having to log out and re-log in with a different user identifier. 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", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Specification 3.1. Authentication of Associated Identifiers A user's registration profile SHOULD indicate the association of the user's multiple identifiers, as requested by the user. During the authentication process initiated by a client's AUTHENTICATE or LOGIN command, the server SHOULD check that client's user registration profile to find out whether or not there are any other user identifiers associated with the one provided by the client in the authentication process. In the case where the client's user registration profile indicates the association of multiple user identifiers, once the client is successfully authenticated with the user identifier provided by the client in the authentication process, all those associated user identifiers listed in the registration profile SHOULD also be treated as authenticated ones for the succeeding transactions. In one word, a successful authentication for a single user identifier brings all the associated user identifiers into the authenticated states. 3.2. LISTA Command Arguments: user identifier Lu Expires May 21, 2012 [Page 3] Internet-Draft IMAP4 Multi-Account Extension November 2011 Responses: no specific responses for this command Result: OK - lista completed NO - lista failure: user identifier rejected BAD - command unknown or arguments invalid The LISTA command SHALL only be implemented when the connection is in the authenticated state. The LISTA command returns a list of all the authenticated user identifiers bound to the one given as the argument. An OK response represents a valid listing. Example: C: A001 LISTA bob1@abcd.com S: * 2 EXISTS S: * LISTA bob1@abcd.com S: * LISTA bob2@defg.com S: A001 OK LISTA completed 3.3. SELECTA Command Arguments: user identifier Responses: no specific responses for this command Result: OK - selecta completed NO - selecta failure: user identifier rejected BAD - command unknown or arguments invalid The SELECTA command SHALL only be implemented when the connection is in the authenticated state. The SELECTA command selects one of the associated user identifiers that have been authenticated for the user, as an active account. An OK response represents a valid selection and the succeeding operations are performed with respect to the selected user identifier. For instance, a SELECT command following a SELECTA command means the selection of a mailbox belonging to the user identifier chosen by the SELECTA command. Example: C: A140 SELECTA bob1@abcd.com S: A140 OK SELECTA completed C: A141 SELECT INBOX S: * 172 EXISTS S: * 1 RECENT S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited Lu Expires May 21, 2012 [Page 4] Internet-Draft IMAP4 Multi-Account Extension November 2011 S: A141 OK [READ-WRITE] SELECT completed (The mailbox "INBOX" belonging to the account "bob1@abcd.com" has been selected.) 4. Security Considerations There are no known security issues with this extension. 5. IANA Considerations 6. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. 7. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Yan LU ZTE Corporation 68 Zijinghua Road, Nanjing, China 210012 Email: luyan@zte.com.cn Jerry Shih AT&T Email: jerry.shih@ATT.COM Xin DING ZTE Corporation 68 Zijinghua Road, Nanjing, China 210012 Email: ding.xin@zte.com.cn Xiongwei Jia China Unicom Research Institute Email: jiaxw9@chinaunicom.cn Lu Expires May 21, 2012 [Page 5]