IMAP Extension for only using and returning UIDs

This document defines an extension to the Internet Message Access Protocol for eliminating use of message numbers. This extension is compatible with both IMAP4rev1 and IMAP4rev2 . The UIDONLY extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows clients to request that servers only use and return UIDs. This helps both clients and servers to reduce resource usage required for maintenance of message number to UID map. IMPLEMENTATION NOTE: this document is not yet at the state where it is implementable. Please contact document authors if you want to experiment with implementing UIDONLY.

In protocol examples, this document uses a prefix of "C: " to denote lines sent by the client to the server, and "S: " for lines sent by the server to the client. Lines prefixed with "// " are comments explaining the previous protocol line. These prefixes and comments are not part of the protocol. Lines without any of these prefixes are continuations of the previous line, and no line break is present in the protocol unless specifically mentioned. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Other capitalised words are names of IMAP commands or responses or keywords from this document.

An IMAP server advertises support for the UIDONLY extension by including the "UIDONLY" capability in the CAPABILITY response/response code. Once the UIDONLY extension is enabled , the client MUST NOT use message sequence numbers (including the special marker "*") in any arguments to IMAP commands, and the server MUST return tagged BAD response if the client uses message sequence numbers. Additionally, once the UIDONLY extension is enabled , the server MUST NOT return message sequence numbers in any response. The UIDONLY extension affects how information about new, expunged or changed messages is returned in unsolicited responses. In partucular, it affects responses to UID FETCH/UID STORE/EXPUNGE/UID EXPUNGE, as well as how unsolicited mailbox changes are announced. The following subsections describe changes introduced by this extension in more details.

As the UIDONLY extension affects how information about new, expunged or changed messages is returned in unsolicited responses, it has to be enabled by the client first using the ENABLE command.

When UIDONLY is enabled, FETCH, STORE, SEARCH, COPY and MOVE commands are prohibited and MUST result in a tagged BAD response. Clients should instead use UID FETCH, UID STORE, UID SEARCH, UID COPY or UID MOVE respectively.

When UIDONLY is enabled, all FETCH responses that would be returned by UID FETCH/UID STORE are replaced by UIDFETCH responses. Note that UIDFETCH response contains the same FETCH response data items, except the UID, which is returned differently at the beginning of a UIDFETCH response. Requesting UID FETCH data item is not an error and this is just ignored.

When UIDONLY is enabled, all EXPUNGED responses that would be returned by EXPUNGE/UID EXPUNGE are replaced by VANISHED responses, as defined in . Note that a server that implements UIDONLY extension is not required (but allowed) to also implement CONDSTORE and/or QRESYNC extensions.

The "<sequence set>" UID SEARCH criterion is prohibited (and results in tagged BAD response) once UIDONLY is enabled. Clients should use ALL or "UID <sequence set>" UID SEARCH criterion instead.

When UIDONLY is enabled, all changes to flags (and other dynamic message attributes) are returned using UIDFETCH responses, instead of FETCH responses. Similarly, all expunged messages are announced using VANISHED responses instead of EXPUNGE responses. UID MOVE/UID COPY commands SHOULD return COPYUID response code, as specified in . Use of UIDNOTSTICKY response code (see ) is not compatible with the UIDONLY extension. I.e. a server that advertises UIDONLY extension MUST NOT return UIDNOTSTICKY response code.

CONDSTORE extension is compatible with the UIDONLY extension. The MODSEQ message data item is returned in UIDFETCH responses instead of FETCH responses. QRESYNC extension is compatible with the UIDONLY extension, but once UIDONLY is enabled, the fourth SELECT QRESYNC parameter ("Message Sequence Match Data", see Section 3.2.5.2 of ) MUST NOT be used. The server MUST return a tagged BAD response if such parameter is observed once UIDONLY is enabled.

IMAP extensions might define other commands that accept message sequence numbers ("sequence-set" ABNF non terminal) Once UIDONLY is enabled, server MUST reject such commands with tagged BAD response. For example, SORT and THREAD commands are prohibited, similarly to the SEARCH command. However UID SORT and UID THREAD can be used instead.

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in . Non-terminals referenced but not defined below are as defined by IMAP4. 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.

capability =/ "UIDONLY" ;; from [RFC3501] message-data =/ uidfetch-resp uidfetch-resp = uniqueid SP "UIDFETCH" SP msg-att ;; UID msg-att is never used. It is replaced by the uniqueid ;; at the beginning of the UIDFETCH response message-data =/ expunged-resp expunged-resp = ]]>

TBD.

IMAP4 capabilities are registered by publishing a standards track or IESG approved Informational or Experimental RFC. The registry is currently located at:

IANA is requested to add definition of the UIDONLY extension to this registry with [RFCXXXX] as the reference.

Editor of this document would like to thank the following people who provided useful comments and/or participated in discussions that lead to this document, in particular: Arnt Gulbrandsen and Bron Gondwana.