| Internet Engineering Task Force | J. Kundrat |
| Internet-Draft | August 18, 2012 |
| Intended status: Standards Track | |
| Expires: February 17, 2013 |
IMAP QRESYNC-ARRIVED Extension
draft-kundrat-qresync-arrived-00
This document updates the QRESYNC extension of the IMAP protocol to use a new untagged response, the ARRIVED one, to inform about the UIDs of newly arriving messages. Deprecating the EXISTS response, this extension prevents a possible race condition where clients can lose synchronization of message UIDs in a selected mailbox when new arrivals are immediately expunged.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 17, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The QRESYNC extension [RFC5162] introduces the VANISHED response, a UID-based supplement to the sequence-number-based EXPUNGED [RFC3501]. The VANISHED response is also explicitly allowed to refer to non-existing message UIDs. Such a situation present a possible race condition where clients could lose track of the sequence -> UID mapping where new arrivals are removed in a parallel session.
This document updates the QRESYNC extension with a new response to be used instead of EXISTS, the ARRIVED one. It also adds a mechanism for activating this extension and explains backward compatibility concerns.
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 [RFC2119].
This section illustrates an example where a fully-compliant QRESYNC client loses track of UIDs of some messages in its mailbox.
Suppose a client has opened a mailbox using the SELECT ... QRESYNC command. The mailbox contains a single message with UID 5; UIDNEXT is 11. The client is fully synchronized with the server. In this situation, the server informs client about new arrival:
S: * 3 EXISTS
Upon receiving the EXISTS reponse, IMAP client would typically proceed towards discovering various message metadata like theirs UIDs and flags, either through the UID SEARCH ALL command, or via UID FETCH (FLAGS). However, when the new arrivals are immediately expunged (perhaps as a result of an activity in a parallel session), the server can possibly process the request for additinal metadata only after the expunge has been reported to the client. The VANISHED response actually complicates matter in this situation:
S: * VANISHED 12:20
This response informs about permanent removal of messages with UIDs between 12 and 20, inclusively. Unfortunately, as the VANISHED response is explicitly allowed to reference non-existing UIDs, the client doesn't know whether this VANISHED response affects two newly arriving messages. Immediately after having received these two responses, the client cannot make any assumptions about the rest of the mailbox (i.e. messages with UIDs > 6). Specifically, any of the following can be true:
In absence of the QRESYNC-ARRIVED extension or when talking to servers not offering that, clients MUST be prepared to work around the described race condition. An example of such a behavior is issuing an explicit UID SEARCH command to rediscover the unclear portion of the sequence -> UID mapping:
S: * 3 EXISTS S: * VANISHED 12:20 C: x UID SEARCH UID 11:* S: * SEARCH S: x OK Search completed
A single search operation is enough to recover the complete UID mapping, but it induces unnecessary round trip before a full mapping can be established again. In addition, clients would have to ignore any unsolicited FETCH responses not containing UID of the target message:
S: * 3 EXISTS S: * 2 FETCH (FLAGS (foo)) S: * 3 FETCH (FLAGS (bar)) S: * VANISHED 12:20 C: x UID SEARCH UID 11:* S: * SEARCH S: x OK Search completed
Clients have no chance but to ignore any FETCH response which affects messages whose UID is not yet known.
This race condition can be avoided by switching to UID-based equivalent of EXISTS, the ARRIVED response. Alternatively, the same goal would be achieved if the QRESYNC specification mandated that VANISHED responses MUST NOT refer to UIDs which were not present in the mailbox at the time immediately before the VANISHED response was generated.
The QRESYNC-ARRIVED parameter to SELECT/EXAMINE commands shares syntax with the QRESYNC parameter defined in [RFC5162]; the only exception is that it is identified by the "QRESYNC-ARRIVED" atom.
For backward compatibility, IMAP servers supporting this extension MUST support QRESYNC as defined by [RFC5162]. In addition, such servers SHOULD NOT sent VANISHED responses containing UIDs of messages which were expunged before, and SHOULD NOT send the untagged EXPUNGED instead of VANISHED.
Contents: ordered list of UIDs
The ARRIVED response reports that the specified UIDs have been delivered to the mailbox. It is similar in functionality to the EXISTS response [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 elliminates the potential of client losing track of assigned UIDs in a mailbox.
If the client has opened the mailbox with the QRESYNC-ARRIVED parameter to SELECT/EXAMINE command, the EXISTS response MUST be still sent during the initial mailbox synchronization, i.e. between having received the SELECT or EXAMINE command and the corresponding tagged response, as in [RFC3501]. Servers MAY send the EXISTS response several times, but they SHOULD send it only once to conserve resources. The number given in the EXISTS response MUST NOT shrink. The clients MUST treat the last occurence as the final data.
Servers MUST NOT issue ARRIVED prior to issuing a tagged OK for the SELECT/EXAMINE command to prevent uncertanities about the HIGHESTMODSEQ value. New arrivals since the last time the mailbox has been selected are reported using FETCH responses with embedded UID, as in regular QRESYNC.
After the mailbox has been selected, all further updates about new arrivals MUST use the ARRIVED response. If servers were allowed to fall back to untagged EXISTS, the possibility of race conditions would return.
UIDs sent in the ARRIVED response must be always presented in a sorted order, lowest UID first. The sequence MUST NOT contain duplicate UIDs. Servers SHOULD take advantage of the compression capabilities of the sequence-set syntax and use the range syntax if possible.
The ARRIVED response MUST NOT be sent unless the client has passed the QRESYNC-ARRIVED option to the last SELECT or EXAMINE command.
This text builds upon the QRESYNC IMAP extension [RFC5162].
IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at:
http://www.iana.org/assignments/imap4-capabilities
This document defines the QRESYNC-ARRIVED IMAP capability. IANA will be asked to add this capability to the registry.
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234].
Non-terminals referenced but not defined below are as defined by [RFC3501], [RFC5162], or [RFC5234].
capability =/ "QRESYNC-ARRIVED"
select-param =/ "QRESYNC-ARRIVED" SP "(" uidvalidity SP
mod-sequence-value [SP known-uids]
[SP seq-match-data] ")"
;; conforms to the generic select-param
;; syntax defined in [IMAPABNF]
message-data =/ arrived-resp
arrived-resp = "ARRIVED" SP sorted-sequence-set
sorted-sequence-set = sequence-set
;; sequence of UIDs, "*" is not allowed
;; UIDs must be sorted, lowest first, no duplicates
This extensions adds no functionality on top of what is already defined in the QRESYNC extension, and therefore we believe that no additional security implications have to be considered.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| [RFC5162] | Melnikov, A., Cridland, D. and C. Wilson, "IMAP4 Extensions for Quick Mailbox Resynchronization", RFC 5162, March 2008. |
| [RFC3501] | Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. |