[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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]