Internet DRAFT - draft-ietf-extra-imap-uidonly
draft-ietf-extra-imap-uidonly
Network Working Group A. Melnikov
Internet-Draft Isode
Intended status: Standards Track A. P. Achuthan
Expires: 4 September 2023 V. Nagulakonda
A. Singh
Yahoo!
L. Alves
3 March 2023
IMAP Extension for only using and returning UIDs
draft-ietf-extra-imap-uidonly-01
Abstract
The UIDONLY extension to the Internet Message Access Protocol (RFC
3501/RFC 9051) allows clients to enable a mode in which information
about mailbox changes is returned using only UIDs. Message numbers
are not returned in responses, and can't be used in requests once
this extension is enabled. This helps both clients and servers to
reduce resource usage required for maintenance of message number to
UID map.
Status of This Memo
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 https://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 4 September 2023.
Copyright Notice
Copyright (c) 2023 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Melnikov, et al. Expires 4 September 2023 [Page 1]
Internet-Draft IMAP UIDONLY March 2023
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3
3. The UIDONLY extension . . . . . . . . . . . . . . . . . . . . 3
3.1. Enabling UIDONLY extension . . . . . . . . . . . . . . . 4
3.2. Changes to FETCH/STORE/SEARCH/COPY/MOVE . . . . . . . . . 4
3.3. Changes to UID FETCH/UID STORE . . . . . . . . . . . . . 4
3.4. Changes to EXPUNGE/UID EXPUNGE . . . . . . . . . . . . . 5
3.5. Changes to UID SEARCH . . . . . . . . . . . . . . . . . . 5
3.6. Changes to how other mailbox changes are announced . . . 5
3.7. Interaction with CONDSTORE and QRESYNC extensions . . . . 5
3.8. Interaction with other extensions . . . . . . . . . . . . 6
4. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. Changes/additions to the IMAP4 capabilities registry . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction and Overview
This document defines an extension to the Internet Message Access
Protocol [RFC3501] for eliminating use of message numbers. This
extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2
[RFC9051].
Melnikov, et al. Expires 4 September 2023 [Page 2]
Internet-Draft IMAP UIDONLY March 2023
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.
2. Document Conventions
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Other capitalised words are names of IMAP commands or responses
[RFC3501][RFC9051] or keywords from this document.
3. The UIDONLY extension
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 Section 3.1, 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 Section 3.1, 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.
Melnikov, et al. Expires 4 September 2023 [Page 3]
Internet-Draft IMAP UIDONLY March 2023
3.1. Enabling UIDONLY extension
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.
S: * OK [CAPABILITY IMAP4rev1 ENABLE CONDSTORE QRESYNC UIDONLY AUTH=SCRAM-SHA-256]
C: 01 ENABLE UIDONLY
S: * ENABLED UIDONLY
S: 01 OK ENABLE completed
3.2. Changes to FETCH/STORE/SEARCH/COPY/MOVE
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.
3.3. Changes to UID FETCH/UID STORE
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.
C: 10 UID FETCH 25900:26600 (FLAGS)
[...]
S: * 25996 UIDFETCH (FLAGS (\Seen))
S: * 25997 UIDFETCH (FLAGS (\Flagged \Answered))
S: * 26600 UIDFETCH (FLAGS ())
S: 10 OK FETCH completed
C: 11 UID FETCH 25900:26600 (UID FLAGS)
S: * 25900 UIDFETCH (FLAGS (\Seen))
S: * 25902 UIDFETCH (FLAGS (\Flagged))
S: * 26310 UIDFETCH (FLAGS (\Answered))
S: * 26311 UIDFETCH (FLAGS ())
S: * 26498 UIDFETCH (FLAGS (\Answered))
[...]
S: 11 OK FETCH completed
Melnikov, et al. Expires 4 September 2023 [Page 4]
Internet-Draft IMAP UIDONLY March 2023
3.4. Changes to EXPUNGE/UID EXPUNGE
When UIDONLY is enabled, all EXPUNGED responses that would be
returned by EXPUNGE/UID EXPUNGE are replaced by VANISHED responses,
as defined in [RFC7162]. Note that a server that implements UIDONLY
extension is not required (but allowed) to also implement CONDSTORE
and/or QRESYNC extensions.
C: 12 EXPUNGE
S: * VANISHED 405,407,410,425
S: 12 OK expunged
3.5. Changes to UID SEARCH
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.
3.6. Changes to how other mailbox changes are announced
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 [RFC4315].
Use of UIDNOTSTICKY response code (see [RFC4315]) is not compatible
with the UIDONLY extension. I.e. a server that advertises UIDONLY
extension MUST NOT return UIDNOTSTICKY response code.
3.7. Interaction with CONDSTORE and QRESYNC extensions
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 [RFC7162]) MUST NOT be
used. The server MUST return a tagged BAD response if such parameter
is observed once UIDONLY is enabled.
Melnikov, et al. Expires 4 September 2023 [Page 5]
Internet-Draft IMAP UIDONLY March 2023
3.8. Interaction with other extensions
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 [RFC5256] commands are prohibited,
similarly to the SEARCH command. However UID SORT and UID THREAD can
be used instead.
4. Formal syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF].
Non-terminals referenced but not defined below are as defined by
IMAP4 [RFC3501].
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.
SP = <Defined in RFC 5234>
capability =/ "UIDONLY"
;; <capability> 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 = <defines VANISHED response, see RFC 7162>
5. Security Considerations
TBD.
6. IANA Considerations
Melnikov, et al. Expires 4 September 2023 [Page 6]
Internet-Draft IMAP UIDONLY March 2023
6.1. Changes/additions to the IMAP4 capabilities registry
IMAP4 capabilities are registered by publishing a standards track or
IESG approved Informational or Experimental RFC. The registry is
currently located at:
https://www.iana.org/assignments/imap4-capabilities
IANA is requested to add definition of the UIDONLY extension to this
registry with [RFCXXXX] as the reference.
7. Acknowledgments
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.
8. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for
Syntax Specifications: ABNF", RFC 5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
[RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315,
December 2005, <https://www.rfc-editor.org/info/rfc4315>.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256,
DOI 10.17487/RFC5256, June 2008,
<https://www.rfc-editor.org/info/rfc5256>.
[RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
Changes Resynchronization (CONDSTORE) and Quick Mailbox
Resynchronization (QRESYNC)", RFC 7162,
DOI 10.17487/RFC7162, May 2014,
<https://www.rfc-editor.org/info/rfc7162>.
Melnikov, et al. Expires 4 September 2023 [Page 7]
Internet-Draft IMAP UIDONLY March 2023
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>.
Authors' Addresses
Alexey Melnikov
Isode Limited
Email: alexey.melnikov@isode.com
URI: https://www.isode.com
Arun Prakash Achuthan
Yahoo Inc.
Email: arunprakash@myyahoo.com
Vikram Nagulakonda
Yahoo Inc.
Email: nvikram_imap@yahoo.com
Ashutosh Singh
Yahoo Inc.
Email: ashutoshvsingh@yahoo.com
Luis Alves
Email: luis.alves@lafaspot.com
Melnikov, et al. Expires 4 September 2023 [Page 8]
