Contexts for IMAP4
updated by
Extracted elements (27)
The extension borrows the windowed-view and bandwidth-efficient update concepts from ACAP (RFC 2244), adapting them to IMAP's existing SEARCH and SORT command model rather than requiring a separate protocol facility.
Unlike ACAP, there is no requirement that a context be created with CONTEXT before using UPDATE, and no snapshot facility exists; UPDATE always reflects the current live state of the mailbox.
UPDATE notifies about all changes to the full matching set regardless of other return options (e.g., MIN, MAX, PARTIAL); this simplifies the server contract at the cost of clients potentially receiving notifications for messages outside their current window of interest.
ESEARCH responses carrying ADDTO and/or REMOVEFROM MAY be sent at any time — when no command is in progress, during command processing, or while the client uses IDLE — consistent with the general IMAP rule that unsolicited responses may arrive at any time (except EXPUNGE).
Servers advertising CONTEXT=SORT MUST also advertise the SORT capability as described in RFC 5256; CONTEXT=SORT implies full SORT support.
A REMOVEFROM containing message sequence numbers removed as a result of expunge MUST be sent prior to the EXPUNGE notification itself, so that those sequence numbers remain valid during client processing.
A server advertising CONTEXT=SEARCH orders all SEARCH results — from both UID SEARCH and SEARCH commands — in mailbox order (by message number and UID).
A single command MUST NOT contain more than one PARTIAL or ALL search return option; exactly one of PARTIAL, ALL, or neither is allowed per command.
ADDTO and REMOVEFROM data items SHOULD be delivered to clients in a timely manner as and when results change, typically co-delivered with the causal FETCH, EXISTS, or EXPUNGE response.
An ADDTO containing message sequence numbers added as a result of message delivery or APPEND MUST be sent after the EXISTS notification, so that those sequence numbers are valid when processed by the client.
Any ranges given by the server in an ESEARCH response from an extended SORT or UID SORT command MUST be ordered in increasing numerical order after expansion.
Clients MUST NOT reuse IMAP command tags when UPDATE is active; an attempt to reuse a tag already in use by an active UPDATE-bearing searching command SHALL result in a BAD response.
Servers MAY cache SEARCH or SORT results for efficiency, but MUST behave identically whether or not internal caching is taking place; any such cache must be kept consistent with mailbox changes.
Servers MUST provide at least one updating context per client, and SHOULD provide more; refusal to provide updates for a SORT command via NOUPDATE does not imply SEARCH contexts will also be refused.
Servers SHOULD present ranges only when the first seq-number is lower than the second; the form 12:10 SHOULD be avoided.
The client MUST process ADDTO and REMOVEFROM return data items in the order they appear, including those within a single ESEARCH response; correspondingly, servers MUST generate them such that results are maintained in the requested order.
The CONTEXT return option SHOULD be used by a client to hint that subsequent use of the search criteria are likely; servers MAY ignore it or use it to maintain a full result cache or index.
The CANCELUPDATE command takes one or more command tags as arguments and instructs the server to cease sending updates for those contexts; the server MAY free resources associated with them, but the client may still issue further PARTIAL requests for the same criteria.
The CONTEXT=SEARCH and CONTEXT=SORT capabilities each add three return options to extended SEARCH/SORT: CONTEXT (a caching hint), UPDATE (live change notifications), and PARTIAL (windowed result access).
The ESORT capability extends SORT and UID SORT commands to accept return options (MIN, MAX, ALL, COUNT) identical to those of ESEARCH, returning results in an ESEARCH response in the requested sort order.
The PARTIAL return option takes a mandatory nz-number:nz-number range argument (first result = 1) and causes the server to return only that window of results in a PARTIAL return data item; if the range extends beyond available results, the server returns only the results that exist, and NIL if there are none.
When a server refuses to honor an UPDATE request (e.g., internal limit reached), it emits an untagged NO with response-code NOUPDATE containing the tag of the refused searching command; other return options in that command SHALL still be honored.
This document defines three new IMAP4 capabilities — ESORT, CONTEXT=SEARCH, and CONTEXT=SORT — and directs IANA to add them to the IMAP capabilities registry.
Creation of a large number of contexts by authorized users may enable denial-of-service attacks; implementors should mitigate this by limiting context count via the NOUPDATE mechanism, applying the strategies in Appendix B, and logging context creation for administrative review.
The ADDTO return data item carries a parenthesized list of (context-position, sequence-set) pairs; context-position is a number (0 for unsorted SEARCH insertion), and each pair inserts the sequence-set starting at that position, shifting existing entries later.
The PARTIAL return data item encodes as: PARTIAL SP "(" partial-range SP partial-results ")", where partial-range is nz-number ":" nz-number and partial-results is a sequence-set or NIL.
The REMOVEFROM return data item carries a parenthesized list of (context-position, sequence-set) pairs; each pair removes the specified messages starting at the given context position, shifting later entries earlier.