< draft-ietf-lemonade-reconnect-client-05.txt   draft-ietf-lemonade-reconnect-client-06.txt >
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft D. Cridland Internet-Draft D. Cridland
Intended status: Standards Track Isode Ltd Intended status: Standards Track Isode Ltd
Expires: December 13, 2007 C. Wilson Expires: March 31, 2008 C. Wilson
Nokia Nokia
June 11, 2007 September 28, 2007
IMAP4 Extensions for Quick Mailbox Resynchronization IMAP4 Extensions for Quick Mailbox Resynchronization
draft-ietf-lemonade-reconnect-client-05.txt draft-ietf-lemonade-reconnect-client-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 13, 2007. This Internet-Draft will expire on March 31, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines an IMAP4 extension, which gives an IMAP client This document defines an IMAP4 extension, which gives an IMAP client
the ability to quickly resynchronize any previously opened mailbox as the ability to quickly resynchronize any previously opened mailbox as
part of the SELECT command, without the need for server-side state or part of the SELECT command, without the need for server-side state or
additional client round-trips. This extension also introduces a new additional client round-trips. This extension also introduces a new
response that allows for a more compact representation for a list of response that allows for a more compact representation for a list of
expunged messages. expunged messages (and always includes the UIDs expunged).
Changes since draft-ietf-lemonade-reconnect-client-05.txt
o Many editorial improvements from Randy Gellens.
o Remove RECENT response from the list of responses that doesn't
need to be returned when VANISHED is also returned.
o Clarified that VANISHED (EARLIER) must be returned before any
FETCH.
o Fixed some typos in examples.
o Require that any client issues ENABLE QRESYNC first. Servers now
reject SELECT QRESYNC/FETCH VANISHED not preceeded by ENABLE
QRESYNC with BAD.
Changes since draft-ietf-lemonade-reconnect-client-04.txt Changes since draft-ietf-lemonade-reconnect-client-04.txt
o Clarified handling of omitted list of known UIDs. o Clarified handling of omitted list of known UIDs.
o Clarified interaction with the CONDSTORE extension. o Clarified interaction with the CONDSTORE extension.
o Renamed TAG to EARLIER and removed the associated tag parameter. o Renamed TAG to EARLIER and removed the associated tag parameter.
o Made QRESYNC extension depend on ENABLE. o Made QRESYNC extension depend on ENABLE.
skipping to change at page 3, line 14 skipping to change at page 4, line 7
o If client's UIDVALIDITY doesn't match server's, the server will o If client's UIDVALIDITY doesn't match server's, the server will
not return any flags anymore. not return any flags anymore.
o Clarified that SELECT (QRESYNC) is a CONDSTORE-enabling command. o Clarified that SELECT (QRESYNC) is a CONDSTORE-enabling command.
o Other minor editorial changes and fixes. o Other minor editorial changes and fixes.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 5
2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 5
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 6 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 7
3.1. QRESYNC parameter to SELECT/EXAMINE . . . . . . . . . . . 6 3.1. QRESYNC parameter to SELECT/EXAMINE . . . . . . . . . . . 7
3.2. VANISHED UID FETCH modifier . . . . . . . . . . . . . . . 11 3.2. VANISHED UID FETCH modifier . . . . . . . . . . . . . . . 12
3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 12 3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 13
3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 13 3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 14
3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 14 3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 15
3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 15 3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 16
3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 17 3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 18
4. Server implementation considerations . . . . . . . . . . . . . 18 4. Server implementation considerations . . . . . . . . . . . . . 19
4.1. Server implementations that don't store extra state . . . 18 4.1. Server implementations that don't store extra state . . . 19
4.2. Server implementations storing minimal state . . . . . . . 18 4.2. Server implementations storing minimal state . . . . . . . 19
4.3. Additional state required on the server . . . . . . . . . 18 4.3. Additional state required on the server . . . . . . . . . 19
5. Updated synchronization sequence . . . . . . . . . . . . . . . 19 5. Updated synchronization sequence . . . . . . . . . . . . . . . 21
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. If a single "C:" or "S:" label applies to server respectively. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol editorial clarity only and are not part of the actual protocol
exchange. exchange.
Understanding of the IMAP message sequence numbers and UIDs and the Understanding of the IMAP message sequence numbers and UIDs and the
EXPUNGE response [RFC3501] is essential when reading this document. EXPUNGE response [RFC3501] is essential when reading this document.
[[anchor2: Editorial comments and questions are marked like this.]] [[anchor2: Editorial comments and questions are marked like this.]]
2. Introduction and Overview 2. Introduction and Overview
The [CONDSTORE] extension gives a disconnected client ability to The [CONDSTORE] extension gives a disconnected client the ability to
quickly resynchronize IMAP flag changes for previously seen messages. quickly resynchronize IMAP flag changes for previously seen messages.
This can be done using the CHANGEDSINCE FETCH modifier once a mailbox This can be done using the CHANGEDSINCE FETCH modifier once a mailbox
is opened. In order for the client to discover which messages have is opened. In order for the client to discover which messages have
been expunged, the client still has to issue a UID FETCH or a UID been expunged, the client still has to issue a UID FETCH or a UID
SEARCH command. This document defines an extension to [CONDSTORE] SEARCH command. This document defines an extension to [CONDSTORE]
that allows a reconnecting client to perform full resynchronization, that allows a reconnecting client to perform full resynchronization,
including discovery of expunged messages, in a single round-trip. including discovery of expunged messages, in a single round-trip.
This extension also introduces a new response VANISHED that allows This extension also introduces a new response VANISHED that allows
for a more compact representation for a list of expunged messages. for a more compact representation for a list of expunged messages.
This extension can be useful for mobile clients that can experience This extension can be useful for mobile clients that can experience
frequent disconnects caused by environmental factors (battery life, frequent disconnects caused by environmental factors (battery life,
signal strength, etc.). Such clients need a way to quickly reconnect signal strength, etc.). Such clients need a way to quickly reconnect
to the IMAP server, without forcing the user to experience long delay to the IMAP server, while minimizing delay experienced by the user as
and pay big bills for the amount of traffic generated by well as the amount of traffic (and hence the expense) generated by
resynchronization. resynchronization.
By extending the SELECT command to perform the additional By extending the SELECT command to perform the additional
resynchronization, this also allows clients to reduce concurrent resynchronization, this also allows clients to reduce concurrent
connections to the IMAP server held purely for the sake of avoiding connections to the IMAP server held purely for the sake of avoiding
the resynchronization. the resynchronization.
[[anchor4: Note to RFC editor: Please change the capability name [[anchor4: Note to RFC editor: Please change the capability name
everywhere in the document from "X-DRAFT-W05-QRESYNC" to "QRESYNC".]] everywhere in the document from "X-DRAFT-W05-QRESYNC" to "QRESYNC".]]
skipping to change at page 5, line 24 skipping to change at page 6, line 24
for a compliant server to support "ENABLE CONDSTORE" by itself. The for a compliant server to support "ENABLE CONDSTORE" by itself. The
"ENABLE X-DRAFT-W05-QRESYNC"/"ENABLE X-DRAFT-W05-QRESYNC CONDSTORE" "ENABLE X-DRAFT-W05-QRESYNC"/"ENABLE X-DRAFT-W05-QRESYNC CONDSTORE"
command also tells the server that it SHOULD start sending VANISHED command also tells the server that it SHOULD start sending VANISHED
responses (see Section 3.6) instead of EXPUNGE responses. This responses (see Section 3.6) instead of EXPUNGE responses. This
change remains in effect until the connection is closed. change remains in effect until the connection is closed.
For compatibility with clients that only support the [CONDSTORE] IMAP For compatibility with clients that only support the [CONDSTORE] IMAP
extension, servers SHOULD advertise "CONDSTORE" in the CAPABILITY extension, servers SHOULD advertise "CONDSTORE" in the CAPABILITY
response as well. response as well.
A client making use of this extension MUST issue "ENABLE QRESYNC"
once it is authenticated. A server MUST respond with a tagged BAD
response if the QRESYNC parameter to the SELECT/EXAMINE command or
the VANISHED UID FETCH modifier is specified and the client hasn't
issued "ENABLE QRESYNC" in the current connection.
This document puts additional requirements on a server implementing This document puts additional requirements on a server implementing
the [CONDSTORE] extension. Each mailbox that supports persistent the [CONDSTORE] extension. Each mailbox that supports persistent
storage of mod-sequences, i.e., for which the server has sent a storage of mod-sequences, i.e., for which the server has sent a
HIGHESTMODSEQ untagged OK response code on a successful SELECT/ HIGHESTMODSEQ untagged OK response code on a successful SELECT/
EXAMINE, MUST increment the per-mailbox mod-sequence when one or more EXAMINE, MUST increment the per-mailbox mod-sequence when one or more
messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the
server MUST associate the incremented mod-sequence with the UIDs of server MUST associate the incremented mod-sequence with the UIDs of
the expunged messages. the expunged messages.
A client which supports CONDSTORE but not this extension might A client which supports CONDSTORE but not this extension might
skipping to change at page 6, line 21 skipping to change at page 7, line 24
o the last known UIDVALIDITY, o the last known UIDVALIDITY,
o the last known modification sequence o the last known modification sequence
o the optional set of known UIDs o the optional set of known UIDs
o an optional parenthesized list of known sequence ranges and their o an optional parenthesized list of known sequence ranges and their
corresponding UIDs. corresponding UIDs.
The parameter acts as a CONDSTORE enabling command, as defined in A server MUST respond with a tagged BAD response if the Quick
[CONDSTORE]. In other words, the use of the QRESYNC parameter Resynchronization parameter to SELECT/EXAMINE command is specified
implies the CONDSTORE parameter. The QRESYNC parameter also tells and the client hasn't issued "ENABLE QRESYNC" in the current
the server that it SHOULD start sending VANISHED responses (see connection.
Section 3.6) instead of EXPUNGE responses. This change remains in
effect until the connection is closed. The QRESYNC parameter also tells the server that it SHOULD start
sending VANISHED responses (see Section 3.6) instead of EXPUNGE
responses. This change remains in effect until the connection is
closed.
Before opening the specified mailbox the server verifies all Before opening the specified mailbox the server verifies all
arguments for syntactic validity. If any parameter is not arguments for syntactic validity. If any parameter is not
syntactically valid, the server returns the tagged BAD response, and syntactically valid, the server returns the tagged BAD response, and
the mailbox remains unselected. Once the check is done the server the mailbox remains unselected. Once the check is done the server
opens the mailbox as if no SELECT/EXAMINE parameters are specified opens the mailbox as if no SELECT/EXAMINE parameters are specified
(this is subject to processing of other parameters as defined in (this is subject to processing of other parameters as defined in
other extensions). In particular this means that server MUST send other extensions). In particular this means that the server MUST
all untagged responses as specified in Section 6.3.1/6.3.2 of send all untagged responses as specified in Section 6.3.1/6.3.2 of
[RFC3501]. [RFC3501].
After that the server checks the UIDVALIDITY value provided by the After that the server checks the UIDVALIDITY value provided by the
client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY
for the mailbox being opened, then the server MUST ignore the for the mailbox being opened, then the server MUST ignore the
remaining parameters and behave as if no dynamic message data remaining parameters and behave as if no dynamic message data
changed. The client can discover this situation by comparing the changed. The client can discover this situation by comparing the
UIDVALIDITY value returned by the server. This behaviour allows the UIDVALIDITY value returned by the server. This behaviour allows the
client not to synchronize the mailbox or decide on the best client not to synchronize the mailbox or decide on the best
synchronization strategy. synchronization strategy.
skipping to change at page 7, line 23 skipping to change at page 8, line 28
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags \Deleted \Seen \*)] Permanent flags
S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch
Modification Sequence and UID Parameters: Modification Sequence and UID Parameters:
A server that doesn't support the persistent storage of mod-sequences A server that doesn't support the persistent storage of mod-sequences
for the mailbox MUST send the OK untagged response including the for the mailbox MUST send the OK untagged response including the
NOMODSEQ response code with every successful SELECT or EXAMINE NOMODSEQ response code with every successful SELECT or EXAMINE
command, as described in [CONDSTORE]. Such server doesn't need to command, as described in [CONDSTORE]. Such a server doesn't need to
remember mod-sequences for expunged messages in the mailbox. It MUST remember mod-sequences for expunged messages in the mailbox. It MUST
ignore the remaining parameters and behave as if no dynamic message ignore the remaining parameters and behave as if no dynamic message
data changed. data changed.
However, whether the server returns the HIGHESTMODSEQ or the NOMODSEQ However, whether the server returns the HIGHESTMODSEQ or the NOMODSEQ
response code, the QRESYNC parameter still enables the use of the response code, the QRESYNC parameter still enables the use of the
VANISHED response in lieu of the EXPUNGE response Section 3.6. VANISHED response in lieu of the EXPUNGE response (as described in
Section 3.6).
If the provided UIDVALIDITY matches that of the selected mailbox, the If the provided UIDVALIDITY matches that of the selected mailbox, the
server then checks the last known modification sequence. server then checks the last known modification sequence.
The server sends the client any pending flag changes (using FETCH The server sends the client any pending flag changes (using FETCH
responses that MUST contain UIDs) and expunges that have occurred in responses that MUST contain UIDs) and expunges that have occurred in
this mailbox since the provided modification sequence. this mailbox since the provided modification sequence.
If the list of known UIDs was also provided, the server should only If the list of known UIDs was also provided, the server should only
report flag changes and expunges for the provided messages. If the report flag changes and expunges for the specified messages. If the
client did not provide the list of UIDs, the server acts as if the client did not provide the list of UIDs, the server acts as if the
client has specified "1:<maxuid>", where <maxuid> is the mailbox's client has specified "1:<maxuid>", where <maxuid> is the mailbox's
UIDNEXT value minus 1. If the mailbox is empty and never had any UIDNEXT value minus 1. If the mailbox is empty and never had any
messages in it, then lack of the list of UIDs is interpreted as an messages in it, then lack of the list of UIDs is interpreted as an
empty set of UIDs. empty set of UIDs.
Thus, the client can process just these pending events and need not Thus, the client can process just these pending events and need not
perform a full resynchronization. Without the message sequence perform a full resynchronization. Without the message sequence
number matching information, the result of this step is semantically number matching information, the result of this step is semantically
equivalent to the client issuing: equivalent to the client issuing:
skipping to change at page 8, line 28 skipping to change at page 9, line 36
S: * OK [HIGHESTMODSEQ 90060115205545359] S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags \Deleted \Seen \*)] Permanent flags
S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540
S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered)) S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered))
S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent)) S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent))
S: ... S: ...
S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded)) S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded))
S: * VANISHED 41,43:116,118,120:211,214:540
S: A03 OK [READ-WRITE] mailbox selected S: A03 OK [READ-WRITE] mailbox selected
Message sequence match data: Message sequence match data:
A client MAY provide a parenthesized list of a message sequence set A client MAY provide a parenthesized list of a message sequence set
and the corresponding UID sets. Both MUST be provided in ascending and the corresponding UID sets. Both MUST be provided in ascending
order. The server uses this data to restrict the range for which it order. The server uses this data to restrict the range for which it
provides expunged message information. provides expunged message information.
Conceptually, the client provides a small sample of sequence numbers Conceptually, the client provides a small sample of sequence numbers
skipping to change at page 9, line 41 skipping to change at page 11, line 4
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 30013] Predicted next UID S: * OK [UIDNEXT 30013] Predicted next UID
S: * OK [HIGHESTMODSEQ 90060115205545359] S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags \Deleted \Seen \*)] Permanent flags
S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...]
29998:29999,30001:30002,30004:30005,30007:30008
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered)) S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered))
S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent)) S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent))
S: ... S: ...
S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded)) S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded))
S: * VANISHED 1:2,4:5,7:8,10:11,13:14 [...]
29998:29999,30001:30002,30004:30005,30007:30008
S: A04 OK [READ-WRITE] mailbox selected S: A04 OK [READ-WRITE] mailbox selected
Example: Example:
C: B04 SELECT INBOX (QRESYNC (67890007 C: B04 SELECT INBOX (QRESYNC (67890007
90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000, 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000,
22500,27000,29970,29973,29976,29979,29982,29985,29988,29991, 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991,
29994,29997))) 29994,29997)))
S: * 10003 EXISTS S: * 10003 EXISTS
skipping to change at page 10, line 37 skipping to change at page 11, line 44
S: * OK [HIGHESTMODSEQ 90060115205545359] S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags \Deleted \Seen \*)] Permanent flags
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered)) S: * VANISHED (EARLIER) 29998:29999,30001:30002,30004:30005,30007:
30008
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered))
S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent)) S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent))
S: ... S: ...
S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded)) S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded))
S: * VANISHED 29998:29999,30001:30002,30004:30005,30007:30008
S: B04 OK [READ-WRITE] mailbox selected S: B04 OK [READ-WRITE] mailbox selected
3.2. VANISHED UID FETCH modifier 3.2. VANISHED UID FETCH modifier
[IMAPABNF] has extended the syntax of the FETCH and UID FETCH [IMAPABNF] has extended the syntax of the FETCH and UID FETCH
commands to include an optional FETCH modifier. This document commands to include an optional FETCH modifier. This document
defines a new UID FETCH modifier: VANISHED. defines a new UID FETCH modifier: VANISHED.
Note, that the VANISHED UID FETCH modifier is NOT allowed with a Note, that the VANISHED UID FETCH modifier is NOT allowed with a
FETCH command. The server MUST return a tagged BAD response if this FETCH command. The server MUST return a tagged BAD response if this
response is specified as a modifier to the FETCH command. response is specified as a modifier to the FETCH command.
A server MUST respond with a tagged BAD response if the VANISHED UID
FETCH modifier is specified and the client hasn't issued "ENABLE
QRESYNC" in the current connection.
The VANISHED UID FETCH modifier MUST only be specified together with The VANISHED UID FETCH modifier MUST only be specified together with
the CHANGEDSINCE UID FETCH modifier. the CHANGEDSINCE UID FETCH modifier.
The VANISHED UID FETCH modifier instructs the server to report those The VANISHED UID FETCH modifier instructs the server to report those
messages from the UID set parameter that have been expunged and whose messages from the UID set parameter that have been expunged and whose
associated modsequence is larger than the specified modsequence. associated modsequence is larger than the specified modsequence.
That is, the client requests to be informed of messages from the That is, the client requests to be informed of messages from the
specified set that were expunged since the specified modsequence. specified set that were expunged since the specified modsequence.
Note that the modsequence(s) associated with these messages were Note that the modsequence(s) associated with these messages were
updated when the messages were expunged (as described above). The updated when the messages were expunged (as described above). The
expunged messages are reported using the VANISHED response as expunged messages are reported using the VANISHED response as
described in Section 3.6, which MUST contain the EARLIER tag. described in Section 3.6, which MUST contain the EARLIER tag. Any
VANISHED (EARLIER) responses MUST be returned before any FETCH
responses, as otherwise the client might get confused about how
message numbers map to UIDs.
Note: a server that receives a modsequence smaller than any of the Note: a server that receives a modsequence smaller than any of the
expunged modsequence it remembers about MUST behave as if it was expunged modsequence it remembers about MUST behave as if it was
requested to report all expunged messages from the provided UID set requested to report all expunged messages from the provided UID set
parameter. parameter.
The VANISHED UID FETCH modifier also instructs the server to replace The VANISHED UID FETCH modifier also instructs the server to replace
all further EXPUNGE responses with VANISHED responses. The server all further EXPUNGE responses with VANISHED responses. The server
MUST do this until the connection is closed. MUST do this until the connection is closed.
skipping to change at page 12, line 12 skipping to change at page 13, line 29
Where 300 and 500 are the lowest and highest UIDs from client's Where 300 and 500 are the lowest and highest UIDs from client's
cache. The second SEARCH response tells the client that the messages cache. The second SEARCH response tells the client that the messages
with UIDs 407, 410 and 412 are still present, but their flags haven't with UIDs 407, 410 and 412 are still present, but their flags haven't
changed since the specified modification sequence. changed since the specified modification sequence.
Using the VANISHED UID FETCH modifier it is sufficient to issue only Using the VANISHED UID FETCH modifier it is sufficient to issue only
a single command: a single command:
C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345
VANISHED) VANISHED)
S: * VANISHED (EARLIER) 300:310,405,411
S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
$AutoJunk $MDNSent)) $AutoJunk $MDNSent))
S: * VANISHED (EARLIER) 300:310,405,411
S: s100 OK FETCH completed S: s100 OK FETCH completed
3.3. EXPUNGE Command 3.3. EXPUNGE Command
Arguments: none Arguments: none
Responses: untagged responses: EXPUNGE or VANISHED Responses: untagged responses: EXPUNGE or VANISHED
Result: OK - expunge completed Result: OK - expunge completed
NO - expunge failure: can't expunge (e.g., permission NO - expunge failure: can't expunge (e.g., permission
skipping to change at page 15, line 34 skipping to change at page 16, line 41
the EXPUNGE response [RFC3501], however it can return information the EXPUNGE response [RFC3501], however it can return information
about multiple messages and it returns UIDs instead of message about multiple messages and it returns UIDs instead of message
numbers. The first benefit saves bandwidth, while the second is more numbers. The first benefit saves bandwidth, while the second is more
convenient for clients which only use UIDs to access the IMAP server. convenient for clients which only use UIDs to access the IMAP server.
The VANISHED response has the same restrictions on when it can be The VANISHED response has the same restrictions on when it can be
sent as does the EXPUNGE response (see below). sent as does the EXPUNGE response (see below).
The VANISHED response has two forms. The first form contains the The VANISHED response has two forms. The first form contains the
EARLIER tag, which signifies that the response was caused by a UID EARLIER tag, which signifies that the response was caused by a UID
FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. Such FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This
response is sent if the UID set parameter to the UID FETCH (VANISHED) response is sent if the UID set parameter to the UID FETCH (VANISHED)
command includes UIDs of messages that are no longer in the mailbox. command includes UIDs of messages that are no longer in the mailbox.
When the client sees a VANISHED EARLIER response it MUST NOT When the client sees a VANISHED EARLIER response it MUST NOT
decrement message sequence numbers for each successive message in the decrement message sequence numbers for each successive message in the
mailbox. mailbox.
The second form doesn't contain the EARLIER tag and is described The second form doesn't contain the EARLIER tag and is described
below. Once a client has used "(VANISHED)" with a UID FETCH or below. Once a client has used "(VANISHED)" with a UID FETCH or
"(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the "(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the
VANISHED response without the EARLIER tag instead of the EXPUNGE VANISHED response without the EARLIER tag instead of the EXPUNGE
response. The server SHOULD continue using VANISHED in lieu of response. The server SHOULD continue using VANISHED in lieu of
EXPUNGE for the duration of the connection. In particular this EXPUNGE for the duration of the connection. In particular this
affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as
well as messages expunged in other connections. Such VANISHED well as messages expunged in other connections. Such VANISHED
response MUST NOT contain the EARLIER tag. response MUST NOT contain the EARLIER tag.
A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command
or because messages were expunged in other connections (i.e. the or because messages were expunged in other connections (i.e. the
VANISHED response without the EARLIER tag) also decrements the number VANISHED response without the EARLIER tag) also decrements the number
of messages in the mailbox; it is not necessary for the server to of messages in the mailbox; it is not necessary for the server to
send an EXISTS and/or RECENT response with the new value. It also send an EXISTS response with the new value. It also decrements
decrements message sequence numbers for each successive message in message sequence numbers for each successive message in the mailbox
the mailbox (see the example at the end of this section). Note that (see the example at the end of this section). Note that a VANISHED
a VANISHED response caused by EXPUNGE/UID EXPUNGE/messages expunged response caused by EXPUNGE, UID EXPUNGE, or messages expunged in
in other connections SHOULD only contain UIDs for messages expunged other connections SHOULD only contain UIDs for messages expunged
since the last VANISHED/EXPUNGE response sent for the currently since the last VANISHED/EXPUNGE response sent for the currently
opened mailbox or since the mailbox was opened. That is, servers opened mailbox or since the mailbox was opened. That is, servers
SHOULD NOT send UIDs for previously expunged messages, unless SHOULD NOT send UIDs for previously expunged messages, unless
explicitly requested to do so by the UID FETCH (VANISHED) command. explicitly requested to do so by the UID FETCH (VANISHED) command.
Note that client implementors must take care to properly decrement Note that client implementors must take care to properly decrement
the number of messages in the mailbox even if a server violates this the number of messages in the mailbox even if a server violates this
last SHOULD or repeats the same UID multiple times in the returned last SHOULD or repeats the same UID multiple times in the returned
UID set. In general this means that a client using this extension UID set. In general this means that a client using this extension
should either avoid using message numbers entirely, or have a should either avoid using message numbers entirely, or have a
complete map of UID-to-message mapping for the selected mailbox. complete mapping of UIDs to message sequence numbers for the selected
mailbox.
Because clients handle the two different forms of the VANISHED Because clients handle the two different forms of the VANISHED
response differently, servers MUST NOT report UIDs resulting from an response differently, servers MUST NOT report UIDs resulting from an
UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same
VANISHED response as UIDs of messages expunged now (i.e. messages VANISHED response as UIDs of messages expunged now (i.e. messages
expunged in other connections). Instead the server MUST send expunged in other connections). Instead the server MUST send
separate VANISHED responses: one with the EARLIER tag and one separate VANISHED responses: one with the EARLIER tag and one
without. without.
A VANISHED response MUST NOT be sent when no command is in progress, A VANISHED response MUST NOT be sent when no command is in progress,
skipping to change at page 18, line 32 skipping to change at page 19, line 37
Clients which use the message sequence match data can reduce the Clients which use the message sequence match data can reduce the
scope of this VANISHED response substantially in the typical case scope of this VANISHED response substantially in the typical case
where expunges have not happened, or happen only toward the end of where expunges have not happened, or happen only toward the end of
the mailbox. the mailbox.
4.2. Server implementations storing minimal state 4.2. Server implementations storing minimal state
A server which stores the HIGHESTMODSEQ value at the time of the last A server which stores the HIGHESTMODSEQ value at the time of the last
EXPUNGE can omit the VANISHED response when a client provides a EXPUNGE can omit the VANISHED response when a client provides a
MODSEQ value that is equal to, or higher than, the current value of MODSEQ value that is equal to, or higher than, the current value of
this datum - that is, when there have been no EXPUNGEs. this datum; that is, when there have been no EXPUNGEs.
A client providing message sequence match data can reduce the scope A client providing message sequence match data can reduce the scope
as above. In the case where there have been no expunges, the server as above. In the case where there have been no expunges, the server
can ignore this data. can ignore this data.
4.3. Additional state required on the server 4.3. Additional state required on the server
When compared to the [CONDSTORE] extension, this extension requires When compared to the [CONDSTORE] extension, this extension requires
servers to store additional state associated with expunged messages. servers to store additional state associated with expunged messages.
Note that implementations are not required to store this state in Note that implementations are not required to store this state in
persistent storage, however use of persistent storage is advisable. persistent storage, however use of persistent storage is advisable.
One possible way to correctly implement the extension described in One possible way to correctly implement the extension described in
this document is to store a queue of <UID set, modsequence> pairs. this document is to store a queue of <UID set, modsequence> pairs.
<UID set> can be represented as a sequence of <min UID, max UID> <UID set> can be represented as a sequence of <min UID, max UID>
pairs. pairs.
When messages are expunged, one or more entry is added to the queue When messages are expunged, one or more entry are added to the queue
tail. tail.
When the server receives a request to return expunged messages since When the server receives a request to return expunged messages since
a given modsequence, it will search the queue from the tail (i.e. a given modsequence, it will search the queue from the tail (i.e.
going from the highest expunged modsequence to the lowest), until it going from the highest expunged modsequence to the lowest), until it
sees the first record with a modsequence less than or equal to the sees the first record with a modsequence less than or equal to the
given modsequence, or it reaches the head of the queue. given modsequence, or it reaches the head of the queue.
Note that indefinitely storing information about expunged messages Note that indefinitely storing information about expunged messages
can cause storage and related problems for an implementation. In the can cause storage and related problems for an implementation. In the
skipping to change at page 20, line 28 skipping to change at page 21, line 35
this value is bigger than the client's copy of the HIGHESTMODSEQ this value is bigger than the client's copy of the HIGHESTMODSEQ
value, then the client MUST use this value as its new HIGHESTMODSEQ value, then the client MUST use this value as its new HIGHESTMODSEQ
value. value.
Note: it is not safe to update the client's copy of the HIGHESTMODSEQ Note: it is not safe to update the client's copy of the HIGHESTMODSEQ
value with a MODSEQ FETCH data item value as soon as it is received, value with a MODSEQ FETCH data item value as soon as it is received,
because servers are not required to send MODSEQ FETCH data items in because servers are not required to send MODSEQ FETCH data items in
increasing modseqence order. This can lead to the client missing increasing modseqence order. This can lead to the client missing
some changes in case of connectivity loss. some changes in case of connectivity loss.
When opening the mailbox for synchronization the client uses QRESYNC When opening the mailbox for synchronization the client uses the
parameter to the SELECT/EXAMINE command. The QRESYNC parameter is QRESYNC parameter to the SELECT/EXAMINE command. The QRESYNC
followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ values, as parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ
known to the client. It can be optionally followed by the set of values, as known to the client. It can be optionally followed by the
UIDs, for example if the client is only interested in partial set of UIDs, for example if the client is only interested in partial
synchronization of the mailbox. The client may also transmit a list synchronization of the mailbox. The client may also transmit a list
containing its knowledge of message numbers. containing its knowledge of message numbers.
If the SELECT/EXAMINE command is successful, the client compares If the SELECT/EXAMINE command is successful, the client compares
UIDVALIDITY as described in step d)1) in section 3 of the UIDVALIDITY as described in step d)1) in section 3 of the
[IMAP-DISC]. If the cached UIDVALIDITY value matches the one [IMAP-DISC]. If the cached UIDVALIDITY value matches the one
returned by the server and the server also returns the HIGHESTMODSEQ returned by the server and the server also returns the HIGHESTMODSEQ
response code, then the server reports expunged messages/returns flag response code, then the server reports expunged messages and returns
changes for all messages specified by the client in the UID set flag changes for all messages specified by the client in the UID set
parameter (or for all messages in the mailbox, if the client omitted parameter (or for all messages in the mailbox, if the client omitted
the UID set parameter). At this point the client is synchronized, the UID set parameter). At this point the client is synchronized,
except for maybe the new messages. except for maybe the new messages.
If upon a successful SELECT/EXAMINE (QRESYNC) command the client If upon a successful SELECT/EXAMINE (QRESYNC) command the client
receives a NOMODSEQ OK untagged response (instead of the receives a NOMODSEQ OK untagged response (instead of the
HIGHESTMODSEQ response code), it MUST remove the last known HIGHESTMODSEQ response code), it MUST remove the last known
HIGHESTMODSEQ value from its cache and follow the more general HIGHESTMODSEQ value from its cache and follow the more general
instructions in section 3 of the [IMAP-DISC]. instructions in section 3 of the [IMAP-DISC].
skipping to change at page 22, line 14 skipping to change at page 23, line 14
C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198)) C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198))
S: * 172 EXISTS S: * 172 EXISTS
S: * 1 RECENT S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 201] Predicted next UID S: * OK [UIDNEXT 201] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: * OK [HIGHESTMODSEQ 20010715194045007] S: * OK [HIGHESTMODSEQ 20010715194045007]
S: * VANISHED (EARLIER) 1:5,7:8,10:15
S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) S: * 2 FETCH (UID 6 MODSEQ (20010715205008000)
FLAGS (\Deleted)) FLAGS (\Deleted))
S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) S: * 5 FETCH (UID 9 MODSEQ (20010715195517000)
FLAGS ($NoJunk $AutoJunk $MDNSent)) FLAGS ($NoJunk $AutoJunk $MDNSent))
... ...
S: * VANISHED 1:5,7:8,10:15
S: A142 OK [READ-WRITE] SELECT completed S: A142 OK [READ-WRITE] SELECT completed
6. Formal Syntax 6. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF]. Form (ABNF) notation as specified in [ABNF].
Non-terminals referenced but not defined below are as defined by Non-terminals referenced but not defined below are as defined by
[RFC3501], [CONDSTORE] or [IMAPABNF]. [RFC3501], [CONDSTORE] or [IMAPABNF].
 End of changes. 36 change blocks. 
71 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/