ietf-corpus

rfc-7162

IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)

A. Melnikov, D. Cridland
date2014-05 streamIETF areaapp wgqresync statusPROPOSED STANDARD pages52 canonicalhttps://www.rfc-editor.org/rfc/rfc7162 doi10.17487/RFC7162 errataview
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience. This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162. Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683.

obsoletes

updates

Extracted elements (30)

design-rationale §1

QRESYNC extends SELECT/EXAMINE to perform full resynchronization—including expunged message discovery—in a single round trip, eliminating the need for clients (especially mobile clients subject to frequent disconnects) to hold concurrent IMAP connections or issue separate UID SEARCH commands solely for resynchronization.

email

design-rationale §3.1

RFC 4551 defined mod-sequences as unsigned 64-bit values; this document redefines them as unsigned 63-bit values to simplify implementations on platforms such as Java. The system clock cannot be used directly as a mod-sequence source because NTP adjustments could produce non-monotonic values.

email

design-rationale §3.2.5.2

The optional fourth argument to QRESYNC SELECT (sequence number/UID match data) allows clients to provide sample seq-to-UID mappings so the server can restrict the range of reported expunged messages. This is especially effective when no expunges have occurred or all expunges are toward the end of the mailbox, substantially reducing VANISHED response size.

email

interoperability-note §3.2.1

A client implementing CONDSTORE but not QRESYNC may incur an extra round trip when resynchronizing a mailbox that had messages expunged but no flag changes, because the HIGHESTMODSEQ increase causes a CHANGEDSINCE FETCH that returns no data. Clients implementing CONDSTORE are strongly encouraged to also implement QRESYNC.

email

interoperability-note §3.2.2

The presence of the QRESYNC capability implies support for CONDSTORE even if CONDSTORE is not separately advertised. 'ENABLE QRESYNC' and 'ENABLE QRESYNC CONDSTORE' are equivalent and both CONDSTORE enabling commands. Servers SHOULD advertise CONDSTORE in addition to QRESYNC for compatibility with CONDSTORE-only clients.

email

interoperability-note §4

This document updates RFC 2683's recommended IMAP command line length limit from 1000 octets to approximately 8192 octets (including quoted strings but not literals), because CONDSTORE/QRESYNC clients may send long UID sequences in extended SELECT or FETCH commands that would otherwise trigger server rejections.

email

normative-requirement §3.1.2 MUST

After a CONDSTORE enabling command is issued, the server MUST return exactly one of the HIGHESTMODSEQ or NOMODSEQ response codes in an OK untagged response for every successful SELECT/EXAMINE command, depending on whether the mailbox supports persistent mod-sequence storage.

email

normative-requirement §3.1 MUST

An IMAP server supporting CONDSTORE MUST associate a positive unsigned 63-bit mod-sequence with every message. Each STORE command on the same mailbox MUST receive a different mod-sequence value, and for any two successful STORE operations within a session on the same mailbox, the second completed operation MUST have a greater mod-sequence than the first.

email

normative-requirement §3.2 MUST

Each mailbox supporting persistent mod-sequence storage MUST increment its per-mailbox mod-sequence when messages are expunged by EXPUNGE, UID EXPUNGE, CLOSE, or MOVE, and MUST associate the incremented mod-sequence with the UIDs of the expunged messages for later QRESYNC queries.

email

normative-requirement §3.2.7 MUST

For EXPUNGE and UID EXPUNGE, when QRESYNC is enabled and at least one message was permanently removed, the server MUST send HIGHESTMODSEQ in the tagged OK response. For CLOSE, the server MUST NOT send HIGHESTMODSEQ, as doing so could cause loss of synchronization on the client.

email

normative-requirement §3.1.6 MUST

If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) command and the server returns a non-empty result, the server MUST append the highest mod-sequence for all returned messages to the end of the untagged SEARCH response.

email

normative-requirement §3.1 MUST

Once a client issues a CONDSTORE enabling command, the server MUST include mod-sequence data in all subsequent untagged FETCH responses for the duration of the connection, whether caused by a regular STORE, a conditional STORE, or an external agent.

email

normative-requirement §3.2.4 MUST

Once ENABLE QRESYNC is issued, the server MUST automatically include both UID and mod-sequence data in all subsequent untagged FETCH responses, whether caused by STORE/UID STORE, conditional STORE, a FETCH that implicitly sets \Seen, or an external agent.

email

normative-requirement §3.2.3 MUST

Servers supporting QRESYNC MUST implement and advertise the ENABLE extension. A client making use of QRESYNC MUST issue 'ENABLE QRESYNC' once authenticated. The server MUST return a tagged BAD if the QRESYNC SELECT parameter or VANISHED UID FETCH modifier is used without a prior successful ENABLE QRESYNC.

email

normative-requirement §3.2.6 MUST

