<?xml version="1.0"?> version='1.0' encoding='UTF-8'?>

<!-- pre-edited by ST 04/08/24 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc3501 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3501.xml'> nbsp    "&#160;">
  <!ENTITY rfc4315 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4315.xml'> zwsp   "&#8203;">
  <!ENTITY rfc5256 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5256.xml'> nbhy   "&#8209;">
  <!ENTITY rfc7162 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7162.xml'>
  <!ENTITY rfc8174 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml'>
  <!ENTITY rfc9051 PUBLIC '' 'https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9051.xml'> wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" ipr="pre5378Trust200902" docName="draft-ietf-extra-imap-uidonly-08">
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc toc="yes" ?>
	<?rfc symrefs="yes" ?>
	<?rfc sortrefs="yes"?>
	<?rfc iprnotified="no" ?>
	<?rfc strict="yes" ?>
	<?rfc comments="yes" ?>
	<?rfc inline="yes" ?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?> docName="draft-ietf-extra-imap-uidonly-08" number="9586" obsoletes="" updates="" consensus="true" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="IMAP UIDONLY">
      IMAP UIDONLY">IMAP Extension for only using Using and returning UIDs
    </title> Returning Unique Identifiers (UIDs) Only</title>
    <seriesInfo name="RFC" value="9586"/>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization abbrev="Isode">
				Isode Limited
			</organization> abbrev="Isode">Isode Limited</organization>
      <address>
        <email>alexey.melnikov@isode.com</email>
        <uri>https://www.isode.com</uri>
      </address>
    </author>
    <author initials="A. P." surname="Achuthan" fullname="Arun Prakash Achuthan">
      <organization abbrev="Yahoo!">
        Yahoo Inc.
      </organization> abbrev="Yahoo!">Yahoo Inc.</organization>
      <address>
        <email>arunprakash@myyahoo.com</email>
      </address>
    </author>
    <author initials="V." surname="Nagulakonda" fullname="Vikram Nagulakonda">
      <organization abbrev="Yahoo!">
        Yahoo Inc.
      </organization> abbrev="Yahoo!">Yahoo Inc.</organization>
      <address>
        <email>nvikram_imap@yahoo.com</email>
      </address>
    </author>
    <author initials="A." surname="Singh" fullname="Ashutosh Singh">
      <organization abbrev="Yahoo!">
        Yahoo Inc.
      </organization> abbrev="Yahoo!">Yahoo Inc.</organization>
      <address>
        <email>ashutoshvsingh@yahoo.com</email>
      </address>
    </author>
    <author initials="L." surname="Alves" fullname="Luis Alves">
      <address>
        <email>luis.alves@lafaspot.com</email>
      </address>
    </author>
    <date month="May" year="2024"/>
    <area>ART</area>
    <workgroup>extra</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

    <abstract>
      <t>The UIDONLY extension to the Internet Message Access Protocol (RFC 3501/RFC (RFCs
      3501 and 9051) allows clients to enable a mode in which information
      about mailbox changes is returned using only Unique Identifiers (UIDs).
      Message numbers are not returned in responses, responses and can't cannot 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.
      <!--Bron's version:
      This allows both clients and servers to avoid requiring resources to maintain a map between message numbers and UIDs.
      -->
      </t>
      <t>
      This document defines an experimental IMAP extension.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction numbered="true" toc="default">
      <name>Introduction and Overview"> Overview</name>

      <t>This document defines an extension to the Internet Message Access Protocol <xref target="RFC3501"/> target="RFC3501" format="default"/> <xref target="RFC9051" format="default"/> for eliminating the use of message numbers. This extension is compatible with both IMAP4rev1 <xref target="RFC3501"/> target="RFC3501" format="default"/> and IMAP4rev2 <xref target="RFC9051"/>.</t> target="RFC9051" format="default"/>.</t>
      <t>
      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. maintain a map between message numbers and UIDs.
      </t>
    </section>
    <section title="Document Conventions"> numbered="true" toc="default">
      <name>Document Conventions</name>
      <t>In protocol examples, this document uses a prefix of "C: " "C:" to denote lines sent by the client to the server, server and
			"S: " "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.</t>
      <t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
      "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
      "OPTIONAL"
      "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP
      14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/>
      when, and only when, they appear in all capitals, as shown here.
      </t>
      <t>
      Other capitalised capitalized words are names of IMAP commands or responses <xref target="RFC3501"/><xref target="RFC9051"/> target="RFC3501" format="default"/> <xref target="RFC9051" format="default"/>
      or keywords from this document.
      </t>
    </section>
    <section title="The anchor="imap-uidonly" numbered="true" toc="default">
      <name>The UIDONLY extension" anchor="imap-uidonly"> Extension</name>
      <t>An IMAP server advertises support for the UIDONLY extension
        by including the "UIDONLY" capability in the CAPABILITY response/response code.</t>
      <t>
        Once the UIDONLY extension is enabled (see <xref target="enabling"/>), target="enabling" format="default"/>),
        the client MUST NOT <bcp14>MUST NOT</bcp14> use message sequence numbers (including the special marker "*")
        in any arguments to IMAP commands, and the server MUST <bcp14>MUST</bcp14> return a tagged BAD response
        if the client uses message sequence numbers. The server MUST <bcp14>MUST</bcp14> include the UIDREQUIRED response code in such BAD responses (see below).
        Additionally, once the UIDONLY extension is enabled,
        the server MUST NOT <bcp14>MUST NOT</bcp14> return message sequence numbers in any response.
      </t>
      <t>The UIDREQUIRED response code is defined as follows:

      <list style='hanging'>
      <t hangText='UIDREQUIRED'>
      <!--
        <iref item='UIDREQUIRED (response code)'/>
        -->

        <list>
          <t>
          Once
      </t>
      <dl newline="false" spacing="normal">
        <dt>UIDREQUIRED:</dt><dd><t>Once the UIDONLY extension is enabled enabled, the server returns the UIDREQUIRED response code when the client issues a command that includes message numbers instead of UIDs.
      </t>

          <t>
