<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
        <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
        <!ENTITY rfc3501 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3501.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-melnikov-5162bis-01.txt"
	 obsoletes="5162" updates="4315">
	<?xml-stylesheet href="rfc5162_files/rfc2629.htm" type="text/xsl"?>
        <?rfc strict="yes" ?>
        <?rfc toc="yes" ?>
	<?rfc symrefs="yes" ?>
	<?rfc sortrefs="yes"?>
	<?rfc iprnotified="no" ?>
	<?rfc strict="yes" ?>
	<?rfc comments="yes" ?>
	<?rfc inline="yes" ?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<front>
		<title abbrev="IMAP Quick Mailbox Resync">IMAP4 Extensions for Quick Mailbox Resynchronization</title>
		<author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
			<organization>Isode Ltd</organization>
			<address>
				<postal>
					<street>5 Castle Business Village</street>
					<street>36 Station Road</street>
					<city>Hampton</city>
					<region>Middlesex</region>
					<code>TW12 2BX</code>
					<country>UK</country>
				</postal>
				<email>Alexey.Melnikov@isode.com</email>
			</address>
		</author>
		<author initials="D.A." surname="Cridland" fullname="Dave Cridland">
			<organization>Isode Ltd</organization>
			<address>
				<postal>
					<street>5 Castle Business Village</street>
					<street>36 Station Road</street>
					<city>Hampton</city>
					<region>Middlesex</region>
					<code>TW12 2BX</code>
					<country>UK</country>
				</postal>
				<email>dave.cridland@isode.com</email>
			</address>
		</author>
		<date year="2013"/>
        <keyword>IMAP</keyword>
        <keyword>CONDSTORE</keyword>
        <keyword>QRESYNC</keyword>
        <keyword>VANISHED</keyword>
        <keyword>EXPUNGE</keyword>
        <keyword>quick resynchronization</keyword>

		<abstract>
			<t>This document defines an IMAP4 extension, which gives 
			an IMAP client the ability to quickly resynchronize any
			previously opened mailbox as part of the SELECT
			command, without the need for server-side state or
			additional client round-trips. This
			extension also introduces a new response that allows for a more
			compact representation of a list of expunged messages
			(and always includes the Unique Identifiers (UIDs) expunged).
			</t>
		</abstract>
	
	</front>
	<middle>
	
		
		<section title="Introduction and Overview">
			<t>
			The <xref target="CONDSTORE"/> extension gives a disconnected client
			the ability to quickly resynchronize IMAP flag changes for previously
			seen messages. This can be done using the CHANGEDSINCE FETCH modifier
			once a mailbox 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 SEARCH command. This document defines an extension to
			<xref target="CONDSTORE"/> that allows a reconnecting client to 
			perform full resynchronization, including discovery of expunged
			messages, in a single round-trip. This extension also 
			introduces a new response, VANISHED, that allows for a more compact 
			representation of a list of expunged messages.
			</t>

			<t>This extension can be useful for mobile clients
			that can experience frequent disconnects caused by environmental factors
			(battery life, signal strength, etc.). Such clients need a way
			to quickly reconnect to the IMAP server, while minimizing delay
			experienced by the user as well as the amount of traffic
			(and hence the expense) generated by resynchronization.
			</t>
			<t>
			By extending the SELECT command to perform the additional
			resynchronization, this also allows clients to reduce concurrent
			connections to the IMAP server held purely for the sake of
			avoiding the resynchronization.
			</t>
			<t>
			
			</t>
			<t>The quick resync IMAP extension is present if an IMAP4 server returns 
			"QRESYNC" as one of the supported capabilities to the 
			CAPABILITY command. 
			</t>

			<t>Servers supporting this extension MUST implement and advertise support for
			the <xref target="ENABLE"/> IMAP extension. Also, the presence of the "QRESYNC"
			capability implies support for the <xref target="CONDSTORE"/> IMAP extension
			even if the "CONDSTORE" capability isn't advertised.  A server compliant with
			this specification is REQUIREd to support "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE"
			(which are "CONDSTORE enabling commands", as defined in <xref target="CONDSTORE"/>,
			and have identical results), but there is no requirement for a compliant server
			to support "ENABLE CONDSTORE" by itself.
			The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command also tells the server that
      [[//// Change the SHOULD to MUST?]]
			it SHOULD start sending VANISHED responses (see <xref target="expunged-resp"/>) instead
			of EXPUNGE responses. This change remains in effect until the connection is closed.
			</t>

			<t>
			For compatibility with clients that only support the <xref target="CONDSTORE"/>
			IMAP extension, servers SHOULD advertise "CONDSTORE" in the CAPABILITY response as well.</t>
			
			<t>
			Once a "CONDSTORE enabling command" is issued by the client,
			the server MUST automatically include both UID and mod-sequence data
			in all subsequent untagged FETCH responses (until the connection is closed),
			whether they were caused by a regular STORE/UID STORE, a STORE/UID STORE
			with UNCHANGEDSINCE modifier, FETCH/UID FETCH that implicitly set \Seen flag
      or an external agent.
			Note that this rule doesn't affect untagged FETCH responses caused by a FETCH
			command that doesn't include UID and/or MODSEQ FETCH data item (and doesn't
      implicitly set \Seen flag), or UID FETCH without the MODSEQ FETCH data item.
			</t>

<?rfc needLines="5"?>
			<t>
			A client making use of this extension MUST issue "ENABLE QRESYNC" once it is authenticated.
			A server MUST respond with a tagged BAD response if the 
			QRESYNC parameter to the SELECT/EXAMINE command or the VANISHED UID FETCH modifier
			is specified and the client hasn't issued "ENABLE QRESYNC", or the server has not
			positively responded to that command with the untagged ENABLED response containing
			QRESYNC, in the current connection.
			</t>

			<t>
			This document puts additional requirements on a server implementing
			the <xref target="CONDSTORE"/> extension. Each mailbox that supports persistent
			storage of mod-sequences, i.e., for which the server has sent
			a HIGHESTMODSEQ untagged OK response code on a successful
			SELECT/EXAMINE, MUST increment the per-mailbox mod-sequence when one or
			more messages are expunged due to EXPUNGE,  UID EXPUNGE or CLOSE; the
			server MUST associate the incremented mod-sequence with the UIDs of
			the expunged messages.
			</t>

 			<t>
			A client that supports CONDSTORE but not this extension might resynchronize
			a mailbox and discover that its HIGHESTMODSEQ has increased from the value
			cached by the client.  If the increase is only
			due to messages having been expunged
			since the client last synchronized, the client is likely to send a
			FETCH ... CHANGEDSINCE command that returns no data.  Thus, a client that
			supports CONDSTORE but not this extension might incur a penalty of an unneeded
			round-trip when resynchronizing some mailboxes (those that have had messages
			expunged but no flag changes since the last synchronization).
			</t>

			<t>
			This extra round-trip is only incurred by clients that support CONDSTORE
			but not this extension, and only when a mailbox has had messages expunged but
			no flag changes to non-expunged messages. Since CONDSTORE is a relatively new extension,
			it is thought likely that clients that support it will also support this extension.
			</t>

		</section>
	<section title="Requirements Notation">
			<t>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 <xref target="RFC2119"/>.</t>

			<t>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.</t>

			<t>
			Understanding of the IMAP message sequence numbers and UIDs and the
			EXPUNGE response <xref target="RFC3501"/> is essential when reading this document.
			</t>

		
		</section>		
		<section title="IMAP Protocol Changes">
			<section title="QRESYNC Parameter to SELECT/EXAMINE">
				<t>
				The Quick Resynchronization parameter to SELECT/EXAMINE commands
				has four arguments:
				<list style="symbols">
				  <t>the last known UIDVALIDITY,</t>
				  <t>the last known modification sequence,</t>
				  <t>the optional set of known
				  UIDs, and</t>
				  <t>an optional parenthesized list of known sequence ranges and their corresponding UIDs.</t>
				</list>
				</t>
				
				<t>A server MUST respond with a tagged BAD response if the Quick
				Resynchronization parameter to SELECT/EXAMINE command is specified
				and the client hasn't issued "ENABLE QRESYNC" in the current
				connection, or the server has not positively responded to
				that command with the untagged ENABLED response containing QRESYNC.
				</t>

				<t>Before opening the specified mailbox, the server verifies all
				arguments for syntactic validity. If any parameter is not syntactically
				valid, the server returns the tagged BAD response, and the mailbox
				remains unselected.
				Once the check is done, the server opens the mailbox as if no
				SELECT/EXAMINE parameters are specified (this is subject to processing
				of other parameters as defined in other extensions).
				In particular this means that the server MUST send all untagged responses
				as specified in Sections 6.3.1 and 6.3.2 of <xref target="RFC3501"/>.
				</t>

				<t>
				After that, the server checks the UIDVALIDITY value provided by the client.
				If the provided UIDVALIDITY doesn't match the UIDVALIDITY for the mailbox
				being opened, then the server MUST ignore the remaining parameters and
				behave as if no dynamic message data changed. The client can discover
				this situation by comparing the UIDVALIDITY value returned by the server.
				This behavior allows the client not to synchronize the mailbox or decide
				on the best synchronization strategy.
				</t>
				<t>

<list style="hanging" hangIndent="9">
				<t hangText="Example:">
				Attempting to resynchronize INBOX, but the provided UIDVALIDITY parameter
				doesn't match the current UIDVALIDITY value.
				</t><t>
				C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000 41,43:211,214:541))<vspace/>
				S: * 464 EXISTS<vspace/>
				S: * 3 RECENT<vspace/>
				S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY<vspace/>
				S: * OK [UIDNEXT 550] Predicted next UID<vspace/>
				S: * OK [HIGHESTMODSEQ 90060128194045007] Highest mailbox mod-sequence<vspace/>
				S: * OK [UNSEEN 12] Message 12 is first unseen<vspace/>
				S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)<vspace/>
				S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft<vspace/>
				    \Deleted \Seen \*)] Permanent flags<vspace/>
				S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch
				</t>
				</list>
				</t>

				<t>
				Modification Sequence and UID Parameters:
				</t>

				<t>
				A server that doesn't support the persistent storage of mod-sequences
				for the mailbox MUST send the OK untagged response including the NOMODSEQ
				response code with every successful SELECT or EXAMINE command, as
				described in <xref target="CONDSTORE"/>. Such a server doesn't need
				to remember mod-sequences for expunged messages in the mailbox.
				It MUST ignore the remaining parameters and behave as if no dynamic
				message data changed.
				</t>

				<t>
				If the provided UIDVALIDITY matches that of the selected mailbox,
				the server then checks the last known modification sequence.
				<vspace/>
				The server sends the client any pending flag changes (using FETCH responses that 
				MUST contain UIDs) and expunges those that have occurred in this mailbox since the provided 
				modification sequence.
				</t>
				<t>
				If the list of known UIDs was also provided, the server should only 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 has specified "1:&lt;maxuid&gt;",
				where &lt;maxuid&gt; 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.
				</t>
				<t>
				Thus, the client can process just these pending events and need not perform
				a full resynchronization. 
				Without the message sequence number matching information, the result of this
				step is semantically equivalent to the client issuing:
				<vspace/>
				tag1 UID FETCH <spanx style="verb">known-uids</spanx> (FLAGS) (CHANGEDSINCE 
				<spanx style="verb">mod-sequence-value</spanx> VANISHED)
				</t>
        
        <t>
        In particular this means that all requirement specified in <xref target="FETCH-VANISHED"/> apply. 
        </t>
        
        <t>
				<list style="hanging">
					<t hangText="Example:">

