draft-ietf-lemonade-reconnect-client-04.txt   draft-ietf-lemonade-reconnect-client-05.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: October 28, 2007 C. Wilson Expires: December 13, 2007 C. Wilson
Nokia Nokia
April 26, 2007 June 11, 2007
IMAP4 Extensions for Quick Mailbox Resynchronization IMAP4 Extensions for Quick Mailbox Resynchronization
draft-ietf-lemonade-reconnect-client-04.txt draft-ietf-lemonade-reconnect-client-05.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 October 28, 2007. This Internet-Draft will expire on December 13, 2007.
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.
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 Changes since draft-ietf-lemonade-reconnect-client-03.txt
o Fixed several typos reported by Randy Gellens. o Fixed several typos reported by Randy Gellens.
o Fixed a couple of errors in examples and text reported by Dan o Fixed a couple of errors in examples and text reported by Dan
Karp. Karp.
Changes since draft-ietf-lemonade-reconnect-client-02.txt Changes since draft-ietf-lemonade-reconnect-client-02.txt
o Fixed description of the synchronization sequence to properly o Fixed description of the synchronization sequence to properly
skipping to change at page 3, line 9 skipping to change at page 3, line 16
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 . . . . . . . . . . . . . . . . . . . . 4
2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 6
3.1. QRESYNC parameter to SELECT/EXAMINE . . . . . . . . . . . 5 3.1. QRESYNC parameter to SELECT/EXAMINE . . . . . . . . . . . 6
3.2. VANISHED UID FETCH modifier . . . . . . . . . . . . . . . 10 3.2. VANISHED UID FETCH modifier . . . . . . . . . . . . . . . 11
3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 11 3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 12
3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 12 3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 13
3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 13 3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 14
3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 14 3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 15
4. Server implementation considerations . . . . . . . . . . . . . 17 3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 17
4.1. Server implementations that don't store extra state . . . 17 4. Server implementation considerations . . . . . . . . . . . . . 18
4.2. Server implementations storing minimal state . . . . . . . 17 4.1. Server implementations that don't store extra state . . . 18
4.3. Additional state required on the server . . . . . . . . . 17 4.2. Server implementations storing minimal state . . . . . . . 18
4.3. Additional state required on the server . . . . . . . . . 18
5. Updated synchronization sequence . . . . . . . . . . . . . . . 19 5. Updated synchronization sequence . . . . . . . . . . . . . . . 19
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26
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
skipping to change at page 4, line 48 skipping to change at page 4, line 48
to the IMAP server, without forcing the user to experience long delay to the IMAP server, without forcing the user to experience long delay
and pay big bills for the amount of traffic generated by and pay big bills for the amount of traffic 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 to "QRESYNC".]] 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-W02-QRESYNC" as one of the supported capabilities to the "X-DRAFT-W05-QRESYNC" as one of the supported capabilities to the
CAPABILITY command. Note, that this extension REQUIREs support for CAPABILITY command.
the [CONDSTORE] IMAP extension, so it MUST be announced in the
CAPABILITY response as well. Servers supporting this extension MUST implement and advertise
support for the [ENABLE] IMAP extension. Also, the presence of the
"X-DRAFT-W05-QRESYNC" capability implies support for the [CONDSTORE]
IMAP extension even if the "CONDSTORE" capability isn't advertised.
A server compliant with this specification is REQUIREd to support
"ENABLE X-DRAFT-W05-QRESYNC" and "ENABLE X-DRAFT-W05-QRESYNC
CONDSTORE" (which are "CONDSTORE enabling commands", as defined in
[CONDSTORE], and have identical results), but there is no requirement
for a compliant server to support "ENABLE CONDSTORE" by itself. The
"ENABLE X-DRAFT-W05-QRESYNC"/"ENABLE X-DRAFT-W05-QRESYNC CONDSTORE"
command 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.
For compatibility with clients that only support the [CONDSTORE] IMAP
extension, servers SHOULD advertise "CONDSTORE" in the CAPABILITY
response as well.
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.
skipping to change at page 7, line 21 skipping to change at page 7, line 41
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 provided 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:*". client has specified "1:<maxuid>", where <maxuid> is the mailbox's
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
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: A02 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: * 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]
skipping to change at page 8, line 17 skipping to change at page 8, line 38
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: * VANISHED 41,43:116,118,120:211,214:540
S: A02 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
skipping to change at page 9, line 7 skipping to change at page 9, line 25
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: A02 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
skipping to change at page 9, line 30 skipping to change at page 10, line 4
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: * 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 [...] S: * VANISHED 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: A02 OK [READ-WRITE] mailbox selected S: A04 OK [READ-WRITE] mailbox selected
Example: Example:
C: A02 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)
skipping to change at page 10, line 27 skipping to change at page 10, line 47
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 29998:29999,30001:30002,30004:30005,30007:30008 S: * VANISHED 29998:29999,30001:30002,30004:30005,30007:30008
S: A02 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.
skipping to change at page 10, line 50 skipping to change at page 11, line 26
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 TAG correlator. described in Section 3.6, which MUST contain the EARLIER tag.
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 11, line 42 skipping to change at page 12, line 16
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: * 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 (TAG "s100") 300:310,405,411 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
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
skipping to change at page 13, line 44 skipping to change at page 14, line 21
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-W02-QRESYNC [[anchor11: change before [UIDPLUS] and X-DRAFT-W05-QRESYNC [[anchor11: RFC editor: change
publication]] extensions must implement UID EXPUNGE as described in before publication]] extensions must implement UID EXPUNGE as
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.
If the server does not support the UIDPLUS capability, the client
SHOULD fall back to using the STORE command to temporarily remove the
\Deleted flag from messages it does not want to remove, then issuing
the EXPUNGE command. Finally, the client SHOULD use the STORE
command to restore the \Deleted flag on the messages in which it was
temporarily removed.
Alternatively, the client MAY fall back to using just the EXPUNGE
command, risking the unintended removal of some messages.
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
skipping to change at page 15, line 4 skipping to change at page 15, line 17
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. See the
description of the EXPUNGE response in [RFC3501] for further description of the EXPUNGE response in [RFC3501] for further
explanation. explanation.
3.6. VANISHED Response 3.6. VANISHED Response
Contents: optional correlators
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 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 starts with an optional correlator. If it is The VANISHED response has two forms. The first form contains the
present and contains the TAG correlator type, then the response is a EARLIER tag, which signifies that the response was caused by a UID
result of a UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. Such
command. Other correlators can be added in the future. 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.
The VANISHED response is sent as a result of a UID FETCH (VANISHED) When the client sees a VANISHED EARLIER response it MUST NOT
command, if the UID set parameter to the UID FETCH (VANISHED) command decrement message sequence numbers for each successive message in the
includes UIDs of messages that are no longer in the mailbox. Such mailbox.
VANISHED response MUST contain the TAG correlator.
Once a client has used "(VANISHED)" with a UID FETCH or "(QRESYNC)" The second form doesn't contain the EARLIER tag and is described
with SELECT/EXAMINE command, the server SHOULD use the VANISHED below. Once a client has used "(VANISHED)" with a UID FETCH or
response instead of the EXPUNGE response. The server SHOULD continue "(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the
using VANISHED in lieu of EXPUNGE for the duration of the connection. VANISHED response without the EARLIER tag instead of the EXPUNGE
In particular this affects the EXPUNGE [RFC3501] and UID EXPUNGE response. The server SHOULD continue using VANISHED in lieu of
[UIDPLUS] commands, as well as messages expunged in other EXPUNGE for the duration of the connection. In particular this
connections. Such VANISHED response MUST NOT contain the TAG affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as
correlator. well as messages expunged in other connections. Such VANISHED
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 also or because messages were expunged in other connections (i.e. the
decrements the number of messages in the mailbox; it is not necessary VANISHED response without the EARLIER tag) also decrements the number
for the server to send an EXISTS and/or RECENT response with the new of messages in the mailbox; it is not necessary for the server to
value. It also decrements message sequence numbers for each send an EXISTS and/or RECENT response with the new value. It also
successive message in the mailbox (see the example at the end of this decrements message sequence numbers for each successive message in
section). Note that a VANISHED response caused by EXPUNGE/UID the mailbox (see the example at the end of this section). Note that
EXPUNGE/messages expunged in other connections SHOULD only contain a VANISHED response caused by EXPUNGE/UID EXPUNGE/messages expunged
UIDs for messages expunged since the last VANISHED/EXPUNGE response in other connections SHOULD only contain UIDs for messages expunged
sent for the currently opened mailbox or since the mailbox was since the last VANISHED/EXPUNGE response sent for the currently
opened. That is, servers SHOULD NOT send UIDs for previously opened mailbox or since the mailbox was opened. That is, servers
expunged messages, unless explicitly requested to do so by the UID SHOULD NOT send UIDs for previously expunged messages, unless
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 map of UID-to-message mapping for the selected mailbox.
Because clients handle the two different forms of the VANISHED
response differently, servers MUST NOT report UIDs resulting from an
UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same
VANISHED response as UIDs of messages expunged now (i.e. messages
expunged in other connections). Instead the server MUST send
separate VANISHED responses: one with the EARLIER tag and one
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.
Note: UID FETCH, UID STORE, and UID SEARCH are different commands Note: UID FETCH, UID STORE, and UID SEARCH are different commands
from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent
skipping to change at page 16, line 41 skipping to change at page 17, line 20
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-W02-QRESYNC [[anchor12: change before Without the X-DRAFT-W05-QRESYNC [[anchor12: RFC editor: change before
publication]] 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.
skipping to change at page 17, line 14 skipping to change at page 17, line 40
(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
The CLOSED response code has no parameters. A server implementing
the extension defined in this document MUST return the CLOSED
response code when the currently selected mailbox is closed
implicitly using the SELECT/EXAMINE command on another mailbox.
There is no need to return this response code on completion of the
CLOSE or the UNSELECT [UNSELECT] command (or similar) who's purpose
is to close the currently selected mailbox without opening a new one.
The CLOSED response code serves as a boundary between responses for
the previously opened mailbox (which was closed) and the newly
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 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
modsequences associated with expunged messages can be considered modsequences associated with expunged messages can be considered
compliant with this specification. Such implementations return all compliant with this specification. Such implementations return all
skipping to change at page 17, line 40 skipping to change at page 18, line 32
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
skipping to change at page 19, line 10 skipping to change at page 19, line 50
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. MUST be deleted as well.
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-W02- An advanced disconnected mail client should use the X-DRAFT-W05-
QRESYNC [[anchor18: Fix before publication]] and [CONDSTORE] QRESYNC [[anchor18: RFC editor: change before publication]] and
extensions when they are supported by the server. The client uses [CONDSTORE] extensions when they are supported by the server. The
the value from the HIGHESTMODSEQ OK response code received on mailbox client uses the value from the HIGHESTMODSEQ OK response code
opening to determine if it needs to resynchronize. Once the received on mailbox opening to determine if it needs to
synchronization is complete it MUST cache the received value (unless resynchronize. Once the synchronization is complete it MUST cache
the mailbox UIDVALIDITY value has changed; See below). The client the received value (unless the mailbox UIDVALIDITY value has changed;
MUST update its copy of the HIGHESTMODSEQ value whenever the server See below). The client MUST update its copy of the HIGHESTMODSEQ
sends a subsequent HIGHESTMODSEQ OK response code. value whenever the server sends a subsequent HIGHESTMODSEQ OK
response code.
The client MUST also take note of any MODSEQ FETCH data items The client MUST also take note of any MODSEQ FETCH data items
received from the server. Whenever the client receives a tagged received from the server. Whenever the client receives a tagged
response to a command, it calculates the highest value among all response to a command, it calculates the highest value among all
MODSEQ FETCH data items received since the last tagged response. If MODSEQ FETCH data items received since the last tagged response. If
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
skipping to change at page 20, line 14 skipping to change at page 21, line 10
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-W02-QRESYNC & CONDSTORE [IMAP-DISC] in the presence of the X-DRAFT-W05-QRESYNC & CONDSTORE
extensions is amended as follows: extensions is 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] for more details) after issuing SELECT/ [IMAP-DISC] for more details) after issuing SELECT/
EXAMINE (QRESYNC) command. If the UIDVALIDITY value EXAMINE (QRESYNC) command. If the UIDVALIDITY value
returned by the server differs, the client MUST returned by the server differs, the client MUST
skipping to change at page 21, line 35 skipping to change at page 22, line 35
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-W02-QRESYNC" capability =/ "X-DRAFT-W05-QRESYNC"
;; [[Note to RFC Editor: fix before ;; [[Note to RFC Editor: change before
;; publication]] ;; 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.
known-uid-set = sequence-set known-uid-set = sequence-set
;; set of UIDs corresponding to the messages in ;; set of UIDs corresponding to the messages in
;; known-sequence-set, in ascending order. ;; known-sequence-set, in ascending order.
;; * is not allowed. ;; * is not allowed.
message-data =/ expunged-resp message-data =/ expunged-resp
expunged-resp = "VANISHED" [expunge-correlator] SP known-uids expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids
expunge-correlator = SP "(" single-exp-correlator
*(SP single-exp-correlator) ")"
;; Unless explicitly specified otherwise,
;; all correlator types must be specified
;; only once.
single-exp-correlator = "TAG" SP tag-string
;; Correlator type followed by parameters
rexpunges-fetch-mod = "VANISHED" rexpunges-fetch-mod = "VANISHED"
;; VANISHED UID FETCH modifier conforms ;; VANISHED UID FETCH modifier conforms
;; to the fetch-modifier syntax ;; to the fetch-modifier syntax
;; defined in [IMAPABNF]. It is only ;; defined in [IMAPABNF]. It is only
;; allowed in the UID FETCH command. ;; allowed in the UID FETCH command.
resp-text-code =/ "CLOSED"
7. Security Considerations 7. Security Considerations
As always, it is important to thoroughly test clients and servers As always, it is important to thoroughly test clients and servers
implementing this extension, as it changes how the server reports implementing this extension, as it changes how the server reports
expunged messages to the client. expunged messages to the client.
Security considerations relevant to [CONDSTORE] are relevant to this Security considerations relevant to [CONDSTORE] are relevant to this
extension. extension.
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-W02-QRESYNC [[anchor22: The final This document defines the X-DRAFT-W05-QRESYNC [[anchor22: The final
capability name will be chosen during AUTH48]] IMAP capability. IANA capability name will be chosen during AUTH48]] IMAP capability. IANA
is requested to add this capability to the registry. is requested to add 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,
Peter Coates, Mark Crispin, Elwyn Davies and Dan Karp. Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp 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., Ed. and P. Overell, Ed., "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005. Syntax Specifications: ABNF", RFC 4234, October 2005.
[CONDSTORE] [CONDSTORE]
Melnikov, A. and S. Hole, "IMAP Extension for Conditional Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE Operation or Quick Flag Changes Resynchronization", STORE Operation or Quick Flag Changes Resynchronization",
RFC 4551, June 2006. RFC 4551, June 2006.
[ENABLE] Gulbrandsen, A., "The IMAP ENABLE Extension",
draft-gulbrandsen-imap-enable (work in progress),
March 2007.
[IMAPABNF] [IMAPABNF]
Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 Melnikov, A. and C. Daboo, "Collected Extensions to 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., "Synchronization Operations For Disconnected Melnikov, A., "Synchronization Operations For Disconnected
Imap4 Clients", RFC 4549, June 2006. Imap4 Clients", RFC 4549, June 2006.
[UNSELECT]
Melnikov, A., "Internet Message Access Protocol (IMAP)
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
 End of changes. 47 change blocks. 
110 lines changed or deleted 165 lines changed or added

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