<figure><artwork><![CDATA[
              <artwork name="" type="" align="left" alt=""><![CDATA[
  C: 07 FETCH 10000:14589 (UID FLAGS)
  S: 07 BAD [UIDREQUIRED] Message numbers are not allowed
      once UIDONLY is enabled
]]></artwork></figure>
          </t>

        </list>
      </t>
      </list>
        </t>
]]></artwork>
            </dd>
          </dl>
      <t>The UIDONLY extension affects how information about new, expunged expunged,
      or changed messages is returned in unsolicited responses.
      In partucular, particular,
        it affects responses to UID FETCH/UID STORE/EXPUNGE/UID EXPUNGE,
        as well as how unsolicited mailbox changes are announced.
      </t>
      <t>The following subsections describe changes introduced by this extension
        in more detail.</t>
      <section title="Enabling anchor="enabling" numbered="true" toc="default">
        <name>Enabling the UIDONLY extension" anchor="enabling"> Extension</name>
        <t>
      As the UIDONLY extension affects how information about new, expunged expunged,
      or changed messages is returned in unsolicited responses, it has to be
      enabled by the client first using the ENABLE command.
        </t>

<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
  S: * OK [CAPABILITY IMAP4rev1 ENABLE CONDSTORE QRESYNC UIDONLY
      AUTH=SCRAM-SHA-256]
  C: 01 ENABLE UIDONLY
  S: * ENABLED UIDONLY
  S: 01 OK ENABLE completed
]]></artwork></figure>
]]></artwork>
      </section>
      <section title="Changes numbered="true" toc="default">
        <name>Changes to FETCH/STORE/SEARCH/COPY/MOVE"> FETCH/STORE/SEARCH/COPY/MOVE</name>
        <t>When UIDONLY is enabled, the FETCH, STORE, SEARCH, COPY COPY, and MOVE commands are prohibited
          and MUST <bcp14>MUST</bcp14> result in a tagged BAD response. Clients should instead use UID FETCH,
          UID STORE, UID SEARCH, UID COPY COPY, or UID MOVE MOVE, respectively.</t>
      </section>
      <section title="Changes numbered="true" toc="default">
        <name>Changes to UID FETCH/UID STORE"> FETCH / UID STORE</name>
        <t>When UIDONLY is enabled, all FETCH responses that would be returned by UID FETCH/UID FETCH / UID STORE
          are replaced by UIDFETCH responses.</t>
        <t>Note that the 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 the UID response data item, if requested by the client.
          While the UID response data item is redundant when requested, it can simplify the updating
          of existing (non UIDONLY) (non-UIDONLY) implementations to support UIDONLY.</t>

<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
  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
]]></artwork></figure>

<figure><artwork><![CDATA[
]]></artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  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
]]></artwork></figure>
]]></artwork>
      </section>
      <section title="Changes numbered="true" toc="default">
        <name>Changes to EXPUNGE/UID EXPUNGE"> EXPUNGE / UID EXPUNGE</name>
        <t>When UIDONLY is enabled, all EXPUNGED responses that would be returned by EXPUNGE/UID EXPUNGE / UID EXPUNGE
          are replaced by VANISHED responses, as defined in <xref target="RFC7162"/>. target="RFC7162" format="default"/>. Note that a server that implements the UIDONLY extension is not required (but allowed) to also implement the CONDSTORE and/or QRESYNC extensions.</t>

