Internet DRAFT - draft-lu-imap-multi-account
draft-lu-imap-multi-account
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]
