Network Working Group A. Melnikov
Internet-Draft Isode Ltd
Expires: September 2, 2005 C. Wilson
Nokia
March 2005
IMAP4 Extensions for Quick Reconnect
draft-ietf-lemonade-reconnect-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 September 2, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a quick reconnect IMAP4 extension, which gives
a mobile client the ability to resume a previously abandoned session,
without the need to perform a full synchronization sequence. The
goal is to minimize the ammount of data transfered at login after a
dropped connection.
Melnikov & Wilson Expires September 2, 2005 [Page 1]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4
2.1 Typical IMAP Session . . . . . . . . . . . . . . . . . . . 5
2.2 Reconnect IMAP Session . . . . . . . . . . . . . . . . . . 8
3. LOGIN and AUTHENTICATE commands . . . . . . . . . . . . . . . 10
3.1 Extended LOGIN command . . . . . . . . . . . . . . . . . . 10
3.2 Extended AUTHENTICATE command . . . . . . . . . . . . . . 12
3.3 Resuming existing session . . . . . . . . . . . . . . . . 14
3.4 Creating a new session . . . . . . . . . . . . . . . . . . 17
4. PRESERVE parameter to LOGOUT command . . . . . . . . . . . . . 18
5. New responses . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 FOLDER Response . . . . . . . . . . . . . . . . . . . . . 19
5.2 NEWSID Response . . . . . . . . . . . . . . . . . . . . . 19
5.3 NOSID Response . . . . . . . . . . . . . . . . . . . . . . 19
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1 Normative References . . . . . . . . . . . . . . . . . . . 24
9.2 Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 26
Melnikov & Wilson Expires September 2, 2005 [Page 2]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
1. Requirements notation
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 [RFC2119].
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
"Resumable session" (or just "session") refers to the entire sequence
of client/server interaction from the initial session creation during
LOGIN/AUTHENTICATE command until it is explicitly deleted upon client
request or until the session expires some time after disconnect. A
resumable session can be terminated by the [RFC3501] LOGOUT command.
Note, that a resumable session doesn't terminate when the connection
is lost or closed with LOGOUT (PRESERVE) command (see Section 4).
Also note that this term has a different meaning from the term
"session" used by [RFC3501].
The term "event" is as defined in [C2S].
Melnikov & Wilson Expires September 2, 2005 [Page 3]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
2. Introduction and Overview
The IMAP4 protocol do not distinguish between a session that has been
disconnected for 15 seconds and one that has been disconnected for 1
week. The assumption is the same: The client and server may be
completely out of sync and the client must ensure that it is
completely synchronized with the server.
In todays mobile environments, accidental disconnects due to
environmental factors (battery life, signal strength, etc.) can be
quite common. In these situtations, the time between the disconnect
and reconnect can be less that a minute. It is these situations
which we are interested in.
If the time between connections is sufficiently short, an assumption
can be made that the state of the last connection is still valid and
that the client can avoid having to query much of the state data at
reconnect.
[[anchor3: Note to RFC editor: This document is compliant with
"transitional IMAP capabilities" document [TRANS-CAPA]. Please
change the capability name below to "RECONNECT"]]
The quick reconnect IMAP extension is present if an IMAP4 server
returns "X-DRAFT-W03-RECONNECT" as one of the supported capabilities
to the CAPABILITY command. Note, that this extension REQUIREs
support for the [CONDSTORE] and the [EXPUNGED] IMAP extensions, so it
MUST be announced in the CAPABILITY response as well.
The text below outlines how quick reconnect extension is to be used.
The description assumes the the quick reconnect is mainly used when
the client closes the TCP connection (intentionally or accidentally)
and tries to reconnect within a preset amount of time.
1. The client authenticates and ask the server to creates a new
session by specifying a NEWSID parameter to LOGIN/AUTHENTICATE
command. The server generates a new Session ID (SID) and returns
it to the client.
2. The client optionally opens a mailbox and does other things.
3. At some point the client loses connectivity. The server retains
all information about the client's session, including information
about the currently selected mailbox, for some amount of time.
Melnikov & Wilson Expires September 2, 2005 [Page 4]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
(case a) The client reconnects before the session timeout.
It authenticates as the same user as before and specifies the
previously used session ID. The client and server begin at
the same mailbox as before the reconnect.
(case b) The client reconnects after the session timeout.
It authenticates as the same user and specifies the previously
used session ID. Since the session has timed out on the
server, the server has no record of this session and creates a
new session. This behaviour deprecates to a normal IMAPv4
login.
2.1 Typical IMAP Session
A typical IMAP client session looks as follows:
(Modified dump from network sniffer)
S: * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN]
imap.mail.com IMAP4rev1 2001.315rh at Thu, 15 Jul 2004 11:47:49
-0400 (EDT)
C: 2 authenticate login
S: + VXNlciBOYW1lAA==
C: dGVzdDg=
S: + UGFzc3dvcmQA
C: dGVzdDg=
S: 2 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN
SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User
test8 authenticated
C: 3 namespace
S: * NAMESPACE (("" "/")("#mhinbox" NIL)("#mh/" "/")) (("~" "/"))
(("#shared/" "/")("#ftp/" "/")("#news." ".")("#public/" "/"))
S: 3 OK completed
C: 4 lsub "" "*"
Melnikov & Wilson Expires September 2, 2005 [Page 5]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
S: 4 OK LSUB completed
C: 5 lsub "" "#mhinbox*"
S: 5 OK LSUB completed
C: 6 lsub "" "#mh/*"
S: * NO /home/test8/.mh_profile not found, mh format names disabled
S: 6 OK LSUB completed
C: 7 lsub "" "~*"
S: 7 OK LSUB completed
C: 8 lsub "" "#shared/*"
S: 8 OK LSUB completed
C: 9 lsub "" "#ftp/*"
S: 9 OK LSUB completed
C: 10 lsub "" "#news.*"
S: 10 OK LSUB completed
C: 11 lsub "" "#public/*"
S: 11 OK LSUB completed
C: 12 list "" "INBOX"
S: * LIST (\NoInferiors) NIL INBOX
S: 12 OK LIST completed
C: 13 list "" "Trash"
S: 13 OK LIST completed
C: 14 create "Trash"
S: 14 NO CREATE failed: Can't create mailbox node /home/test8/:
Permission denied
Melnikov & Wilson Expires September 2, 2005 [Page 6]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
C: 15 select "INBOX"
S: * 464 EXISTS
S: * 3 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 550] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: 15 OK [READ-WRITE] SELECT completed
C: 16 UID fetch 1:* (FLAGS)
S: * 1 FETCH (UID 41 FLAGS (\Seen))
S: * 2 FETCH (UID 43 FLAGS (\Seen \Flagged))
S: ...
S: * 464 FETCH (UID 541 FLAGS (Junk))
S: 16 fetch completed
C: 17 IDLE
S: + Waiting for DONE
(Note, that the client has recoqnized the CAPABILITY response code in
the initial OK response, it has omitted the CAPABILITY command.)
The above dump was generated usig Ethereal and it reported that the
above process generated just under 20 KB of data.
The above protocol sequence simply logged the user into the account,
selected the INBOX mailbox, downloaded the updated flags for a subset
of messages, and then went IDLE waiting for another command.
All this before the user can even start using the client program.
Melnikov & Wilson Expires September 2, 2005 [Page 7]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
2.2 Reconnect IMAP Session
Now lets look at the same mailbox, but see how the protocol would
react if the user had droped connection and was reconnecting within a
few minutes.
As in the previous section, the client has recognized the CAPABILITY
response code in the initial OK response, so it has omitted the
CAPABILITY command.
S: * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN
CONDSTORE X-DRAFT-I01-EXPUNGED X-DRAFT-W03-RECONNECT]
imap.example.com IMAP4rev1 2001.315rh at Thu, 15 Jul 2004 11:47:49
-0400 (EDT)
C: 2 authenticate login (SID P1234567890 56789 20010715194045000
41,43:211,214:541)
S: + VXNlciBOYW1lAA==
C: dGVzdDg=
S: + UGFzc3dvcmQA
C: dGVzdDg=
S: * FOLDER INBOX
S: * 464 EXISTS
S: * 3 RECENT
S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY
S: * OK [UIDNEXT 550] Predicted next UID
S: * OK [HIGHESTMODSEQ 20010715194045007]
S: * 1 FETCH (UID 1 FLAGS (\Seen))
S: * EXPUNGED 5,7,9,15:21
S: 2 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN
SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User
test8 authenticated
Melnikov & Wilson Expires September 2, 2005 [Page 8]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
C: 3 IDLE
S: + Waiting for DONE
That's it! And since no new messages arrived, no headers were
downloaded. The total byte count is about 500 bytes, significantly
less than the amount of data transferred during a normal connect
request.
Melnikov & Wilson Expires September 2, 2005 [Page 9]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
3. LOGIN and AUTHENTICATE commands
3.1 Extended LOGIN command
Arguments: user name
password
optional SID or NEWSID parameter
Data: OPTIONAL untagged responses: FOLDER (required if either
SID or NEWSID parameter was specified, unless the server
returns NOSID)
OPTIONAL untagged responses: NEWSID or NOSID (required if
NEWSID parameter was specified; also required if SID
parameter was specified but the given session ID is
invalid)
OPTIONAL - also untagged responses associated with SELECT
Result: OK - login completed, now in authenticated state (or
selected) state; see section 3.3
NO - login failure: user name or password rejected
BAD - arguments invalid
This section extends the definition of the LOGIN command as defined
in [RFC3501]. The LOGIN command identifies the client to the server
and carries the plaintext password authenticating this user. In
addition, the client can do one of two things: create a new session
by specifying the NEWSID parameter or pass a session identifier
("SID") in the SID parameter in order to attempt to resume a
previously created session. Either parameter is only used if login
is successful.
If no SID or NEWSID is specified, the LOGIN command behaves as
described in [RFC3501].
If either SID or NEWSID is specified, the server first performs all
actions associated with a regular LOGIN command. Should
authentication succeed, the server must try to resume the specified
session as described in section 3.3 if the SID parameter was
specified. If the client has specified NEWSID, the server is
required to create a new session as described in Section 3.4.
The NEWSID parameter is mutually exclusive with the SID parameter.
If the client has specified both the server MUST return BAD tagged
response.
Melnikov & Wilson Expires September 2, 2005 [Page 10]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
Example: First login, the client needs to perform a state-comparison-
sync to get in sync.
C: A01 LOGIN joe password (NEWSID)
S: * NEWSID ABC412423rs
S: A01 OK LOGIN completed
Example: A successful Lemonade login resuming an old session.
C: A02 LOGIN joe password (SID ABC412423rs)
S: * FOLDER ()
S: ...
S: A02 OK LOGIN completed
Example: A successful Lemonade login resuming an old session in
SELECTED state with the INBOX selected.
C: A02 LOGIN joe password (SID ABC412423rs 67890007
20010715194045000 41,43:211,214:541)
S: * FOLDER INBOX
S: * 14 EXISTS
S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered))
S: ...
S: A02 OK LOGIN completed
Example: A successful Lemonade login resuming an old session in
SELECTED state with the INBOX selected, but where the server could
not cache all the events since the last disconnect. The server
sends the NEWSID response, which means that the client should
perform full resynchronization.
C: A02 LOGIN joe password (SID ABC412423rs 67890007
20010715194045000 41,43:211,214:541)
S: * NEWSID jwejei9qe3r
Melnikov & Wilson Expires September 2, 2005 [Page 11]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
S: * FOLDER INBOX
S: A02 OK LOGIN completed
Example: A successful Lemonade login resuming an old session in
SELECTED state with the mailbox Drafts selected, but the mailbox
was deleted and another one was renamed to become Drafts, while
the client was offline. The server chooses to keep the Drafts
mailbox open, however it sends the NEWSID response, which means
that the client should perform full resynchronization.
C: A02 LOGIN joe password (SID Frt-egf-779 6896834 11 20:35)
S: * NEWSID Frt-egf-779
S: * FOLDER Drafts
S: * OK [UIDVALIDITY 1098183472] Current UIDValidity
S: * OK [UIDNEXT 12] Next available UID
S: * 7 EXISTS
S: * 0 RECENT
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen
\*)] Permanent flags
S: A02 OK [READ-WRITE] LOGIN completed
[[anchor8: READ-WRITE response code conflicts with CAPABILITY
response code]]
3.2 Extended AUTHENTICATE command
Arguments: authentication mechanism name
optional initial SASL response, as per [IMAP-SASL-IR]
optional SID or NEWSID parameter
Responses: continuation data can be requested
Melnikov & Wilson Expires September 2, 2005 [Page 12]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
Data: OPTIONAL untagged responses: FOLDER (required if either
SID or NEWSID parameter was specified, unless NOSID
response is returned)
OPTIONAL untagged responses: NEWSID or NOSID (required if
NEWSID parameter was specified; also required if SID
parameter was specified but the given session ID is
invalid)
OPTIONAL - also untagged responses associated with SELECT
Result: OK - authenticate completed, now in authenticated (or
selected) state; see section 3.3
NO - authenticate failure: unsupported authentication
BAD - arguments invalid, also authentication exchange
cancelled
This section extends the definition of the AUTHENTICATE command as
defined in [RFC3501]. The AUTHENTICATE command indicates a [SASL]
authentication mechanism to the server. If the server supports the
requested authentication mechanism, it performs an authentication
protocol exchange to authenticate and identify the client. It MAY
also negotiate an OPTIONAL security layer for subsequent protocol
interactions. If the requested authentication mechanism is not
supported, the server SHOULD reject the AUTHENTICATE command by
sending a tagged NO response. See [RFC3501] for more details.
The client can also pass a session identifier ("SID") in order to
attempt to resume a previously created session. This is only used if
authentication exchange is successful. If it is, then the presence
of a SID tells the server to try to resume the specified session as
described in section 3.3.
Alternatively, the client can pass a NEWSID parameter that requests
that the server creates a new session. This is only used if
authentication exchange is successful. See section 3.4 for detailed
description of server's behavior in this case.
The NEWSID parameter is mutually exclusive with the SID parameter.
If the client has specified both the server MUST return the BAD
tagged response.
[[anchor10: Check how this will work together with SASL-INITIAL.]]
Example: A successful Lemonade authentication exchange resuming an
old session in SELECTED state with the INBOX selected, but where
the server could not cache all the events since the last
disconnect. The server returns a new SID.
Melnikov & Wilson Expires September 2, 2005 [Page 13]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
C: A02 AUTHENTICATE DIGEST-MD5 (SID BORkjr5745745i)
S: + ABCDEFG==
C: 1234567==
S: + HIJKLMNO==
C:
S: A02 OK User authenticated successfully
S: * NEWSID jwejei9qe3r
S: * FOLDER INBOX
[[anchor11: Can we send untagged responses before the final OK? If
we can't, can we do this as shown?]]
3.3 Resuming existing session
This section describes server behaviour if the client has specified
the SID parameter to a LOGIN/AUTHENTICATE command.
SID parameter is followed by four arguments: session identifier
followed by three optional arguments: the mailbox UIDVALIDITY, the
last known modification sequence and the list of known UIDs.
[[anchor13: Do we still need the list of known UIDs, now that the
EXPUNGED extension can use modification sequence? This seems very
much like filtering and probably should be removed for simplicity]]
[[anchor14: What the server should do if a mailbox is selected, but
there are no optional parameters? Are they required if a mailbox is
selected?]]
The server checks the session identifier (SID) first. If the session
identified by the SID is not recognized (for example, this is the
first time the client tries to connect, or the the SID is invalid
because it is either not recognized, or recognized but the session
has expired on the server), the server creates a new session as
described in Section 3.4.
Otherwise the server resumes a previously created session for the
client.
If a session is resumed, the server MUST inform the client of the
state of the server by sending an untagged FOLDER response. The
FOLDER response contains the name of the currently selected mailbox
name or "()" if there is no mailbox selected. If, before the
disconnect, the session had a mailbox selected and the mailbox has
been deleted since than (or the user has no longer permissions to
Melnikov & Wilson Expires September 2, 2005 [Page 14]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
access it), the server MUST return a special FOLDER untagged response
that \contains "()" as the mailbox name. This tells the client that
the session has returned to the unauthenticated state.
If at this point there is no mailbox selected, the remaining
arguments MUST be ignored by the server (however it MAY check them
for syntactic validity).
Once the session has successfully resumed and there is a mailbox
selected, the server checks the UIDVALIDITY value provided by the
client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY
for the currently selected mailbox, the server MUST send the NEWSID
response (that MAY contain the SID of the resumed session) in order
to force the client to perform full resynchronization. The remaining
arguments are ignored in this case.
If the provided UIDVALIDITY matches the actual, the server then
checks the last known modification sequence [[anchor15: if one was
provided]].
The server sends the client any pending flag changes (using FETCH
responses that MUST contain UIDs) and expunges that have occurred in
this folder since the provided modification sequence.
If the list of known UIDs was also provided, the server should only
report flag changes and expunges for the provided messages. If the
client haven't provided the list of UIDs, the server acts as if the
client has specified "1:*". Thus, the client can just service these
pending events and need not perform a full resynchronization. The
result of this step is semantically equivalent to the client issuing:
tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE "mod-sequence-
value" REPORTEXPUNGES)
If these events could not be cached for some reason, the server MUST
return the NEWSID response to signal that the client should perform a
state-comparison based synchronization. Note, that the NEWSID
response MAY contain the same SID as specified in the SID parameter.
Section 3.4 describes server behaviour in this case.
[[anchor16: There seems to be additional failure case: the server has
sent the client a new EXISTS value, but the client has lost
connection before receiving it]]
Example: A successful Lemonade login resuming an old session in
SELECTED state with the INBOX selected.
C: A02 LOGIN joe password (SID ABC412423rs 67890007
20010715194045000 41,43:211,214:541)
Melnikov & Wilson Expires September 2, 2005 [Page 15]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
S: * FOLDER INBOX
S: * 314 EXISTS
S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered))
S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent))
S: ...
S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded))
S: * EXPUNGED 41,43:116,118,120:211,214:540
S: A02 OK LOGIN completed
Note, that if, while the client was offline, the mailbox was deleted
and another mailbox was renamed on top of the selected, the server
may do one of the two things:
1. return the NEWSID response, as well as new UIDVALIDITY and all
other responses required on select.
2. return "FOLDER ()" response to return the client to authenticated
state.
[[anchor17: Ideally, this should be a separate section, as it applies
to both 3.3 and 3.4]] Whether a session was successfully resumed or a
new one was created, the server is now required to remember the
session state associated with the (username, SID) pair. This state
includes the currently selected mailbox and any associated state,
which MUST include the mailbox UIDVALIDITY value, the number of
messages (EXISTS), the number of recent messages (RECENT), and the
UID of the last message in the mailbox.
[[anchor18: Read-only state? PERMANENTFLAGS/FLAGS? Other?]] If the
server supports CONDSTORE extension [CONDSTORE], it MUST also
remember the HIGHESTMODSEQ value. Other IMAP extensions can define
additional state that has to be tracked. [[anchor19: e.g. ACL
MYRIGHTS?]]
Note, that TLS and/or SASL security layer state [SASL] created with
STARTTLS/AUTHENTICATE command on a previous connection can't be
resumed using this mechanism. A client wishing to resume a TLS layer
or a SASL security layer should use TLS session resumption or SASL
fast reauthentication (if it is supported by the selected SASL
mechanism).
[[anchor20: Define how resuming a session interacts with ANNOTATE and
other IMAP extensions]]
Melnikov & Wilson Expires September 2, 2005 [Page 16]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
An implementation may choose to keep all session state in memory and
expire sessions some time after client disconnects due to dropped TCP
connection or explicit execution of LOGOUT (PRESERVE) command. Upon
session expiration the session ID becomes invalid and its associated
state is deleted. Note, that this document doesn't define a minimal
required expiration timeout, as members of the Lemonade WG have
decided that any such limit would not be adequate for all
deployments.
Note that SIDs are chosen by the server and are opaque to the client.
The same SID used with two different usernames refers to two
different sessions, unless the two usernames refer to the same user
account, e.g. one username is an alias for another.
3.4 Creating a new session
This section describes server behaviour if the client has specified
the NEWSID parameter to a LOGIN/AUTHENTICATE command. The NEWSID
parameter tells the server to create a new resumable session and
return a unique SID in the NEWSID response. This section also
applies if the client has specified the SID parameter to a LOGIN/
AUTHENTICATE command and the specified session can't be resumed (see
Section 3.3).
Each server MUST be able to keep track of at least 5 [[anchor22: this
is a random number at this point]] sessions for the same user. A
server implementation might also have a per-server or per-username
limit on maximum number of resumable sessions. This document doesn't
define this limit. If the server has reached the limit, it MUST
return the NOSID response and proceed as if no NEWSID parameter was
specified by the client.
Melnikov & Wilson Expires September 2, 2005 [Page 17]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
4. PRESERVE parameter to LOGOUT command
[[anchor24: This section clearly assumes voluntarily disconnect]]
This section updates the description of the LOGOUT command found in
Section 6.1.3 of [RFC3501]. A LOGOUT command with no parameters tell
the server to terminate a resumable session.
This document also adds a new parameter "PRESERVE" to the LOGOUT
command. This tells the server that it should not terminate the
current resumable session. If the client doesn't want to terminate
the current session on logout it SHOULD use "LOGOUT (PRESERVE)"
instead of just dropping TCP connection. The former helps to avoid
unnecessary resource consumption on the server caused by a TCP
disconnect.
Example: C: A023 LOGOUT (PRESERVE)
S: * BYE IMAP4rev1 Server logging out, state preserved
S: A023 OK LOGOUT completed
(Server and client then close the connection)
Melnikov & Wilson Expires September 2, 2005 [Page 18]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
5. New responses
5.1 FOLDER Response
Contents: name of the selected mailbox or "()" if there is no
selected mailbox
The FOLDER response tells the client that a session was successfully
resumed and returns the name of the selected mailbox. The "()"
sequence is used to signal that there is no mailbox selected.
5.2 NEWSID Response
Contents: generated session ID
The NEWSID response tells the client the unique identifier that can
be used to resume the created session. It also tells the client to
perform a full state resynchronization.
5.3 NOSID Response
Contents: none
The NOSID response tells the client that the server was unable to
create a new session, probably because it has reached some
implementation specific limit.
Melnikov & Wilson Expires September 2, 2005 [Page 19]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
6. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF].
Non-terminals referenced but not defined below are as defined by
[RFC3501], [CONDSTORE] or [EXPUNGED].
Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
login = "LOGIN" SP userid SP password [login-params]
authenticate = "AUTHENTICATE" SP auth-type
[SP (base64 / "=")] [login-params]
*(CRLF base64)
login-params =/ *(SP "(" login-param-data ")"
;; modifies the original IMAP4 LOGIN
;; command to accept optional parameters
login-param-data = login-param *(SP login-param)
login-param = astring /
"(" astring SP astring *(SP astring) ")"
;; parameters to LOGIN may contain one or
;; more atoms or strings - multiple items
;; are always parenthesized
login-sid = "SID" SP session-id [SP uidvalidity SP mod-
sequence-value [SP known-uids]]
;; conforms to login-param-data syntax
uidvalidity = nz-number
known-uids = sequence-set
;; sequence of UIDs, "*" is not allowed
command-any =/ logout
logout = "LOGOUT" [logout-params]
logout-params =/ *(SP "(" logout-param-data ")"
;; modifies the original IMAP4 LOGOUT
;; command to accept optional parameters
Melnikov & Wilson Expires September 2, 2005 [Page 20]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
logout-param-data= logout-param *(SP logout-param)
logout-param = astring /
"(" astring SP astring *(SP astring) ")"
;; parameters to LOGOUT may contain one or
;; more atoms or strings - multiple items
;; are always parenthesized
logout-preserve = "PRESERVE"
;; conforms to logout-param-data syntax
login-newsid = "NEWSID"
;; conforms to login-param-data syntax
mailbox-data =/ folder-resp / newsid-resp / nosid-resp
;; [[Is it Ok to use mailbox-data?]]
folder-resp = "FOLDER" SP (folder | no_folder)
no_folder = "()"
newsid-resp = "NEWSID" SP session-id
session-id = string ;; a unique session identifier,
;; implementation specific. If starts from "P"
;; it must be followed by an international
;; phone number.
nosid-resp = "NOSID"
Melnikov & Wilson Expires September 2, 2005 [Page 21]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
7. Security Considerations
In order to mitigate DoS attacks caused by a client that tries to
generate numerous resumable sessions, a server implementation should
consider imposing a limit on the maximum number of resumable sessions
associated with a particular user and/or coming from a particular IP
address/network.
[[anchor31: Add a warning about not being able to resume STARTTLS/
AUTHENTICATE state]]
The Quick Reconnect extension does not make any modifications to the
authentication sequence of the current IMAP4 protocol [RFC3501].
Melnikov & Wilson Expires September 2, 2005 [Page 22]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
8. IANA Considerations
Melnikov & Wilson Expires September 2, 2005 [Page 23]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
9. References
9.1 Normative References
[ABNF] Crocker, D., Ed., "Augmented BNF for Syntax
Specifications: ABNF".
[CONDSTORE]
Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE", November 2003.
[EXPUNGED]
Melnikov, A., "IMAP4 extension to CONDSTORE for reporting
messages expunged since last synchronization",
January 2005.
[IMAP-SASL-IR]
Siemborski, R., "IMAP Extension for SASL Initial Client
Response".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[SASL] Melnikov, A., "Simple Authentication and Security Layer
(SASL)".
9.2 Informative References
[C2S] Maes, S. and C. Wilson, "Lemonade Requirements for Server
to Client Notifications", February 2005.
[IMAP-DISC]
Melnikov, A., "Synchronization Operations For Disconnected
Imap4 Clients".
[TRANS-CAPA]
Melnikov, A., "Transitional IMAP capabilities".
Melnikov & Wilson Expires September 2, 2005 [Page 24]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
Authors' Addresses
Alexey Melnikov
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
Email: Alexey.Melnikov@isode.com
Corby Wilson
Nokia
503 Martindale St.
Suite 610
Pittsburgh, PA 15212
USA
Email: corby@computer.org
Melnikov & Wilson Expires September 2, 2005 [Page 25]
Internet-Draft IMAP4 Extensions for Quick Reconnect March 2005
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Melnikov & Wilson Expires September 2, 2005 [Page 26]
