Skip to main content

IMAP Extension for only using and returning UIDs
draft-ietf-extra-imap-uidonly-06

Document Type Active Internet-Draft (extra WG)
Authors Alexey Melnikov , ArunPrakash Achuthan , Vikram Nagulakonda , Ashutosh Singh , Luis Alves
Last updated 2024-02-14 (Latest revision 2023-12-05)
Replaces draft-melnikov-imap-uidonly
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Experimental
Formats
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Associated WG milestone
Dec 2023
Submit IMAP UIDONLY draft to IESG
Document shepherd Kenneth Murchison
Shepherd write-up Show Last changed 2023-12-05
IESG IESG state AD Evaluation
Action Holder
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Murray Kucherawy
Send notices to murch@fastmailteam.com
draft-ietf-extra-imap-uidonly-06
Network Working Group                                        A. Melnikov
Internet-Draft                                                     Isode
Intended status: Experimental                             A. P. Achuthan
Expires: 7 June 2024                                      V. Nagulakonda
                                                                A. Singh
                                                                  Yahoo!
                                                                L. Alves
                                                         5 December 2023

            IMAP Extension for only using and returning UIDs
                    draft-ietf-extra-imap-uidonly-06

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 to maintain a map between message
   numbers and UIDs.

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 7 June 2024.

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 7 June 2024                  [Page 1]
Internet-Draft                IMAP UIDONLY                 December 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 . . . .   6
     3.8.  Interaction with other extensions . . . . . . . . . . . .   6
   4.  Formal syntax . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Changes/additions to the IMAP4 capabilities registry  . .   7
   7.  Alternative solutions not taken . . . . . . . . . . . . . . .   8
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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 7 June 2024                  [Page 2]
Internet-Draft                IMAP UIDONLY                 December 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.

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 (see 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.  The
   server SHOULD include the UIDREQUIRED response code in such BAD
   responses (see below).  Additionally, once the UIDONLY extension is
   enabled, the server MUST NOT return message sequence numbers in any
   response.

   The UIDREQUIRED response code is defined as follows:

   UIDREQUIRED  The server returns UIDREQUIRED response code when the client
         issues a command that includes message numbers instead of UIDs
         once UIDONLY extension is enabled.

Melnikov, et al.           Expires 7 June 2024                  [Page 3]
Internet-Draft                IMAP UIDONLY                 December 2023

           C: 07 FETCH 10000:14589 (UID FLAGS)
           S: 07 OK [UIDREQUIRED] Message numbers are not allowed
               once UIDONLY is enabled

   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.

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 response data items as
   specified for the FETCH response.  The UID is always returned at the
   beginning of a UIDFETCH response, and it can also appear in UID
   response data item, if requested by the client.  While UID response
   data item is redundant when requested, it can simplify updating of
   existing (non UIDONLY) implementations to support UIDONLY.

Melnikov, et al.           Expires 7 June 2024                  [Page 4]
Internet-Draft                IMAP UIDONLY                 December 2023

     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) UID 25900)
     S: * 25902 UIDFETCH (FLAGS (\Flagged) UID 25902)
     S: * 26310 UIDFETCH (FLAGS (\Answered) UID 26310)
     S: * 26311 UIDFETCH (FLAGS () UID 26311)
     S: * 26498 UIDFETCH (FLAGS (\Answered) UID 26498)
     [...]
     S: 11 OK FETCH completed

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.

   This extension doesn't affect EXISTS or RECENT responses.

   UID MOVE/UID COPY commands SHOULD return COPYUID response code, as
   specified in [RFC4315].

Melnikov, et al.           Expires 7 June 2024                  [Page 5]
Internet-Draft                IMAP UIDONLY                 December 2023

   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.

     C: 15 UID move 597 "Archives/2023/2023-05"
     S: * OK [COPYUID 1685977201 597 2] UID MOVE
     S: * VANISHED 597
     S: 15 OK UID MOVE Completed

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.

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.

Melnikov, et al.           Expires 7 June 2024                  [Page 6]
Internet-Draft                IMAP UIDONLY                 December 2023

   SP                  = <Defined in RFC 5234>

   capability          =/ "UIDONLY"
                          ;; <capability> from [RFC3501]

   message-data        =/ uidfetch-resp

   uidfetch-resp       = uniqueid SP "UIDFETCH" SP msg-att
                         ;; The uniqueid is the UID of the corresponding
                         ;; message

   message-data        =/ expunged-resp

   expunged-resp       = <defines VANISHED response, see RFC 7162>

   resp-text-code      =/ "UIDREQUIRED"

5.  Security Considerations

   This IMAP extension is not believed to add any additional Security
   Considerations beyond the ones that are generally applicable to
   IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].

6.  IANA Considerations

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.

   IANA is also requested to add definition of the UIDREQUIRED response
   code to the "IMAP Response Codes" registry with [RFCXXXX] as the
   reference.  The registry is currently located at:

   https://www.iana.org/assignments/imap-response-codes/imap-response-codes.xhtml

Melnikov, et al.           Expires 7 June 2024                  [Page 7]
Internet-Draft                IMAP UIDONLY                 December 2023

7.  Alternative solutions not taken

   An earlier draft of this document proposed use of FETCH responses
   with the message number parameter always be set to 0.  This was
   judged to be too risky, as this could have caused unexpected side
   effects and cache corruptions in client code that was not properly
   updated to handle lack of message numbers.

8.  Acknowledgments

   Editors 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, Ken Murchison and
   Bron Gondwana.  This document is similar to draft-gulbrandsen-imap-
   uidonly-00.txt, but some different syntactic choices were made in the
   end.

9.  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 7 June 2024                  [Page 8]
Internet-Draft                IMAP UIDONLY                 December 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>.

Index

   U

      U

         UIDREQUIRED (response code)
            Section 3, Paragraph 4.2.1

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 7 June 2024                  [Page 9]