<!-- [rfced] Please note that because some examples were put in as 
  lists and others as artwork elements, 
  the subcompact PI has been added so that all examples appear uniform.
  That is, without blank lines between each C: / S: line. -->

<?rfc subcompact="yes"?>
						<list style="hanging">
							<t hangText="C:">A03 SELECT INBOX (QRESYNC (67890007<vspace/>
							 90060115194045000 41:211,214:541))</t>
							<t hangText="S:">* OK [CLOSED]</t>
							<t hangText="S:">* 100 EXISTS</t>
							<t hangText="S:">* 11 RECENT</t>
							<t hangText="S:">* OK [UIDVALIDITY 67890007] UIDVALIDITY</t>
							<t hangText="S:">* OK [UIDNEXT 600] Predicted next UID</t>
							<t hangText="S:">* OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod-sequence</t>
							<t hangText="S:">* OK [UNSEEN 7] There are some unseen messages in the mailbox</t>
							<t hangText="S:">* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)</t>
							<t hangText="S:">* OK [PERMANENTFLAGS (\Answered \Flagged \Draft<vspace/>
							\Deleted \Seen \*)] Permanent flags</t>
							<t hangText="S:">* VANISHED (EARLIER) 41,43:116,118,120:211,214:540</t>
<!--MODSEQ is known:              
              <t hangText="S:">* 48 FETCH (UID 42 FLAGS (\Seen \Flagged) MODSEQ (90060115194045000))</t>