The VANISHED UID FETCH modifier MUST only be used together with the CHANGEDSINCE modifier; the server MUST reject it with a tagged BAD otherwise. Any VANISHED (EARLIER) responses resulting from this modifier MUST be returned before any FETCH responses to prevent confusion about message-number-to-UID mapping.

email

normative-requirement §3.1.3 MUST

When messages fail the UNCHANGEDSINCE test, the server MUST return a MODIFIED response code listing the failed message numbers or UIDs. An untagged FETCH response including the MODSEQ data item MUST be sent for each message on which the operation succeeded, even if .SILENT was specified.

email

normative-requirement §3.2.10.2 MUST

When QRESYNC is enabled, the server MUST use VANISHED responses instead of EXPUNGE responses for all mailboxes not returning NOMODSEQ. A VANISHED response without EARLIER MUST NOT be sent during FETCH, STORE, or SEARCH commands, and MUST NOT reference UIDs not yet announced to the client.

email

protocol-element §3.1

A modification sequence (mod-sequence) is a positive unsigned 63-bit opaque value associated with every IMAP message, updated by the server whenever a metadata item (such as a flag) is modified. It enables clients to determine exactly which messages have changed since a known point in time.

email

protocol-element §3.1.4.1

The CHANGEDSINCE FETCH modifier restricts the set of returned messages to those with a mod-sequence greater than the specified value, and implicitly adds the MODSEQ message data item to the response. It is defined for use with FETCH and UID FETCH commands.

email

protocol-element §3.2.11

The CLOSED response code has no parameters and is returned when the currently selected mailbox is implicitly closed via SELECT/EXAMINE on another mailbox. Any server advertising QRESYNC or CONDSTORE MUST return it to serve as a clear boundary between responses for the old and new mailboxes.

email

protocol-element §3.1.2.1

The HIGHESTMODSEQ response code (OK [HIGHESTMODSEQ <mod-sequence-value>]) is returned during SELECT/EXAMINE when the mailbox supports persistent mod-sequence storage. Its value is the highest mod-sequence of all messages in the mailbox and is used by disconnected clients to decide whether resynchronization is necessary.

email

protocol-element §3.1.7 MUST

The HIGHESTMODSEQ STATUS data item allows a client to check the highest mod-sequence of a mailbox without selecting it. If the mailbox does not support persistent mod-sequence storage, the server MUST return 0 for this item.

email

protocol-element §3.1.4.2

The MODSEQ message data item in FETCH causes the server to return per-message mod-sequence values in responses. Once requested, the server includes MODSEQ in all subsequent unsolicited FETCH responses for CONDSTORE-aware clients, covering changes from conditional STOREs and external agents.

email

protocol-element §3.1.5

The MODSEQ search criterion matches messages whose modification sequence is equal to or greater than a specified value. Optionally, the client may specify an entry-name (e.g., '/flags/\\Seen') and entry-type ('shared', 'priv', or 'all') to narrow the scope to a particular metadata item type.

email

protocol-element §3.1.2.2 MUST

The NOMODSEQ response code is returned during SELECT/EXAMINE when the mailbox does not support persistent mod-sequence storage. A server that returned NOMODSEQ MUST reject with a tagged BAD any FETCH with CHANGEDSINCE, FETCH/SEARCH with MODSEQ, or STORE with UNCHANGEDSINCE while that mailbox remains selected.

email

protocol-element §3.2.5 MUST

The QRESYNC parameter to SELECT/EXAMINE accepts four arguments: last known UIDVALIDITY, last known modification sequence, an optional set of known UIDs, and an optional parenthesized list of known sequence ranges with corresponding UIDs for match data. If UIDVALIDITY does not match, the server MUST ignore remaining parameters and behave as if no dynamic message data changed.

email

protocol-element §3.1.3

The UNCHANGEDSINCE STORE modifier causes the server to perform the flag operation only if the mod-sequence of every affected metadata item is at most the specified value. Messages whose mod-sequence exceeds the threshold are skipped and their identifiers are collected into a MODIFIED response code returned at the end.

email

protocol-element §3.2.10

The VANISHED response reports permanently removed UIDs in two forms: VANISHED (EARLIER), caused by UID FETCH (VANISHED) or SELECT (QRESYNC) and not requiring sequence-number adjustment; and VANISHED without EARLIER, used for real-time expunge notification, which requires the client to decrement message counts. Servers MUST NOT combine the two forms.

email

registry §9

This document registers two capabilities in the IANA IMAP4 Capabilities Registry: 'CONDSTORE' for the Conditional STORE extension providing mod-sequence tracking and protected flag updates, and 'QRESYNC' for the Quick Mailbox Resynchronization extension that builds on CONDSTORE to support single-round-trip full resynchronization.

email, registry

security-consideration §8

The CONDSTORE and QRESYNC extensions allow clients to retrieve complete metadata change histories for a mailbox. Implementations must ensure that mod-sequence data is only returned to sessions authorized to access the corresponding metadata items; in particular, private metadata changes MUST NOT be reported to sessions authenticated as different users, as shown in the flag-sharing examples.

email, security