<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
  C: 12 EXPUNGE
  S: * VANISHED 405,407,410,425
  S: 12 OK expunged
]]></artwork></figure>
]]></artwork>
      </section>
      <section title="Changes numbered="true" toc="default">
        <name>Changes to UID SEARCH"> SEARCH</name>
        <t>The "&lt;sequence set&gt;" UID SEARCH criterion is prohibited (and results in a tagged BAD response) once UIDONLY is enabled.
          Clients should use ALL or "UID &lt;sequence set&gt;" UID SEARCH criterion instead.</t>
      </section>
      <section title="Changes numbered="true" toc="default">
        <name>Changes to how other mailbox changes are announced"> How Other Mailbox Changes Are Announced</name>
        <t>When UIDONLY is enabled, all changes to flags (and other dynamic message attributes)
          are returned using UIDFETCH responses, responses instead of FETCH responses.</t>
        <t>Similarly, all expunged messages are announced using VANISHED responses
          instead of EXPUNGE responses.</t>
          <t>This extension doesn't affect EXISTS or RECENT responses.</t>

          <t>UID MOVE/UID
        <t>The UID MOVE / UID COPY commands SHOULD <bcp14>SHOULD</bcp14> return the COPYUID response code, as specified in <xref target="RFC4315"/>. target="RFC4315" format="default"/>.
        </t>
        <t>Use of the UIDNOTSTICKY response code (see <xref target="RFC4315"/>) target="RFC4315" format="default"/>) is not compatible with the UIDONLY extension,
          i.e. i.e., a server that advertises the UIDONLY extension MUST NOT <bcp14>MUST NOT</bcp14> return a UIDNOTSTICKY response code.</t>

<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
  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
]]></artwork></figure>
]]></artwork>
      </section>
      <section title="Interaction numbered="true" toc="default">
        <name>Interaction with the CONDSTORE and QRESYNC extensions"> Extensions</name>
        <t>
          The CONDSTORE extension is compatible with the UIDONLY extension.
          The MODSEQ message data item is returned in UIDFETCH responses instead of FETCH responses.
        </t>
        <t>
          The QRESYNC extension is compatible with the UIDONLY extension, but once UIDONLY is enabled,
          the fourth SELECT QRESYNC parameter ("Message (see Section <xref target="RFC7162" section="3.2.5.2"
sectionFormat="bare">"Message Sequence Match Data", see Section 3.2.5.2 Data"</xref> of <xref target="RFC7162"/>)
          MUST NOT
          <bcp14>MUST NOT</bcp14> be used. The server MUST <bcp14>MUST</bcp14> return a tagged BAD response if such a parameter is observed once UIDONLY is enabled.
        </t>
      </section>
      <section title="Interaction numbered="true" toc="default">
        <name>Interaction with other extensions"> Other Extensions</name>
        <t>IMAP extensions might define other commands that accept message sequence numbers ("sequence-set" ABNF non terminal, non-terminal; see Section 9 of <xref target="RFC9051"/>). target="RFC9051" sectionFormat="of" section="9"/>).
          Once UIDONLY is enabled, the server MUST <bcp14>MUST</bcp14> reject such commands with a tagged BAD response. For example, the SORT and THREAD <xref target="RFC5256"/> target="RFC5256" format="default"/> commands are prohibited, similarly to the SEARCH command.
          However However, UID SORT and UID THREAD can be used instead.
        </t>
      </section>
    </section>
    <section title="Formal syntax"> numbered="true" toc="default">
      <name>Formal Syntax</name>
      <t>The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in <xref target="ABNF"/>.</t> target="RFC5234" format="default"/>.</t>
      <t>Non-terminals referenced but not defined below are as defined by Section 9 of in <xref target="RFC9051">IMAP4</xref>.</t> target="RFC9051" sectionFormat="of" section="9">IMAP4</xref>.</t>
      <t>Except as noted otherwise, all alphabetic characters are case-insensitive. case insensitive.
      The use of upper uppercase or lower case lowercase characters to define token strings is for editorial clarity only.
      Implementations MUST <bcp14>MUST</bcp14> accept these strings in a case-insensitive fashion.</t>