-->
              <t hangText="S:">* 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ (90060115194045001))</t>
							<t hangText="S:">* 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ (90060115194045308))</t>
							<t hangText="S:">* 51 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ (90060115194045001))</t>
							<t hangText="S:">A03 OK [READ-WRITE] mailbox selected</t>
						</list>
<?rfc subcompact="no"?>
					</t>
				</list>
				</t>

        <t>
        In the above example flag information for the UID 42 is not returned, presumably because its flags
        haven't changed since the MODSEQ 90060115194045000.
        </t>
        
				<t>
				Message sequence match data:
				</t>
				<t>A client MAY provide a parenthesized list of a message
				sequence set and the corresponding UID sets. Both MUST be provided in ascending order.
				The server uses this data to restrict
				the range for which it provides expunged message information.</t>
				<t>Conceptually, the client provides a small sample of sequence numbers for which
				it knows the corresponding UIDs. The server then compares each sequence number and
				UID pair the client provides with the current state of the mailbox. If a pair matches,
				then the client knows of any expunges up to, and including, the message, and thus
				will not include that range in the VANISHED response, even if the
				<spanx style="verb">mod-sequence-value</spanx> provided by the client is too old
				for the server to have data of when those messages were expunged.</t>
				<t>Thus, if the Nth message number in the first set in the list is 4, 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 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 has UID 25, then the lowest UID included in the VANISHED
				response would be 9.</t>
				<t>In the following two examples, the server is unable to remember expunges at
				all, and only UIDs with messages divisible by three are present in the mailbox.
				In the first example, the client does not use the fourth parameter; in the second,
				it provides it. This example is somewhat extreme, but shows that judicious usage
				of the sequence match data can save a substantial amount of bandwidth.</t>
				<t>
				<list style="hanging">
					<t hangText="Example:">
<?rfc subcompact="yes"?>
						<list style="hanging">
							<t hangText="C:">A04 SELECT INBOX (QRESYNC (67890007<vspace/>
							 90060115194045000 1:29997))</t>
							<t hangText="S:">* 10003 EXISTS</t>
							<t hangText="S:">* 4 RECENT</t>
							<t hangText="S:">* OK [UIDVALIDITY 67890007] UIDVALIDITY</t>
							<t hangText="S:">* OK [UIDNEXT 30013] Predicted next UID</t>
							<t hangText="S:">* OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod-sequence</t>
							<t hangText="S:">* OK [UNSEEN 7] There are some unseen messages in the mailbox</t>
							<t hangText="S:">* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)</t>
							<t hangText="S:">* OK [PERMANENTFLAGS (\Answered \Flagged \Draft<vspace/>
							\Deleted \Seen \*)] Permanent flags</t>
							<t hangText="S:">* VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14,[...],<vspace/>
              29668:29669,29671:29996</t>
              <t hangText="S:">* 1 FETCH (UID 3 FLAGS (\Seen \Answered $Important) MODSEQ (90060115194045001))</t>
              <t hangText="S:">...</t>
              <t hangText="S:">* 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ (90060115194045027))</t>
              <t hangText="S:">* 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ (90060115194045028))</t>
              <t hangText="S:">...</t>
              <t hangText="S:">* 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ (90060115194045031))</t>
							<t hangText="S:">A04 OK [READ-WRITE] mailbox selected</t>
						</list>
<?rfc subcompact="no"?>
					</t>
				</list>
				</t>

				<t>
				<list style="hanging">
					<t hangText="Example:">
<?rfc subcompact="yes"?>
						<list style="hanging">
							<t hangText="C:">B04 SELECT INBOX (QRESYNC (67890007<vspace/>
							 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000,<vspace/>
							 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991,<vspace/>
							 29994,29997)))</t>
							<t hangText="S:">* 10003 EXISTS</t>
							<t hangText="S:">* 4 RECENT</t>
							<t hangText="S:">* OK [UIDVALIDITY 67890007] UIDVALIDITY</t>
							<t hangText="S:">* OK [UIDNEXT 30013] Predicted next UID</t>
							<t hangText="S:">* OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod-sequence</t>
							<t hangText="S:">* OK [UNSEEN 7] There are some unseen messages in the mailbox</t>
							<t hangText="S:">* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)</t>
							<t hangText="S:">* OK [PERMANENTFLAGS (\Answered \Flagged \Draft<vspace/>
							\Deleted \Seen \*)] Permanent flags</t>
              <t hangText="S:">* 1 FETCH (UID 3 FLAGS (\Seen \Answered $Important) MODSEQ (90060115194045001))</t>
              <t hangText="S:">...</t>
              <t hangText="S:">* 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ (90060115194045027))</t>
							<t hangText="S:">* 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ (90060115194045028))</t>
							<t hangText="S:">...</t>
							<t hangText="S:">* 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ (90060115194045031))</t>
              <t hangText="S:">B04 OK [READ-WRITE] mailbox selected</t>
						</list>
<?rfc subcompact="no"?>
					</t>
				</list>
				</t>
			</section>

			<section title="VANISHED UID FETCH Modifier" anchor="FETCH-VANISHED">
				<t>
				<xref target="IMAPABNF"/> has extended the syntax of the FETCH and UID FETCH 
				commands to include an optional FETCH modifier.  This document 
				defines a new UID FETCH modifier: VANISHED.
				</t>

				<t>
				Note, that the VANISHED UID FETCH modifier is NOT allowed with a 
				FETCH command. The server MUST return a tagged BAD response if this 
				response is specified as a modifier to the FETCH command.
				</t>
				
				<t>A server MUST respond with a tagged BAD response if
				the VANISHED UID FETCH modifier is specified and the client hasn't issued
				"ENABLE QRESYNC" in the current connection.</t>

				<t>
				The VANISHED UID FETCH modifier MUST only be specified together
				with the CHANGEDSINCE UID FETCH modifier.
				</t>
				
				<t>
				The VANISHED UID FETCH modifier instructs the server to report
				those messages from the UID set parameter that have been expunged
				and whose associated mod-sequence is larger than the specified
				mod-sequence.  That is, the client requests to be informed of messages
				from the specified set that were expunged since the specified
				mod-sequence.  Note that the mod-sequence(s) associated with these
				messages were updated when the messages were expunged
				(as described above).
				The expunged messages are reported using the
				VANISHED response as described in <xref target="expunged-resp"/>,
				which MUST contain the EARLIER tag. Any VANISHED (EARLIER) responses
				MUST be returned before any FETCH responses, as otherwise the client
				might get confused about how message numbers map to UIDs.
				</t>

				<t>
				Note: A server that receives a mod-sequence smaller than &lt;minmodseq&gt;,
				where &lt;minmodseq&gt; is the value of the smallest expunged mod-sequence
				it remembers minus one, MUST behave as if
				it was requested to report all expunged messages from the provided
				UID set parameter.
				</t>

				<figure>
					<preamble>
						Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware client
						<xref target="CONDSTORE"/> 
						needs to issue separate commands to learn of flag changes
						and expunged messages since the last synchronization:
					</preamble>
					<artwork>
