draft-ietf-lemonade-reconnect-client-06.txt   rfc5162.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft D. Cridland Request for Comments: 5162 D. Cridland
Intended status: Standards Track Isode Ltd Category: Standards Track Isode Ltd
Expires: March 31, 2008 C. Wilson C. Wilson
Nokia Nokia
September 28, 2007
IMAP4 Extensions for Quick Mailbox Resynchronization IMAP4 Extensions for Quick Mailbox Resynchronization
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
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 March 31, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007). This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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 of a list of
expunged messages (and always includes the UIDs expunged). expunged messages (and always includes the Unique Identifiers (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
o Clarified handling of omitted list of known UIDs.
o Clarified interaction with the CONDSTORE extension.
o Renamed TAG to EARLIER and removed the associated tag parameter.
o Made QRESYNC extension depend on ENABLE.
o Removed text about client emulating UID EXPUNGE in absence of
UIDPLUS.
o Added CLOSED response code.
Changes since draft-ietf-lemonade-reconnect-client-03.txt
o Fixed several typos reported by Randy Gellens.
o Fixed a couple of errors in examples and text reported by Dan
Karp.
Changes since draft-ietf-lemonade-reconnect-client-02.txt
o Fixed description of the synchronization sequence to properly
describe how HIGHESTMODSEQ is used.
o Fixed a couple of errors in ABNF.
Changes since draft-ietf-lemonade-reconnect-client-01.txt
o Folded the EXPUNGED extension
(draft-melnikov-imap-expunged-02.txt) into this document. Updated
mailbox synchronization instructions.
o Added UID sequence number matching.
o Clarified how NOMODSEQ response affects this extension.
o Other minor editorial changes and fixes.
Changes since draft-ietf-lemonade-reconnect-client-00.txt
o Changed server behavior when the specified UIDVALIDITY doesn't
match the current. This allows the client to chose how to proceed
after that.
o If client's UIDVALIDITY doesn't match server's, the server will
not return any flags anymore.
o Clarified that SELECT (QRESYNC) is a CONDSTORE-enabling command.
o Other minor editorial changes and fixes.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
2. Introduction and Overview . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 7 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 4
3.1. QRESYNC parameter to SELECT/EXAMINE . . . . . . . . . . . 7 3.1. QRESYNC Parameter to SELECT/EXAMINE . . . . . . . . . . . 4
3.2. VANISHED UID FETCH modifier . . . . . . . . . . . . . . . 12 3.2. VANISHED UID FETCH Modifier . . . . . . . . . . . . . . . 8
3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 13 3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 10
3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 14 3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 11
3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 15 3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 11
3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 16 3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 12
3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 18 3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 15
4. Server implementation considerations . . . . . . . . . . . . . 19 4. Server Implementation Considerations . . . . . . . . . . . . . 15
4.1. Server implementations that don't store extra state . . . 19 4.1. Server Implementations That Don't Store Extra State . . . 15
4.2. Server implementations storing minimal state . . . . . . . 19 4.2. Server Implementations Storing Minimal State . . . . . . . 16
4.3. Additional state required on the server . . . . . . . . . 19 4.3. Additional State Required on the Server . . . . . . . . . 16
5. Updated synchronization sequence . . . . . . . . . . . . . . . 21 5. Updated Synchronization Sequence . . . . . . . . . . . . . . . 17
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
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. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol
exchange.
Understanding of the IMAP message sequence numbers and UIDs and the
EXPUNGE response [RFC3501] is essential when reading this document.
[[anchor2: Editorial comments and questions are marked like this.]]
2. Introduction and Overview 1. Introduction and Overview
The [CONDSTORE] extension gives a disconnected client the 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 of 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, while minimizing delay experienced by the user as to the IMAP server, while minimizing delay experienced by the user as
well as the amount of traffic (and hence the expense) 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
everywhere in the document from "X-DRAFT-W05-QRESYNC" to "QRESYNC".]]
The quick resync IMAP extension is present if an IMAP4 server returns The quick resync IMAP extension is present if an IMAP4 server returns
"X-DRAFT-W05-QRESYNC" as one of the supported capabilities to the "QRESYNC" as one of the supported capabilities to the CAPABILITY
CAPABILITY command. command.
Servers supporting this extension MUST implement and advertise Servers supporting this extension MUST implement and advertise
support for the [ENABLE] IMAP extension. Also, the presence of the support for the [ENABLE] IMAP extension. Also, the presence of the
"X-DRAFT-W05-QRESYNC" capability implies support for the [CONDSTORE] "QRESYNC" capability implies support for the [CONDSTORE] IMAP
IMAP extension even if the "CONDSTORE" capability isn't advertised. extension even if the CONDSTORE capability isn't advertised. A
A server compliant with this specification is REQUIREd to support server compliant with this specification is REQUIREd to support
"ENABLE X-DRAFT-W05-QRESYNC" and "ENABLE X-DRAFT-W05-QRESYNC "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE
CONDSTORE" (which are "CONDSTORE enabling commands", as defined in enabling commands", as defined in [CONDSTORE], and have identical
[CONDSTORE], and have identical results), but there is no requirement results), but there is no requirement for a compliant server to
for a compliant server to support "ENABLE CONDSTORE" by itself. The support "ENABLE CONDSTORE" by itself. The "ENABLE QRESYNC"/"ENABLE
"ENABLE X-DRAFT-W05-QRESYNC"/"ENABLE X-DRAFT-W05-QRESYNC CONDSTORE" QRESYNC CONDSTORE" command also tells the server that it SHOULD start
command also tells the server that it SHOULD start sending VANISHED sending VANISHED responses (see Section 3.6) instead of EXPUNGE
responses (see Section 3.6) instead of EXPUNGE responses. This responses. This change remains in effect until the connection is
change remains in effect until the connection is closed. 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" A client making use of this extension MUST issue "ENABLE QRESYNC"
once it is authenticated. A server MUST respond with a tagged BAD once it is authenticated. A server MUST respond with a tagged BAD
response if the QRESYNC parameter to the SELECT/EXAMINE command or response if the QRESYNC parameter to the SELECT/EXAMINE command or
the VANISHED UID FETCH modifier is specified and the client hasn't the VANISHED UID FETCH modifier is specified and the client hasn't
issued "ENABLE QRESYNC" in the current connection. 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 that supports CONDSTORE but not this extension might
resynchronize a mailbox and discover that its HIGHESTMODSEQ has resynchronize a mailbox and discover that its HIGHESTMODSEQ has
increased from the value cached by the client. If the increase is increased from the value cached by the client. If the increase is
due only to messages having been expunged since the client last only due to messages having been expunged since the client last
synchronized, the client is likely to send a FETCH ... CHANGEDSINCE synchronized, the client is likely to send a FETCH ... CHANGEDSINCE
command that returns no data. Thus, a client which supports command that returns no data. Thus, a client that supports CONDSTORE
CONDSTORE but not this extension might incur a penalty of an unneeded but not this extension might incur a penalty of an unneeded round-
round-trip when resynchronizing some mailboxes (those which have had trip when resynchronizing some mailboxes (those that have had
messages expunged but no flag changes since the last messages expunged but no flag changes since the last
synchronization). synchronization).
This extra round-trip is only incurred by clients that supports This extra round-trip is only incurred by clients that support
CONDSTORE but not this extension, and only when a mailbox has had CONDSTORE but not this extension, and only when a mailbox has had
messages expunged but no flag changes to non-expunged messages. messages expunged but no flag changes to non-expunged messages.
Since CONDSTORE is a relatively new extension, it is thought likely Since CONDSTORE is a relatively new extension, it is thought likely
that clients that support it will also support this extension. that clients that support it will also support this extension.
2. 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. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol
exchange. The five characters [...] means that something has been
elided.
Understanding of the IMAP message sequence numbers and UIDs and the
EXPUNGE response [RFC3501] is essential when reading this document.
3. IMAP Protocol Changes 3. IMAP Protocol Changes
3.1. QRESYNC parameter to SELECT/EXAMINE 3.1. QRESYNC Parameter to SELECT/EXAMINE
The Quick Resynchronization parameter to SELECT/EXAMINE commands has The Quick Resynchronization parameter to SELECT/EXAMINE commands has
four arguments: four arguments:
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, and
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.
A server MUST respond with a tagged BAD response if the Quick A server MUST respond with a tagged BAD response if the Quick
Resynchronization parameter to SELECT/EXAMINE command is specified Resynchronization parameter to SELECT/EXAMINE command is specified
and the client hasn't issued "ENABLE QRESYNC" in the current and the client hasn't issued "ENABLE QRESYNC" in the current
connection. connection.
The QRESYNC parameter also tells the server that it SHOULD start Before opening the specified mailbox, the server verifies all
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
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 the server MUST other extensions). In particular this means that the server MUST
send all untagged responses as specified in Section 6.3.1/6.3.2 of send all untagged responses as specified in Sections 6.3.1 and 6.3.2
[RFC3501]. of [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 behavior 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.
Example: Attempting to resynchronize INBOX, but the provided Example: Attempting to resynchronize INBOX, but the provided
UIDVALIDITY parameter doesn't match the current UIDVALIDITY UIDVALIDITY parameter doesn't match the current UIDVALIDITY
value. value.
C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000 C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000
41,43:211,214:541)) 41,43:211,214:541))
S: * 464 EXISTS S: * 464 EXISTS
skipping to change at page 8, line 33 skipping to change at page 5, line 51
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 a 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
response code, the QRESYNC parameter still enables the use of the
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 those that have
this mailbox since the provided modification sequence. occurred in 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 specified 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
skipping to change at page 9, line 13 skipping to change at page 6, line 25
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:
tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE
"mod-sequence-value" VANISHED) "mod-sequence-value" VANISHED)
Example: Example:
C: A03 SELECT INBOX (QRESYNC (67890007 C: A03 SELECT INBOX (QRESYNC (67890007
90060115194045000 41,43:211,214:541)) 90060115194045000 41,43:211,214:541))
S: * OK [CLOSED] S: * OK [CLOSED]
S: * 314 EXISTS S: * 314 EXISTS
S: * 15 RECENT S: * 15 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 567] Predicted next UID S: * OK [UIDNEXT 567] 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) 41,43:116,118,120:211,214:540 S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540
S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ
S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered)) (90060115194045001))
S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ
S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent)) (90060115194045308))
S: ... S: ...
S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ
S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded)) (90060115194045001))
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
for which it knows the corresponding UIDs. The server then compares for which it knows the corresponding UIDs. The server then compares
each sequence number and UID pair the client provides with the each sequence number and UID pair the client provides with the
current state of the mailbox. If a pair matches, then the client current state of the mailbox. If a pair matches, then the client
knows of any expunges up to, and including, the message, and thus knows of any expunges up to, and including, the message, and thus
will not include that range in the VANISHED response, even if the will not include that range in the VANISHED response, even if the
"mod-sequence-value" provided by the client is too old for the server "mod-sequence-value" provided by the client is too old for the server
to have data of when those messages were expunged. to have data of when those messages were expunged.
Thus if the Nth message number in the first set in the list is 4, and Thus, if the Nth message number in the first set in the list is 4,
the Nth UID in the second set in the list is 8, and the mailbox's and the Nth UID in the second set in the list is 8, and the mailbox's
fourth message has UID 8, then no UIDs equal to or less than 8 are fourth message has UID 8, then no UIDs equal to or less than 8 are
present in the VANISHED response. If the (N+1)th message number is present in the VANISHED response. If the (N+1)th message number is
12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox 12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox
has UID 25, then the lowest UID included in the VANISHED response has UID 25, then the lowest UID included in the VANISHED response
would be 9. would be 9.
In the following two examples, the server is unable to remember In the following two examples, the server is unable to remember
expunges at all, and only UIDs with messages divisible by three are expunges at all, and only UIDs with messages divisible by three are
present in the mailbox. In the first example, the client does not present in the mailbox. In the first example, the client does not
use the fourth parameter, in the second, it provides it. This use the fourth parameter; in the second, it provides it. This
example is somewhat extreme, but shows that judicious usage of the example is somewhat extreme, but shows that judicious usage of the
sequence match data can save a substantial amount of bandwidth. sequence match data can save a substantial amount of bandwidth.
Example: Example:
C: A04 SELECT INBOX (QRESYNC (67890007 C: A04 SELECT INBOX (QRESYNC (67890007
90060115194045000 1:29997)) 90060115194045000 1:29997))
S: * 10003 EXISTS S: * 10003 EXISTS
S: * 5 RECENT S: * 5 RECENT
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 [...] S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...]
29998:29999,30001:30002,30004:30005,30007:30008 29998:29999,30001:30002,30004:30005,30007:30008
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered)) (90060115194045027))
S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent)) (90060115194045028))
S: ... S: ...
S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded)) (90060115194045031))
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
S: * 5 RECENT S: * 5 RECENT
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) 29998:29999,30001:30002,30004:30005,30007: S: * VANISHED (EARLIER) 29998:29999,30001:30002,30004:30005,30007:
30008 30008
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered)) (90060115194045027))
S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent)) S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
(90060115194045028))
S: ... S: ...
S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded)) (90060115194045031))
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 A server MUST respond with a tagged BAD response if the VANISHED UID
FETCH modifier is specified and the client hasn't issued "ENABLE FETCH modifier is specified and the client hasn't issued "ENABLE
QRESYNC" in the current connection. 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 mod-sequence is larger than the specified mod-sequence.
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 mod-sequence.
Note that the modsequence(s) associated with these messages were Note that the mod-sequence(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. Any described in Section 3.6, which MUST contain the EARLIER tag. Any
VANISHED (EARLIER) responses MUST be returned before any FETCH VANISHED (EARLIER) responses MUST be returned before any FETCH
responses, as otherwise the client might get confused about how responses, as otherwise the client might get confused about how
message numbers map to UIDs. message numbers map to UIDs.
Note: a server that receives a modsequence smaller than any of the Note: A server that receives a mod-sequence smaller than <minmodseq>,
expunged modsequence it remembers about MUST behave as if it was where <minmodseq> is the value of the smallest expunged mod-sequence
requested to report all expunged messages from the provided UID set it remembers minus one, MUST behave as if it was requested to report
parameter. all expunged messages from the provided UID set parameter.
The VANISHED UID FETCH modifier also instructs the server to replace
all further EXPUNGE responses with VANISHED responses. The server
MUST do this until the connection is closed.
Example 1: Without the VANISHED UID FETCH modifier a CONDSTORE-aware Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware
client [CONDSTORE] needs to issue separate commands to learn of flag client [CONDSTORE] needs to issue separate commands to learn of flag
changes and expunged messages since the last synchronization: changes and expunged messages since the last synchronization:
C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345) C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345)
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: s100 OK FETCH completed S: s100 OK FETCH completed
C: s101 UID SEARCH 300:500 C: s101 UID SEARCH 300:500
S: * SEARCH 404 406 407 408 410 412 S: * SEARCH 404 406 407 408 410 412
S: s101 OK search completed S: s101 OK search completed
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
changed since the specified modification sequence. haven't 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: * 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: 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 denied)
denied)
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
This section updates the definition of the EXPUNGE command described This section updates the definition of the EXPUNGE command described
in section 6.4.3 of [RFC3501]. in Section 6.4.3 of [RFC3501].
The EXPUNGE command permanently removes all messages that have the The EXPUNGE command permanently removes all messages that have the
\Deleted flag set from the currently selected mailbox. Before \Deleted flag set from the currently selected mailbox. Before
returning an OK to the client, those messages that are removed are returning an OK to the client, those messages that are removed are
reported using a VANISHED response or EXPUNGE responses. reported using a VANISHED response or EXPUNGE responses.
If the server is capable of storing modification sequences for the If the server is capable of storing modification sequences for the
selected mailbox, it MUST increment the per-mailbox mod-sequence if selected mailbox, it MUST increment the per-mailbox mod-sequence if
at least one message was permanently removed due to the execution of at least one message was permanently removed due to the execution of
the EXPUNGE command. For each permanently removed message the server the EXPUNGE command. For each permanently removed message, the
MUST remember the incremented mod-sequence and corresponding UID. If server MUST remember the incremented mod-sequence and corresponding
at least one message got expunged, the server MUST send the updated UID. If at least one message got expunged, the server MUST send the
per-mailbox modification sequence using the HIGHESTMODSEQ response updated per-mailbox modification sequence using the HIGHESTMODSEQ
code (defined in [CONDSTORE]) in the tagged OK response. response code (defined in [CONDSTORE]) in the tagged OK response.
Example: C: A202 EXPUNGE Example: C: A202 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 5 EXPUNGE S: * 5 EXPUNGE
S: * 8 EXPUNGE S: * 8 EXPUNGE
S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged
Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag
set. See the description of the EXPUNGE response in [RFC3501] for set. The first "* 3 EXPUNGE" reports message # 3 as expunged. The
further explanation. second "* 3 EXPUNGE" reports message # 4 as expunged (the message
number got decremented due to the previous EXPUNGE response). See
the description of the EXPUNGE response in [RFC3501] for further
explanation.
Note that once the VANISHED response is enabled on the connection the Note that if the server chooses to always send VANISHED responses
previous example might look like this: instead of EXPUNGE responses, the previous example might look like
this:
Example: C: B202 EXPUNGE Example: C: B202 EXPUNGE
S: * VANISHED 405,407,410,425 S: * VANISHED 405,407,410,425
S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged
Here messages with message numbers 3, 4, 7, and 11 have respective
Here messages with message numbers 3, 4, 7 and 11 have respective UIDs 405, 407, 410, and 425.
UIDs 405, 407, 410 and 425.
3.4. CLOSE Command 3.4. CLOSE Command
Arguments: none Arguments: none
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - close completed, now in authenticated state Result: OK - close completed, now in authenticated state
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
This section updates the definition of the CLOSE command described in This section updates the definition of the CLOSE command described in
section 6.4.2 of [RFC3501]. Section 6.4.2 of [RFC3501].
The CLOSE command permanently removes all messages that have the The CLOSE command permanently removes all messages that have the
\Deleted flag set from the currently selected mailbox, and returns to \Deleted flag set from the currently selected mailbox, and returns to
the authenticated state from the selected state. No untagged EXPUNGE the authenticated state from the selected state. No untagged EXPUNGE
(or VANISHED) responses are sent. (or VANISHED) responses are sent.
If the server is capable of storing modification sequences for the If the server is capable of storing modification sequences for the
selected mailbox, it MUST increment the per-mailbox mod-sequence if selected mailbox, it MUST increment the per-mailbox mod-sequence if
at least one message was permanently removed due to the execution of at least one message was permanently removed due to the execution of
the CLOSE command. For each permanently removed message the server the CLOSE command. For each permanently removed message, the server
MUST remember the incremented mod-sequence and corresponding UID. If MUST remember the incremented mod-sequence and corresponding UID. If
at least one message got expunged, the server MUST send the updated at least one message got expunged, the server MUST send the updated
per-mailbox modification sequence using the HIGHESTMODSEQ response per-mailbox modification sequence using the HIGHESTMODSEQ response
code (defined in [CONDSTORE]) in the tagged OK response. code (defined in [CONDSTORE]) in the tagged OK response.
Example: C: A202 CLOSE Example: C: A202 CLOSE
S: A202 OK [HIGHESTMODSEQ 20010715194045319] done S: A202 OK [HIGHESTMODSEQ 20010715194045319] done
3.5. UID EXPUNGE Command 3.5. UID EXPUNGE Command
Arguments: message set Arguments: message set
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 denied)
denied)
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
This section updates the definition of the UID EXPUNGE command This section updates the definition of the UID EXPUNGE command
described in section 2.1 of [UIDPLUS]. Servers that implement both described in Section 2.1 of [UIDPLUS]. Servers that implement both
[UIDPLUS] and X-DRAFT-W05-QRESYNC [[anchor11: RFC editor: change [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as
before publication]] extensions must implement UID EXPUNGE as
described in this section. described in this section.
The UID EXPUNGE command permanently removes from the currently The UID EXPUNGE command permanently removes from the currently
selected mailbox all messages that both have the \Deleted flag set selected mailbox all messages that both have the \Deleted flag set
and have a UID that is included in the specified message set. If a and have a UID that is included in the specified message set. If a
message either does not have the \Deleted flag set or has a UID that message either does not have the \Deleted flag set or has a UID that
is not included in the specified message set, it is not affected. is not included in the specified message set, it is not affected.
This command is particularly useful for disconnected mode clients. This command is particularly useful for disconnected mode clients.
By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the
server, the client can avoid inadvertently removing any messages that server, the client can avoid inadvertently removing any messages that
have been marked as \Deleted by other clients between the time that have been marked as \Deleted by other clients between the time that
the client was last connected and the time the client resynchronizes. the client was last connected and the time the client resynchronizes.
Before returning an OK to the client, those messages that are removed Before returning an OK to the client, those messages that are removed
are reported using a VANISHED response or EXPUNGE responses. are reported using a VANISHED response or EXPUNGE responses.
If the server is capable of storing modification sequences for the If the server is capable of storing modification sequences for the
selected mailbox, it MUST increment the per-mailbox mod-sequence if selected mailbox, it MUST increment the per-mailbox mod-sequence if
at least one message was permanently removed due to the execution of at least one message was permanently removed due to the execution of
the UID EXPUNGE command. For each permanently removed message the the UID EXPUNGE command. For each permanently removed message, the
server MUST remember the incremented mod-sequence and corresponding server MUST remember the incremented mod-sequence and corresponding
UID. If at least one message got expunged, the server MUST send the UID. If at least one message got expunged, the server MUST send the
updated per-mailbox modification sequence using the HIGHESTMODSEQ updated per-mailbox modification sequence using the HIGHESTMODSEQ
response code (defined in [CONDSTORE]) in the tagged OK response. response code (defined in [CONDSTORE]) in the tagged OK response.
Example: C: . UID EXPUNGE 3000:3002 Example: C: . UID EXPUNGE 3000:3002
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: . OK [HIGHESTMODSEQ 20010715194045319] Ok S: . OK [HIGHESTMODSEQ 20010715194045319] Ok
Note: In this example, at least messages with message numbers 3, 4, Note: In this example, at least messages with message numbers 3, 4,
and 5 (UIDs 3000 to 3002) had the \Deleted flag set. See the and 5 (UIDs 3000 to 3002) had the \Deleted flag set. The first "* 3
description of the EXPUNGE response in [RFC3501] for further EXPUNGE" reports message # 3 as expunged. The second "* 3 EXPUNGE"
explanation. reports message # 4 as expunged (the message number got decremented
due to the previous EXPUNGE response). See the description of the
EXPUNGE response in [RFC3501] for further explanation.
3.6. VANISHED Response 3.6. VANISHED Response
Contents: an optional EARLIER tag Contents: an optional EARLIER tag
list of UIDs list of UIDs
The VANISHED response reports that the specified UIDs have been The VANISHED response reports that the specified UIDs have been
permanently removed from the mailbox. This response is similar to permanently removed from the mailbox. This response is similar to
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 that 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. This 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 issued "ENABLE QRESYNC", the server SHOULD
"(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the use the VANISHED response without the EARLIER tag instead of the
VANISHED response without the EARLIER tag instead of the EXPUNGE EXPUNGE response. The server SHOULD continue using VANISHED in lieu
response. The server SHOULD continue using VANISHED in lieu of 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 a 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 response with the new value. It also decrements send an EXISTS response with the new value. It also decrements
message sequence numbers for each successive message in the mailbox message sequence numbers for each successive message in the mailbox
(see the example at the end of this section). Note that a VANISHED (see the example at the end of this section). Note that a VANISHED
response caused by EXPUNGE, UID EXPUNGE, or messages expunged in response caused by EXPUNGE, UID EXPUNGE, or messages expunged 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 mapping of UIDs to message sequence numbers for the selected complete mapping of UIDs to message sequence numbers for the selected
mailbox. 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 a
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,
nor while responding to a FETCH, STORE, or SEARCH command. This rule nor while responding to a FETCH, STORE, or SEARCH command. This rule
is necessary to prevent a loss of synchronization of message sequence is necessary to prevent a loss of synchronization of message sequence
numbers between client and server. A command is not "in progress" numbers between client and server. A command is not "in progress"
until the complete command has been received; in particular, a until the complete command has been received; in particular, a
command is not "in progress" during the negotiation of command command is not "in progress" during the negotiation of command
continuation. continuation.
skipping to change at page 18, line 24 skipping to change at page 14, line 44
Message numbers: 1 2 3 4 5 6 7 8 9 10 11 Message numbers: 1 2 3 4 5 6 7 8 9 10 11
UIDs: x 504 505 507 508 x 510 x x x 625 UIDs: x 504 505 507 508 x 510 x x x 625
\Deleted messages: X X X X \Deleted messages: X X X X
In the presence of the extension defined in this document: In the presence of the extension defined in this document:
C: A202 EXPUNGE C: A202 EXPUNGE
S: * VANISHED 505,507,510,625 S: * VANISHED 505,507,510,625
S: A202 OK EXPUNGE completed S: A202 OK EXPUNGE completed
Without the X-DRAFT-W05-QRESYNC [[anchor12: RFC editor: change before Without the QRESYNC extension, the same example might look like:
publication]] extension the same example might look like:
C: A202 EXPUNGE C: A202 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 5 EXPUNGE S: * 5 EXPUNGE
S: * 8 EXPUNGE S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed S: A202 OK EXPUNGE completed
(Continuing previous example) If subsequently messages with UIDs 504 (Continuing previous example) If subsequently messages with UIDs 504
and 508 got marked as \Deleted: and 508 got marked as \Deleted:
C: A210 EXPUNGE C: A210 EXPUNGE
S: * VANISHED 504,508 S: * VANISHED 504,508
S: A210 OK EXPUNGE completed S: A210 OK EXPUNGE completed
I.e., the last VANISHED response only contains UIDs of messages i.e., the last VANISHED response only contains UIDs of messages
expunged since the previous VANISHED response. expunged since the previous VANISHED response.
3.7. CLOSED Response Code 3.7. CLOSED Response Code
The CLOSED response code has no parameters. A server implementing The CLOSED response code has no parameters. A server implementing
the extension defined in this document MUST return the CLOSED the extension defined in this document MUST return the CLOSED
response code when the currently selected mailbox is closed response code when the currently selected mailbox is closed
implicitly using the SELECT/EXAMINE command on another mailbox. implicitly using the SELECT/EXAMINE command on another mailbox. The
There is no need to return this response code on completion of the CLOSED response code serves as a boundary between responses for the
CLOSE or the UNSELECT [UNSELECT] command (or similar) who's purpose previously opened mailbox (which was closed) and the newly selected
is to close the currently selected mailbox without opening a new one. mailbox: all responses before the CLOSED response code relate to the
The CLOSED response code serves as a boundary between responses for mailbox that was closed, and all subsequent responses relate to the
the previously opened mailbox (which was closed) and the newly newly opened mailbox.
selected mailbox: all responses before the CLOSED response code
relate to the mailbox which was closed and all subsequent responses
relate to the newly opened mailbox.
4. Server implementation considerations There is no need to return the CLOSED response code on completion of
the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose
purpose is to close the currently selected mailbox without opening a
new one.
4. Server Implementation Considerations
This section describes a minimalist implementation, a moderate This section describes a minimalist implementation, a moderate
implementation, and an example of a full implementation. implementation, and an example of a full implementation.
4.1. Server implementations that don't store extra state 4.1. Server Implementations That Don't Store Extra State
Strictly speaking, a server implementation that doesn't remember Strictly speaking, a server implementation that doesn't remember mod-
modsequences associated with expunged messages can be considered sequences associated with expunged messages can be considered
compliant with this specification. Such implementations return all compliant with this specification. Such implementations return all
expunged messages specified in the UID set of the UID FETCH expunged messages specified in the UID set of the UID FETCH
(VANISHED) command every time, without paying attention to the (VANISHED) command every time, without paying attention to the
specified CHANGEDSINCE modsequence. Such implementations are specified CHANGEDSINCE mod-sequence. Such implementations are
discouraged, as they can end up returning VANISHED responses bigger discouraged, as they can end up returning VANISHED responses that are
than the result of a UID SEARCH command for the same UID set. bigger than the result of a UID SEARCH command for the same UID set.
Clients which use the message sequence match data can reduce the Clients that use the message sequence match data can reduce the scope
scope of this VANISHED response substantially in the typical case of this VANISHED response substantially in the typical case where
where expunges have not happened, or happen only toward the end of expunges have not happened, or happen only toward the end of the
the mailbox. 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 that 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, mod-sequence> 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 are added to the queue When messages are expunged, one or more entries are added to the
tail. queue tail.
When the server receives a request to return expunged messages since When the server receives a request to return messages expunged since
a given modsequence, it will search the queue from the tail (i.e. a given mod-sequence, 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 mod-sequence to the lowest) until it
sees the first record with a modsequence less than or equal to the sees the first record with a mod-sequence less than or equal to the
given modsequence, or it reaches the head of the queue. given mod-sequence 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
worst case, this could result in almost 64Gb of storage for each IMAP worst case, this could result in almost 64Gb of storage for each IMAP
mailbox. For example, consider an implementation that stores <min mailbox. For example, consider an implementation that stores <min
UID, max UID, modsequence> triples for each range of messages UID, max UID, mod-sequence> triples for each range of messages
expunged at the same time. Each triple requires 16 octets: 4 octets expunged at the same time. Each triple requires 16 octets: 4 octets
for each of the two UIDs, and 8 octets for the modsequence. Assume a for each of the two UIDs, and 8 octets for the mod-sequence. Assume
mailbox containing a single message with a UID of 2**32-1 (the that there is a mailbox containing a single message with a UID of
maximum possible UID value), where messages had previously existed 2**32-1 (the maximum possible UID value), where messages had
with UIDs starting at 1, and have been expunged one at a time. For previously existed with UIDs starting at 1, and have been expunged
this mailbox alone, storage is required for the triples <1, 1, one at a time. For this mailbox alone, storage is required for the
modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2, modseq4294967294>. triples <1, 1, modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2,
modseq4294967294>.
Hence, implementations are encouraged to adopt strategies to protect Hence, implementations are encouraged to adopt strategies to protect
against such storage problems, such as limiting the size of the queue against such storage problems, such as limiting the size of the queue
used to store modsequences for expunged messages and "expiring" older used to store mod-sequences for expunged messages and "expiring"
records when this limit is reached. When the selected older records when this limit is reached. When the selected
implementation-specific queue limit is reached, the oldest record(s) implementation-specific queue limit is reached, the oldest record(s)
are deleted from the queue (Note that such records are located at the are deleted from the queue (note that such records are located at the
queue head). For all such "expired" records the server needs to queue head). For all such "expired" records, the server needs to
store a single modsequence, which is the highest modsequence for all store a single mod-sequence, which is the highest mod-sequence for
"expired" expunged messages. all "expired" expunged messages.
Note that if the client provides the message sequence match data, Note that if the client provides the message sequence match data,
this can heavily reduce the data cost of sending a complete set of this can heavily reduce the data cost of sending a complete set of
missing UIDs, thus reducing the problems for clients if a server is missing UIDs; thus, reducing the problems for clients if a server is
unable to persist much of this queue. If the queue contains data unable to persist much of this queue. If the queue contains data
back to the requested modsequence, this data can be ignored. back to the requested mod-sequence, this data can be ignored.
Also note that if the UIDVALIDITY of the mailbox changes or if the Also, note that if the UIDVALIDITY of the mailbox changes or if the
mailbox is deleted, then any state associated with expunged messages mailbox is deleted, then any state associated with expunged messages
MUST be deleted as well. doesn't need to be preserved and SHOULD be deleted.
5. Updated synchronization sequence 5. Updated Synchronization Sequence
This section updates the description of optimized synchronization in This section updates the description of optimized synchronization in
section 6.1 of the [IMAP-DISC]. Section 6.1 of the [IMAP-DISC].
An advanced disconnected mail client should use the X-DRAFT-W05- An advanced disconnected mail client should use the QRESYNC and
QRESYNC [[anchor18: RFC editor: change before publication]] and
[CONDSTORE] extensions when they are supported by the server. The [CONDSTORE] extensions when they are supported by the server. The
client uses the value from the HIGHESTMODSEQ OK response code client uses the value from the HIGHESTMODSEQ OK response code
received on mailbox opening to determine if it needs to received on mailbox opening to determine if it needs to
resynchronize. Once the synchronization is complete it MUST cache resynchronize. Once the synchronization is complete, it MUST cache
the received value (unless the mailbox UIDVALIDITY value has changed; the received value (unless the mailbox UIDVALIDITY value has changed;
See below). The client MUST update its copy of the HIGHESTMODSEQ see below). The client MUST update its copy of the HIGHESTMODSEQ
value whenever the server sends a subsequent HIGHESTMODSEQ OK value whenever the server sends a subsequent HIGHESTMODSEQ OK
response code. response code.
The client MUST also take note of any MODSEQ FETCH data items After completing a full synchronization, the client MUST also take
received from the server. Whenever the client receives a tagged note of any unsolicited MODSEQ FETCH data items received from the
response to a command, it calculates the highest value among all server. Whenever the client receives a tagged response to a command,
MODSEQ FETCH data items received since the last tagged response. If it calculates the highest value among all MODSEQ FETCH data items
this value is bigger than the client's copy of the HIGHESTMODSEQ received since the last tagged response. If this value is bigger
value, then the client MUST use this value as its new HIGHESTMODSEQ than the client's copy of the HIGHESTMODSEQ value, then the client
value. MUST use this value as its new HIGHESTMODSEQ 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 the When opening the mailbox for synchronization, the client uses the
QRESYNC parameter to the SELECT/EXAMINE command. The QRESYNC QRESYNC parameter to the SELECT/EXAMINE command. The QRESYNC
parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ
values, as known to the client. It can be optionally followed by the values, as known to the client. It can be optionally followed by the
set of 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 and returns response code, then the server reports expunged messages and returns
flag 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].
At this point the client is in sync with the server regarding old At this point, the client is in sync with the server regarding old
messages. This client can now fetch information about new messages messages. This client can now fetch information about new messages
(if requested by the user). (if requested by the user).
Step d) ("Server-to-client synchronization") in section 4 of the Step d) ("Server-to-client synchronization") in Section 4 of the
[IMAP-DISC] in the presence of the X-DRAFT-W05-QRESYNC & CONDSTORE [IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is
extensions is amended as follows: amended as follows:
d) "Server-to-client synchronization" -- for each mailbox that d) "Server-to-client synchronization" -- for each mailbox that
requires synchronization, do the following: requires synchronization, do the following:
1a) Check the mailbox UIDVALIDITY (see section 4.1 of the 1a) Check the mailbox UIDVALIDITY (see Section 4.1 of the [IMAP-DISC]
[IMAP-DISC] for more details) after issuing SELECT/ for more details) after issuing SELECT/EXAMINE (QRESYNC) command.
EXAMINE (QRESYNC) command. If the UIDVALIDITY value
returned by the server differs, the client MUST
* empty the local cache of that mailbox;
* "forget" the cached HIGHESTMODSEQ value for If the UIDVALIDITY value returned by the server differs, the
the mailbox; client MUST
* remove any pending "actions" which refer to * empty the local cache of that mailbox;
UIDs in that mailbox. Note, this doesn't
affect actions performed on client generated
fake UIDs (see section 5 of the [IMAP-DISC]);
* skip steps 1b and 2-II; * "forget" the cached HIGHESTMODSEQ value for the mailbox;
* remove any pending "actions" which refer to UIDs in that
mailbox. Note, this doesn't affect actions performed on
client generated fake UIDs (see Section 5 of the
[IMAP-DISC]);
2) Fetch the current "descriptors"; 2) Fetch the current "descriptors";
I) Discover new messages. I) Discover new messages.
3) Fetch the bodies of any "interesting" messages that the 3) Fetch the bodies of any "interesting" messages that the client
client doesn't already have. doesn't already have.
Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ
value has changed on the server while the client was value has changed on the server while the client was
offline: offline:
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
skipping to change at page 23, line 28 skipping to change at page 19, line 43
FLAGS ($NoJunk $AutoJunk $MDNSent)) FLAGS ($NoJunk $AutoJunk $MDNSent))
... ...
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].
Except as noted otherwise, all alphabetic characters are case- Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion. accept these strings in a case-insensitive fashion.
capability =/ "X-DRAFT-W05-QRESYNC" capability =/ "QRESYNC"
;; [[Note to RFC Editor: change before
;; publication]]
select-param = "QRESYNC" SP "(" uidvalidity SP select-param = "QRESYNC" SP "(" uidvalidity SP
mod-sequence-value [SP known-uids] mod-sequence-value [SP known-uids]
[SP seq-match-data] ")" [SP seq-match-data] ")"
;; conforms to the generic select-param ;; conforms to the generic select-param
;; syntax defined in [IMAPABNF] ;; syntax defined in [IMAPABNF]
seq-match-data = "(" known-sequence-set SP known-uid-set ")" seq-match-data = "(" known-sequence-set SP known-uid-set ")"
uidvalidity = nz-number uidvalidity = nz-number
known-uids = sequence-set known-uids = sequence-set
;; sequence of UIDs, "*" is not allowed ;; sequence of UIDs, "*" is not allowed
known-sequence-set = sequence-set known-sequence-set = sequence-set
;; set of message numbers corresponding to ;; set of message numbers corresponding to
;; the UIDs in known-uid-set, in ascending order. ;; the UIDs in known-uid-set, in ascending order.
;; * is not allowed. ;; * is not allowed.
skipping to change at page 25, line 4 skipping to change at page 21, line 12
This document doesn't raise any new security concerns not already This document doesn't raise any new security concerns not already
raised by [CONDSTORE] or [RFC3501]. raised by [CONDSTORE] or [RFC3501].
8. IANA Considerations 8. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located IESG approved experimental RFC. The registry is currently located
at: at:
http://www.iana.org/assignments/imap4-capabilities http://www.iana.org/assignments/imap4-capabilities
This document defines the X-DRAFT-W05-QRESYNC [[anchor22: The final
capability name will be chosen during AUTH48]] IMAP capability. IANA This document defines the QRESYNC IMAP capability. IANA has added
is requested to add this capability to the registry. this capability to the registry.
9. Acknowledgments 9. Acknowledgments
Thanks to Steve Hole, Cyrus Daboo and Michael Wener for encouraging Thanks to Steve Hole, Cyrus Daboo, and Michael Wener for encouraging
creation of this document. creation of this document.
Valuable comments, both in agreement and in dissent, were received Valuable comments, both in agreement and in dissent, were received
from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen, from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen,
Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp and Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp,
Mike Zraly. Eric Rescorla, and Mike Zraly.
This document takes substantial text from [RFC3501] by Mark Crispin. This document takes substantial text from [RFC3501] by Mark Crispin.
10. References 10. References
10.1. Normative References 10.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Syntax Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[CONDSTORE] [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for
Melnikov, A. and S. Hole, "IMAP Extension for Conditional Conditional STORE Operation or Quick Flag Changes
STORE Operation or Quick Flag Changes Resynchronization", Resynchronization", RFC 4551, June 2006.
RFC 4551, June 2006.
[ENABLE] Gulbrandsen, A., "The IMAP ENABLE Extension", [ENABLE] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
draft-gulbrandsen-imap-enable (work in progress), ENABLE Extension", RFC 5161, March 2008.
March 2007.
[IMAPABNF] [IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to
Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 IMAP4 ABNF", RFC 4466, April 2006.
ABNF", RFC 4466, April 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, December 2005. UIDPLUS extension", RFC 4315, December 2005.
10.2. Informative References 10.2. Informative References
[IMAP-DISC] [IMAP-DISC] Melnikov, A., Ed., "Synchronization Operations For
Melnikov, A., "Synchronization Operations For Disconnected Disconnected Imap4 Clients", RFC 4549, June 2006.
Imap4 Clients", RFC 4549, June 2006.
[UNSELECT] [UNSELECT] Melnikov, A., "Internet Message Access Protocol (IMAP)
Melnikov, A., "Internet Message Access Protocol (IMAP)
UNSELECT command", RFC 3691, February 2004. UNSELECT command", RFC 3691, February 2004.
Authors' Addresses Authors' Addresses
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
Email: Alexey.Melnikov@isode.com EMail: Alexey.Melnikov@isode.com
Dave Cridland Dave Cridland
Isode Ltd Isode Ltd
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
Email: dave.cridland@isode.com EMail: dave.cridland@isode.com
Corby Wilson Corby Wilson
Nokia Nokia
5 Wayside Rd. 5 Wayside Rd.
Burlington, MA 01803 Burlington, MA 01803
USA USA
Email: corby@computer.org EMail: corby@computer.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 27, line 44 skipping to change at line 1044
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 157 change blocks. 
431 lines changed or deleted 275 lines changed or added

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