<figure><artwork>
      <![CDATA[
      <sourcecode type="abnf"><![CDATA[
SP                  = <Defined in RFC 5234>

capability          =/ "UIDONLY"
                       ;; <capability> from [RFC9051] <capability>; see RFC 9051

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, response; see RFC 7162>

resp-text-code      =/ "UIDREQUIRED"
]]></artwork></figure>
]]></sourcecode>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
      This IMAP extension is not believed to add any additional Security Considerations
      beyond the ones that are generally applicable to IMAP4rev1 <xref target="RFC3501"/> target="RFC3501" format="default"/>
      and IMAP4rev2 <xref target="RFC9051"/>. target="RFC9051" format="default"/>.
      </t>
    </section>
    <section title="IANA Considerations">

			<t>
				IMAP4 numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IMAP4 capabilities are registered by publishing a standards track Standards Track or
				IESG approved IESG-approved Informational or Experimental RFC.
        The registry is currently located at:
      </t>

			<figure><artwork><![CDATA[
   https://www.iana.org/assignments/imap4-capabilities
    ]]></artwork></figure>
      <t>IANA is requested to add definition of has added the UIDONLY extension to
      this
      the "IMAP Capabilities" registry with [RFCXXXX] RFC 9586 as the reference. The registry is located at <eref target="https://www.iana.org/assignments/imap4-capabilities/" brackets="angle"/>.
      </t>
      <t>IANA is has also requested to add definition of added the UIDREQUIRED response code
      to the "IMAP Response Codes" registry with [RFCXXXX] RFC 9586 as the reference.
      The registry is currently located at: at <eref target="https://www.iana.org/assignments/imap-response-codes/" brackets="angle"/>.
      </t>

			<figure><artwork><![CDATA[
   https://www.iana.org/assignments/imap-response-codes/imap-response-codes.xhtml
      ]]></artwork></figure>
    </section>
    <section title="Alternative solutions not taken"> numbered="true" toc="default">
      <name>Alternative Solutions Not Taken</name>
      <t>
      An earlier draft version of this document proposed use of FETCH responses with
      the message number parameter always be set to 0.
      This was judged considered to be too risky, risky as this it could have caused cause unexpected
      side effects and cache corruptions in client code that was not properly updated
      to handle a lack of message numbers.
      </t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC5234" to="ABNF"/>
    <displayreference target="I-D.gulbrandsen-imap-uidonly" to="IMAP-UIDONLY-ORIG"/>
    <references>
      <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3501.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4315.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5256.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7162.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9051.xml"/>
    </references>

  <references>
    <name>Informative References</name>
    <!--draft-gulbrandsen-imap-uidonly; IESG State: Expired-->
    <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-gulbrandsen-imap-uidonly.xml"/>

  </references>
  <section title="Acknowledgments"> numbered="false">
      <name>Acknowledgments</name>
      <t>
      Editors
      The 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,
      Bron Gondwana, Barry Leiba and Elwyn Davis. document: <contact fullname="Arnt Gulbrandsen"/>, <contact fullname="Ken Murchison"/>, <contact fullname="Bron Gondwana"/>, <contact fullname="Barry Leiba"/>, and <contact fullname="Elwyn Davis"/>.
      </t>
      <t>

<!--[rfced] FYI: "draft-gulbrandsen-imap-uidonly-00" did not have a
reference entry, so we created one under "Informative References"
as shown below.

Original:
   This document is similar to draft-gulbrandsen-imap-uidonly-00.txt,
   but some different syntactic choices were made in the end.

Current:
   This document is similar to [IMAP-UIDONLY], but some
   different syntactic choices were made in the end.

Informative Reference Entry:
[IMAP-UIDONLY]
     Gulbrandsen, A., "The IMAP UIDONLY Extension", Work in Progress,
     Internet-Draft, draft-gulbrandsen-imap-uidonly-00, 25 April 2014,
     <https://datatracker.ietf.org/doc/html/draft-gulbrandsen-imap-uidonly-00>.
-->
      This document is similar to <xref target="I-D.gulbrandsen-imap-uidonly"/>,
      but some different syntactic choices were made in the end.
      </t>
    </section>

	</middle>
	<back>
		<references title="Normative References">
			&rfc2119;
      &rfc8174;
      &rfc3501;
      <reference anchor="ABNF">
				<front>
					<title>Augmented BNF for Syntax Specifications: ABNF</title>
					<author initials="D" surname="Crocker" fullname="Dave Crocker" role="editor">
						<organization />
					</author>
					<author initials="P" surname="Overell" fullname="Paul Overell" role="editor">
						<organization />
					</author>
					<date year="2008" month="January"/>
				</front>
				<seriesInfo name="RFC" value="5234" />
				<format type="TXT" target="https://www.rfc-editor.org/info/rfc5234" />
			</reference>

      &rfc4315;
      &rfc5256;
      &rfc7162;
      &rfc9051;

    </references>

  </back>

<!--
    <references title="Informative References">
    </references> [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

	</back>

</rfc>