C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345)
S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
    $AutoJunk $MDNSent))
S: s100 OK FETCH completed
C: s101 UID SEARCH 300:500
S: * SEARCH 404 406 407 408 410 412
S: s101 OK search completed
					</artwork>
					<postamble>
						Where 300 and 500 are the lowest and highest UIDs from client's 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
						changed since the specified modification sequence.
					</postamble>	
				</figure>

				<figure>
					<preamble>
						Using the VANISHED UID FETCH modifier, it is sufficient to issue
						only a single command:
					</preamble>
					<artwork>
C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345
    VANISHED)
S: * VANISHED (EARLIER) 300:310,405,411
S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
    $AutoJunk $MDNSent))
S: s100 OK FETCH completed
					</artwork>
					<postamble>
					</postamble>
				</figure>
			</section>

			<section title="EXPUNGE Command">
				<t>
				<list style="hanging" hangIndent="11">
					<t hangText="Arguments:">none</t>
					<t hangText="Responses:">
						untagged responses: EXPUNGE or VANISHED
					</t>
				</list>
				<list style="hanging" hangIndent="8">
					<t hangText="Result:">
				        OK - expunge completed<vspace/>
					NO - expunge failure: can't
					expunge (e.g., permission denied)<vspace/>
					BAD - command unknown or arguments invalid</t>
				</list>
				</t>

				<t>
			    This section updates the definition of the EXPUNGE command described in
			    Section 6.4.3 of <xref target="RFC3501"/>.
				</t>
   
				<t>
				The EXPUNGE command permanently removes all messages that have the
				\Deleted flag set from the currently selected mailbox.  Before
				returning an OK to the client, those messages that are removed
				are reported using a VANISHED response or EXPUNGE responses.
				</t>
   
<?rfc needLines="5"?>
				<t>
			    If the server is capable of storing modification sequences for the
			    selected mailbox, it MUST increment the per-mailbox mod-sequence if at
			    least one message was permanently removed due to the execution of
			    the EXPUNGE command. For each permanently removed message, the
			    server MUST remember the incremented mod-sequence and corresponding
			    UID. If at least one message got expunged, the server MUST send the
			    updated per-mailbox modification sequence using the HIGHESTMODSEQ
			    response code (defined in <xref target="CONDSTORE"/>) in the tagged
				OK response.
				</t>

				<figure>
					<preamble>
					</preamble>
					<artwork>
   Example:    C: A202 EXPUNGE
               S: * 3 EXPUNGE
               S: * 3 EXPUNGE
               S: * 5 EXPUNGE
               S: * 8 EXPUNGE
               S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged
					</artwork>
					<postamble>
						Note: In this example, messages 3, 4, 7, and 11 had the
						\Deleted flag set.  The first "* 3 EXPUNGE" reports message
						# 3 as expunged. The 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 <xref target="RFC3501"/> for further explanation.
					</postamble>
				</figure>
      
				<figure>
					<preamble>
						Note that if the server chooses to always send VANISHED responses
						instead of EXPUNGE responses,
						the previous example might look like this:
					</preamble>
					<artwork>
   Example:    C: B202 EXPUNGE
               S: * VANISHED 405,407,410,425
               S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged
					</artwork>
					<postamble>
					Here messages with message numbers 3, 4, 7, and 11
					have respective UIDs 405, 407, 410, and 425.
					</postamble>
				</figure>
				
			</section>

			<section title="CLOSE Command">
				<t>
				<list style="hanging" hangIndent="11">
					<t hangText="Arguments:">none</t>
					<t hangText="Responses:">
						no specific responses for this command
					</t>
				</list>
				<list style="hanging" hangIndent="8">
					<t hangText="Result:">
				        OK - close completed, now in authenticated state<vspace/>
					BAD - command unknown or arguments invalid</t>
				</list>
				</t>
   
				<t>
				This section updates the definition of the CLOSE command described in
				Section 6.4.2 of <xref target="RFC3501"/>.
				</t>
   
				<t>
				The CLOSE command permanently removes all messages that have the
				\Deleted flag set from the currently selected mailbox, and returns
				to the authenticated state from the selected state.  No untagged
				EXPUNGE (or VANISHED) responses are sent.
				</t>

				<t>
				If the server is capable of storing modification sequences for the
				selected mailbox, it MUST increment the per-mailbox mod-sequence if at
				least one message was permanently removed due to the execution of
				the CLOSE command. For each permanently removed message, the server
				MUST remember the incremented mod-sequence and corresponding UID.
				
				The server MUST NOT send the updated per-mailbox modification sequence
				using the HIGHESTMODSEQ response code (defined in <xref target="CONDSTORE"/>)
				in the tagged OK response, as this might cause loss of synchronization
				on the client.
				</t>

				<figure>
					<preamble>
					</preamble>
					<artwork>
   Example:    C: A202 CLOSE
               S: A202 OK done
					</artwork>
					<postamble>
					</postamble>
				</figure>
      
			</section>

			<section title="UID EXPUNGE Command">
				<t>
				<list style="hanging" hangIndent="11">
						<t hangText="Arguments:">message set</t>
						<t hangText="Responses:">
							untagged responses: EXPUNGE or VANISHED
						</t>
					</list>
				<list style="hanging" hangIndent="8">
						<t hangText="Result:">
							OK - expunge completed<vspace/>
							NO - expunge failure: can't expunge (e.g., permission denied)<vspace/>
							BAD - command unknown or arguments invalid
						</t>
					</list>
				</t>
				
				<t>
				This section updates the definition of the UID EXPUNGE command described in
				Section 2.1 of <xref target="UIDPLUS"/>. Servers that implement both
				<xref target="UIDPLUS"/> and QRESYNC extensions must
				implement UID EXPUNGE as described in this section.
				</t>
				
				<t>
					The UID EXPUNGE command permanently removes from the currently 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
					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.
				</t>

				<t>
				This command is particularly useful for disconnected mode clients.
				By using UID EXPUNGE instead of EXPUNGE when resynchronizing with
				the server, the client can avoid inadvertently
				removing any messages that have been marked as \Deleted by other
				clients between the time that the client was last connected and
				the time the client resynchronizes.
				</t>


			<!--Chris thought that it would be better to remove this:
				<t>
				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.
				</t>
				
				<t>
				Alternatively, the client MAY fall back to using just the EXPUNGE
				command, risking the unintended removal of some messages.
				</t>
			-->

				<t>
				Before returning an OK to the client, those messages that are removed
				are reported using a VANISHED response or EXPUNGE responses. 
				</t>

				<t>
				If the server is capable of storing modification sequences for the
				selected mailbox, it MUST increment the per-mailbox mod-sequence if at
				least one message was permanently removed due to the execution of
				the UID EXPUNGE command. For each permanently removed message, the
				server MUST remember the incremented mod-sequence and corresponding
				UID. If at least one message got expunged, the server MUST send the
				updated per-mailbox modification sequence using the HIGHESTMODSEQ
				response code (defined in <xref target="CONDSTORE"/>) in the tagged
				OK response.
				</t>
				
				<figure>
					<preamble>
					</preamble>
					<artwork>
Example:    C: . UID EXPUNGE 3000:3002
            S: * 3 EXPUNGE
            S: * 3 EXPUNGE
            S: * 3 EXPUNGE
            S: . OK [HIGHESTMODSEQ 20010715194045319] Ok
					</artwork>
					<postamble>
						Note: In this example, at least messages with message
						numbers 3, 4, and 5 (UIDs 3000 to 3002) had the
						\Deleted flag set.  The first "* 3 EXPUNGE" reports message
						# 3 as expunged. The 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 <xref target="RFC3501"/> for further explanation.
					</postamble>
				</figure>

			</section>

			<section title="VANISHED Response" anchor="expunged-resp">
				<t>
					<list style="hanging" hangIndent="11">
						<t hangText="Contents:">an optional EARLIER tag</t>
						<t hangText="">list of UIDs</t>
					</list>
				</t>
				
				<t>
				The VANISHED response reports that the specified UIDs have been
				permanently removed from the mailbox. This response is similar to
				the EXPUNGE response <xref target="RFC3501"/>; however, it can return information
				about multiple messages, and it returns UIDs instead of message
				numbers. The first benefit saves bandwidth, while the second is
				more convenient for clients that only use UIDs to access the IMAP
				server.
				</t>

				<t>The VANISHED response has the same restrictions on when it can
				be sent as does the EXPUNGE response (see below).</t>

				<t>
				The VANISHED response has two forms. The first form contains
				the EARLIER tag, which signifies that the response was caused by
				a UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command.
				This 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. When the client sees a VANISHED EARLIER
				response, it MUST NOT decrement message sequence numbers for each
				successive message in the mailbox.
				</t>

				<t>
				The second form doesn't contain the EARLIER tag and is described below.
				Once a client has issued "ENABLE QRESYNC" (and the server has positively
				responded to that command with the untagged ENABLED response containing
				QRESYNC), the server SHOULD use the VANISHED response without
				the EARLIER tag instead of the EXPUNGE response.
				The server SHOULD continue using VANISHED in lieu of EXPUNGE
				for the duration of the connection. In particular,
				this affects the EXPUNGE <xref target="RFC3501"/> and
				UID EXPUNGE <xref target="UIDPLUS"/>
				commands, as well as messages expunged in other connections.
				Such a VANISHED response MUST NOT contain the EARLIER tag.
				</t>

				<t>
        A VANISHED response sent because of an EXPUNGE or UID EXPUNGE
        command or because messages were expunged
        in other connections (i.e., the VANISHED response without the EARLIER
        tag) also decrements the number of messages
        in the mailbox; it is not necessary for the server to send an
        EXISTS response with the new value. It also
        decrements message sequence numbers for each successive message in
        the mailbox (see the example at the end of this section).
				</t>

				<t>
        Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or messages
        expunged in other connections MUST only contain UIDs for messages
        expunged since the last VANISHED/EXPUNGE response sent for the currently
        opened mailbox or since the mailbox was opened. That is, servers
        MUST NOT send UIDs for previously expunged messages, unless
        explicitly requested to do so by the UID FETCH (VANISHED) command.
        This is required to prevent a possible race condition where new arrivals
        for which the UID is not yet known by the client are expunged.
        </t>

				<t>
				Note that client implementors must take care to properly decrement
				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 UID set. 
In general, this means that a client
				using this extension should either avoid using message numbers
				entirely, or have a complete mapping of UIDs to message sequence numbers
				for the selected mailbox.
				</t>

				<t>
				Because clients handle the two different forms of the VANISHED response
				differently, servers MUST NOT report UIDs resulting from a
				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.
				</t>

				<t>
				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 is necessary to prevent a loss of
				synchronization of message sequence numbers between client and
				server.  A command is not "in progress" until the complete command
				has been received; in particular, a command is not "in progress"
				during the negotiation of command continuation.
				</t>

				<t>
				Note: UID FETCH, UID STORE, and UID SEARCH are different
				commands from FETCH, STORE, and SEARCH.  A VANISHED
				response MAY be sent during a UID command.
				However, the VANISHED response MUST NOT be sent during a UID SEARCH
				command that contains message numbers in the search criteria.
				</t>

				<t>
				The update from the VANISHED response MUST be recorded by the
				client.
				</t>

				<figure>
					<preamble>
						Example: Let's assume that there is the following mapping between
						message numbers and UIDs in the currently selected mailbox (here
						"X" marks messages with the \Deleted flag set, and "x" represents
						UIDs which are not relevant for the example):
					</preamble>
					<artwork>
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
\Deleted messages:           X    X           X            X
					</artwork>
					<postamble>
					</postamble>
				</figure>

				<figure>
					<preamble>
						In the presence of the extension defined in this document:
					</preamble>
					<artwork>
C: A202 EXPUNGE
S: * VANISHED 505,507,510,625
S: A202 OK EXPUNGE completed
					</artwork>
					<postamble>
					</postamble>
				</figure>

				<figure>
					<preamble>
						Without the QRESYNC extension,
						the same example might look like:
					</preamble>
					<artwork>
C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed
					</artwork>
					<postamble>
					</postamble>
				</figure>
				
				<figure>
					<preamble>
						(Continuing previous example) If subsequently messages with UIDs 504 and
						508 got marked as \Deleted:
					</preamble>
					<artwork>
C: A210 EXPUNGE
S: * VANISHED 504,508
S: A210 OK EXPUNGE completed
					</artwork>
					<postamble>
						i.e., the last VANISHED response only contains UIDs of messages
						expunged since the previous VANISHED response.
					</postamble>
				</figure>
			</section>

			<section title="CLOSED Response Code" anchor="closed-resp-code">				
				<t>
				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.
				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 that was closed, and all subsequent
				responses relate to the newly opened mailbox.
				</t>
				
				<t>There is no need to return the CLOSED response code
				on completion of the CLOSE or the UNSELECT <xref target="UNSELECT"/> command
				(or similar) whose purpose is to close
				the currently selected mailbox without opening a new one.
				</t>
			</section>


		</section>
			
		<section title="Server Implementation Considerations">
			<t>
			This section describes a minimalist implementation, a moderate implementation, and an example of a full
			implementation.
			</t>

			<section title="Server Implementations That Don't Store Extra State">
				<t>
				Strictly speaking, a server implementation that doesn't remember
				mod-sequences associated with expunged messages can be considered
				compliant with this specification. Such implementations return
				all expunged messages specified in the UID set of the UID FETCH
				(VANISHED) command every time, without paying attention
				to the specified CHANGEDSINCE mod-sequence. Such implementations
				are discouraged, as they can end up returning VANISHED responses
				that are bigger than the result of a UID SEARCH command for the same UID set.
				</t>
				<t>
				Clients that use the message sequence match data can reduce the
				scope of this VANISHED response substantially in the typical
				case where expunges have not happened, or happen only toward the
				end of the mailbox.
				</t>
			</section>
			
			<section title="Server Implementations Storing Minimal State">
			        <t>
				A server that stores the HIGHESTMODSEQ value at the time of the last EXPUNGE
				can omit the VANISHED response when a client provides a MODSEQ value that is equal
				to, or higher than, the current value of this datum, that is, when there have been no
				EXPUNGEs.
				</t>
				<t>A client providing message sequence match data can reduce the scope as above. In
				the case where there have been no expunges, the server can ignore this data.</t>
			</section>
			
			<section title="Additional State Required on the Server">
				<t>
				When compared to the <xref target="CONDSTORE"/> extension,
				this extension requires servers to store additional state
				associated with expunged messages. Note that implementations
				are not required to store this state in persistent storage;
				however, use of persistent storage is advisable.
				</t>

				<t>
				One possible way to correctly implement the extension described
				in this document is to store a queue of &lt;UID set,
				mod-sequence&gt; pairs. &lt;UID set&gt; can be represented
				as a sequence of &lt;min UID, max UID&gt; pairs.
				</t>

				<t>
				When messages are expunged, one or more entries are added to
				the queue tail.
				</t>
				
<?rfc needLines="5"?>
				<t>
				When the server receives a request to
				return messages expunged since a given mod-sequence, it will search the queue from the tail
				(i.e., going from the highest expunged mod-sequence to the lowest)
				until it sees the first record with a mod-sequence less than or equal
				to the given mod-sequence or it reaches the head of the queue.
				</t>

				<t>
				Note that indefinitely storing information about expunged messages
				can cause storage and related problems for an implementation.
				In the worst case, this could result in almost 64Gb of storage
				for each IMAP mailbox.  For example, consider an implementation
				that stores &lt;min UID, max UID, mod-sequence&gt; triples
				for each range of messages expunged at the same time.
				Each triple requires 16 octets: 4 octets for each of the two UIDs,
				and 8 octets for the mod-sequence.
				Assume that there is a mailbox containing a single message with a UID of 2**32-1
				(the maximum possible UID value), where messages had previously
				existed with UIDs starting at 1, and have been expunged one at a time.
				For this mailbox alone, storage is required for the triples
				&lt;1, 1, modseq1&gt;, &lt;2, 2, modseq2&gt;, ...,
				&lt;2**32-2, 2**32-2, modseq4294967294&gt;.
</t>				
				
				<t>
				Hence, implementations are encouraged to adopt strategies to protect
				against such storage problems, such as limiting the size of the queue
				used to store mod-sequences for expunged messages and
				"expiring" older records when this limit is reached. When the selected
				implementation-specific queue limit is reached, the oldest record(s)
				are deleted from the queue (note that such records
				are located at the queue head). For all such "expired"
				records, the server needs to store a single mod-sequence, which is the
				highest mod-sequence for all "expired" expunged messages.
				</t>
				
				<t>Note that if the client provides the message sequence match data,
				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 unable to persist much of this queue. If the queue contains data back to the requested mod-sequence, this data can be ignored.</t>
				
				<t>
				Also, note that if the UIDVALIDITY of the mailbox changes or if the mailbox
				is deleted, then any state associated with expunged messages doesn't need
				to be preserved and SHOULD be deleted.
				</t>
				
			</section>
		</section>

		<section title="Updated Synchronization Sequence">
			<t>
			This section updates the description of optimized synchronization
			in Section 6.1 of the <xref target="IMAP-DISC"/>.
			</t>

			<t>
			An advanced disconnected mail client should use the QRESYNC
			and
			<xref target="CONDSTORE"/> extensions when they are supported by the server. The
			client uses the value from the HIGHESTMODSEQ OK response code received
			on mailbox opening to determine if it needs to resynchronize. Once
			the synchronization is complete, it MUST cache the received value
			(unless the mailbox UIDVALIDITY value has changed; see below).
			The client MUST update its copy of the HIGHESTMODSEQ value whenever the server
			sends a subsequent HIGHESTMODSEQ OK response code.
			</t>

			<t>
      After completing a full synchronization, the client MUST also take
      note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ
      response codes received from the server.  Whenever the client receives
      a tagged response to a command, it checks the received unsolicited
      responses to calculate the new HIGHESTMODSEQ value.  If the
      HIGHESTMODSEQ response code is received, the client MUST use it even
      if it has seen higher mod-sequences.  Otherwise, the client calculates
      the highest value among all MODSEQ FETCH data items received since the
      last tagged response.  If 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.
			</t>

      <figure>
        <preamble>
          Example:
        </preamble>
        <artwork>
C: A150 STORE 1:2 (UNCHANGEDSINCE 96) +FLAGS.SILENT \Seen
S: * 1 FETCH (UID 6 MODSEQ (103))
S: * 2 FETCH (UID 7 MODSEQ (101))
S: * OK [HIGHESTMODSEQ 99] VANISHED reply with MODSEQ 100 is delayed
S: A150 OK [MODIFIED 3] done

C: A151 STORE 3 +FLAGS.SILENT \Seen
S: * 3 FETCH (UID 8 MODSEQ (104))
S: A151 OK [HIGHESTMODSEQ 99] Still delaying VANISHED

C: A152 NOOP
S: * VANISHED 8
S: A153 OK [HIGHESTMODSEQ 104] done
        </artwork>
        <postamble>
        </postamble>
      </figure>

      <t>
      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 because servers
      are not required to send MODSEQ FETCH data items in increasing modseqence order.
      Some commands may also delay EXPUNGE (or VANISHED) replies with smaller mod-sequences.
      These can lead to the client missing some changes in case of connectivity loss.
			</t>

			<t>
			When opening the mailbox for synchronization, the client uses the QRESYNC
			parameter to the SELECT/EXAMINE command. The QRESYNC parameter is followed
			by the UIDVALIDITY and mailbox HIGHESTMODSEQ 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 synchronization of the mailbox. The client
			may also transmit a list containing its knowledge of message numbers.</t>
			
			<t>If the SELECT/EXAMINE command is successful, the client
			compares UIDVALIDITY as described in step d)1) in Section 3 of the
			<xref target="IMAP-DISC"/>. If the cached UIDVALIDITY value matches the one 
			returned by the server and the server also returns the HIGHESTMODSEQ response code,
			then the server reports expunged messages and returns 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 the UID set parameter). At this point, the client
			is synchronized, except for maybe the new messages.
			</t>

			<t>
			If upon a successful SELECT/EXAMINE (QRESYNC) command the client receives
			a NOMODSEQ OK untagged response (instead of the HIGHESTMODSEQ response code),
			it MUST remove the last known HIGHESTMODSEQ value 
			from its cache and follow the more general instructions in Section 3 of 
			the <xref target="IMAP-DISC"/>.
			</t>

			<t>
			At this point, the client is in sync with the server regarding old messages.
			This client can now fetch information about new messages (if requested by the user).
			</t>

			<t>
			Step d) ("Server-to-client synchronization") in Section 4 of the
			<xref target="IMAP-DISC"/> in the presence of the QRESYNC &amp; CONDSTORE extensions
			is amended as follows:
			</t>

		<t>
		<list style="hanging" hangIndent="3">
			<t hangText="d)">
			"Server-to-client synchronization" -- for each mailbox
			that requires synchronization, do the following:
			</t>
		</list>
		</t>

			<t>
			<list style="hanging" hangIndent="4">
				<t hangText="1a)">
					Check the mailbox UIDVALIDITY (see Section 4.1 of the
					<xref target="IMAP-DISC"/> for more details) after
					issuing SELECT/EXAMINE
					(QRESYNC) command. 

					<vspace blankLines="1"/>

					If the UIDVALIDITY value returned by the server differs, the client MUST

					<list style="symbols">
						<t>empty the local cache of that mailbox;</t>
						<t>"forget" the cached HIGHESTMODSEQ value for
						the mailbox;</t>
						<t>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 <xref target="IMAP-DISC"/>);</t>
					</list>
				</t>

				<t hangText="2)">
				  Fetch the current "descriptors";
					
                                  <list style="hanging" hangIndent="3">
				    <t hangText="I)">
				      Discover new messages.
				    </t>
				  </list>
				</t>

				<t hangText="3)">
				  Fetch the bodies of any "interesting" messages that the
				  client doesn't already have.
				</t>
			</list>
			</t>
				<t>
				  <list style="hanging" hangIndent="9">
				    <t hangText="Example:">
				The UIDVALIDITY value is the same, but the
				HIGHESTMODSEQ value has changed on the server while
				the client was offline:
				    </t>
				  </list>
				</t>
				<t>
					<figure>
						<preamble>
						</preamble>
						<artwork>
 C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198))
 S: * 172 EXISTS
 S: * 1 RECENT
 S: * OK [UNSEEN 12] Message 12 is first unseen
 S: * OK [UIDVALIDITY 3857529045] UIDs valid
 S: * OK [UIDNEXT 201] Predicted next UID
 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
 S: * OK [HIGHESTMODSEQ 20010715194045007] Highest
       mailbox mod-sequence
 S: * VANISHED (EARLIER) 1:5,7:8,10:15
 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000)
     FLAGS (\Deleted))
 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000)
     FLAGS ($NoJunk $AutoJunk $MDNSent))
    ...
 S: A142 OK [READ-WRITE] SELECT completed
						</artwork>
						<postamble>
						</postamble>
					</figure>
					</t>

		</section>

		<section title="Formal Syntax">
			<t>
			The following syntax specification uses the Augmented Backus-Naur 
			Form (ABNF) notation as specified in <xref target="ABNF"/>.
			</t>
			<t>
			Non-terminals referenced but not defined below are as defined by 
			<xref target="RFC3501"/>, <xref target="CONDSTORE"/>, or <xref target="IMAPABNF"/>.
			</t>
			<t>
			Except as noted otherwise, all alphabetic characters are case-insensitive.  
			The use of upper or lower case characters to define token strings is for 
			editorial clarity only.  Implementations MUST accept these strings in a 
			case-insensitive fashion.
			</t>
<figure>
<artwork>
   capability          =/ "QRESYNC"
		       
   select-param        =  "QRESYNC" SP "(" uidvalidity SP
                       mod-sequence-value [SP known-uids]
                       [SP seq-match-data] ")"
                       ;; conforms to the generic select-param
                       ;; syntax defined in [IMAPABNF]
		       
   seq-match-data      =  "(" known-sequence-set SP known-uid-set ")"
		       
   uidvalidity         =  nz-number
		       
   known-uids          =  sequence-set
                       ;; sequence of UIDs, "*" is not allowed
		       
   known-sequence-set  =  sequence-set
                       ;; set of message numbers corresponding to
                       ;; the UIDs in known-uid-set, in ascending order.
                       ;; * is not allowed.
		       
   known-uid-set       =  sequence-set
                       ;; set of UIDs corresponding to the messages in
                       ;; known-sequence-set, in ascending order.
                       ;; * is not allowed.

   message-data        =/ expunged-resp

   expunged-resp       =  "VANISHED" [SP "(EARLIER)"] SP known-uids

   rexpunges-fetch-mod =  "VANISHED"
                       ;; VANISHED UID FETCH modifier conforms
                       ;; to the fetch-modifier syntax
                       ;; defined in [IMAPABNF].  It is only
                       ;; allowed in the UID FETCH command.

   resp-text-code      =/ "CLOSED"
</artwork>
</figure>

		</section>
		<section title="Security Considerations">
			<t>
			As always, it is important to thoroughly test clients and servers
			implementing this extension, as it changes how the server reports
			expunged messages to the client.
			</t>

			<t>Security considerations relevant to <xref target="CONDSTORE"/>
			   are relevant to this extension.</t>

			<t>This document doesn't raise any new security concerns not already raised by <xref target="CONDSTORE"/> or <xref target="RFC3501"/>.</t>
		</section>
		
		<section title="IANA Considerations">
		    <t>
		    IMAP4 capabilities are registered by publishing a standards track or
		    IESG approved experimental RFC.  The registry is currently located
		    at:
		    </t>

<figure>
    <artwork>
   http://www.iana.org/assignments/imap4-capabilities
    </artwork>
</figure>

		    <t>
		    This document defines the QRESYNC IMAP capability.
		    IANA has added this capability to the registry.
		    </t>
		</section>

		<section title="Acknowledgments">
			<t>
			Thanks to Steve Hole, Cyrus Daboo, and Michael Wener
			for encouraging creation of this document.
			</t>

			<t>
			Valuable comments, both in agreement and in dissent, were received from
			Timo Sirainen, Michael Wener, Randall Gellens,
			Arnt Gulbrandsen, Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies,
			Dan Karp, Eric Rescorla, Mike Zraly and Alfred Hoenes.
			</t>

			<t>
			This document takes substantial text from <xref target="RFC3501"/> by Mark Crispin.
			</t>
		</section>
	</middle>
	<back>
		<references title="Normative References">

			<reference anchor="RFC2119">

<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
<format type="HTML" octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
			</reference>
			
			<reference anchor="RFC3501">
<front>
<title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title>
<author initials="M." surname="Crispin" fullname="M. Crispin">
<organization/></author>
<date year="2003" month="March"/>
<abstract>
<t>The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server.  IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders.  IMAP4rev1 also provides the capability for an offline client to resynchronize with the server.  IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof.  Messages in IMAP4rev1 are accessed by the use of numbers.  These numbers are either message sequence numbers or unique identifiers.  IMAP4rev1 supports a single server.  A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244.  IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name="RFC" value="3501"/>
<format type="TXT" octets="227640" target="ftp://ftp.isi.edu/in-notes/rfc3501.txt"/>
			</reference>
			
			<reference anchor="ABNF">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="D." surname="Crocker" fullname="D. Crocker">
<organization/></author>
<author initials="P." surname="Overell" fullname="P. Overell">
<organization/></author>
<date year="2008" month="January"/>
<abstract>
<t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF.  It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name="STD" value="68"/>

<seriesInfo name="RFC" value="5234"/>
<format type="TXT" octets="26359" target="ftp://ftp.isi.edu/in-notes/rfc5234.txt"/>
			</reference>


			<reference anchor="IMAPABNF">
				<front>
					<title>Collected Extensions to IMAP4 ABNF</title>
					<author initials="A" surname="Melnikov">
						<organization>Isode Ltd.</organization>
					</author>
					<author initials="C" surname="Daboo">
						<organization/>
					</author>
					<date year="2006" month="April"/>
				</front>
				<seriesInfo name="RFC" value="4466"/>
				<format type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc4466.txt"/>
			</reference>
			<reference anchor="CONDSTORE">
				<front>
					<title>IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization
					</title>
					<author initials="A" surname="Melnikov">
						<organization>Isode Ltd.</organization>
					</author>
					<author initials="S" surname="Hole">
						<organization>ACI WorldWide/MessagingDirect</organization>
					</author>
					<date year="2006" month="June"/>
				</front>
				<seriesInfo name="RFC" value="4551"/>
				<format type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc4551.txt"/>
			</reference>
			<reference anchor="UIDPLUS">
				<front>
					<title>Internet Message Access Protocol (IMAP) - UIDPLUS extension</title>
					<author initials="M" surname="Crispin">
						<organization>University of Washigton</organization>
					</author>
					<date year="2005" month="December"/>
				</front>
				<seriesInfo name="RFC" value="4315"/>
				<format type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc4315.txt"/>
			</reference>
			<reference anchor="ENABLE">
				<front>
					<title>The IMAP ENABLE Extension</title>
					<author initials="A" surname="Gulbrandsen" role="editor">
						<organization>Oryx Mail Systems GmbH</organization>
					</author>
                                        <author initials="A" surname="Melnikov" role="editor">
                                                <organization>Isode Limited</organization>
                                        </author>

					<date year="2008" month="March"/>
				</front>
				<seriesInfo name="RFC" value="5161"/>
							</reference>
		</references>
		<references title="Informative References">
			<reference anchor="RFC-2180">
				<front>
					<title>IMAP4 Multi-Accessed Mailbox Practice
					</title>
					<author initials="M" surname="Gahrns" role="editor">
						<organization/>
					</author>
					<date year="1997" month="July"/>
				</front>
				<seriesInfo name="RFC" value="2180"/>
				<format type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2180.txt"/>
			</reference>
			
			<reference anchor="IMAP-DISC">
				<front>
					<title>Synchronization Operations For Disconnected Imap4 Clients
					</title>
					<author initials="A" surname="Melnikov" role="editor">
						<organization>Isode Ltd.</organization>
					</author>
					<date year="2006" month="June"/>
				</front>
				<seriesInfo name="RFC" value="4549"/>
				<format type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc4549.txt"/>
			</reference>
			<reference anchor="UNSELECT">
				<front>
					<title>
						Internet Message Access Protocol (IMAP) UNSELECT command
					</title>
					<author initials="A" surname="Melnikov">
						<organization>Isode Ltd.</organization>
					</author>
					<date year="2004" month="February"/>
				</front>
				<seriesInfo name="RFC" value="3691"/>
				<format type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3691.txt"/>
			</reference>
			
			<reference anchor="ACL">
				<front>
					<title>
						IMAP4 Access Control List (ACL) Extension
					</title>
					<author initials="A" surname="Melnikov">
						<organization>Isode Ltd.</organization>
					</author>
					<date year="2005" month="December"/>
				</front>
				<seriesInfo name="RFC" value="4314"/>
				<format type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc4314.txt"/>
			</reference>

			<reference anchor="NTP">
				<front>
					<title>
						Network Time Protocol (Version 3) Specification, Implementation and Analysis
					</title>
					<author initials="D" surname="Mills">
						<organization/>
					</author>
					<date year="1992" month="March"/>
				</front>
				<seriesInfo name="RFC" value="1305"/>
				<format type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc1305.txt"/>
			</reference>
			
		</references>

    <section title="Changes since RFC 5162">

      <t>
      Addressed erratum #1365: http://www.rfc-editor.org/errata_search.php?eid=1365  
      </t>

      <t>
      Addressed erratum #1807: http://www.rfc-editor.org/errata_search.php?eid=1807
      </t>
      
      <t>
      Addressed erratum #1808: http://www.rfc-editor.org/errata_search.php?eid=1808
      </t>

      <t>
      Addressed erratum #1809: http://www.rfc-editor.org/errata_search.php?eid=1809
      </t>

      <t>
      Addressed erratum #3322: http://www.rfc-editor.org/errata_search.php?eid=3322
      </t>

      <t>Fixed some examples to report data that match requirements specified in the document.</t>

    </section>


  </back>
</rfc>