<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="exp" ipr="pre5378Trust200902" docName="draft-ietf-extra-imap-uidonly-08" number="9586" obsoletes="" updates="" consensus="true" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" prepTime="2024-05-30T09:16:00" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-extra-imap-uidonly-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9586" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="IMAP UIDONLY">IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only</title>
    <seriesInfo name="RFC" value="9586" stream="IETF"/>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization abbrev="Isode" showOnFrontPage="true">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!" showOnFrontPage="true">Yahoo Inc.</organization>
      <address>
        <email>arunprakash@myyahoo.com</email>
      </address>
    </author>
    <author initials="V." surname="Nagulakonda" fullname="Vikram Nagulakonda">
      <organization abbrev="Yahoo!" showOnFrontPage="true">Yahoo Inc.</organization>
      <address>
        <email>nvikram_imap@yahoo.com</email>
      </address>
    </author>
    <author initials="A." surname="Singh" fullname="Ashutosh Singh">
      <organization abbrev="Yahoo!" showOnFrontPage="true">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="05" year="2024"/>
    <area>ART</area>
    <workgroup>extra</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The UIDONLY extension to the Internet Message Access Protocol (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 and 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.
      </t>
      <t indent="0" pn="section-abstract-2">
      This document defines an experimental IMAP extension.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  This document is a product of the Internet Engineering
            Task Force (IETF).  It represents the consensus of the IETF community.
            It has received public review and has been approved for publication
            by the Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9586" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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 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.
        </t>
        <t indent="0" pn="section-boilerplate.2-3">
            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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction-and-overview">Introduction and Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-document-conventions">Document Conventions</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-uidonly-extension">The UIDONLY Extension</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-enabling-the-uidonly-extens">Enabling the UIDONLY Extension</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-fetch-store-sear">Changes to FETCH/STORE/SEARCH/COPY/MOVE</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-uid-fetch-uid-st">Changes to UID FETCH / UID STORE</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-expunge-uid-expu">Changes to EXPUNGE / UID EXPUNGE</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-uid-search">Changes to UID SEARCH</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-how-other-mailbo">Changes to How Other Mailbox Changes Are Announced</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.7">
                <t indent="0" pn="section-toc.1-1.3.2.7.1"><xref derivedContent="3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-the-condst">Interaction with the CONDSTORE and QRESYNC Extensions</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.8">
                <t indent="0" pn="section-toc.1-1.3.2.8.1"><xref derivedContent="3.8" format="counter" sectionFormat="of" target="section-3.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-other-exte">Interaction with Other Extensions</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-formal-syntax">Formal Syntax</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-alternative-solutions-not-t">Alternative Solutions Not Taken</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction-and-overview">Introduction and Overview</name>
      <t indent="0" pn="section-1-1">This document defines an extension to the Internet Message Access Protocol <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/> for eliminating the use of message numbers. This extension is compatible with both IMAP4rev1 <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> and IMAP4rev2 <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>.</t>
      <t indent="0" pn="section-1-2">	
      The UIDONLY extension of the Internet Message Access Protocol allows clients to request that servers only use and return UIDs. This helps both clients and servers to reduce resource usage required to maintain a map between message numbers and UIDs.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-document-conventions">Document Conventions</name>
      <t indent="0" pn="section-2-1">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.</t>
      <t indent="0" pn="section-2-2">
      The key words "<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
      "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP
      14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>
      when, and only when, they appear in all capitals, as shown here.
      </t>
      <t indent="0" pn="section-2-3">
      Other capitalized words are names of IMAP commands or responses <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>
      or keywords from this document.
      </t>
    </section>
    <section anchor="imap-uidonly" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-the-uidonly-extension">The UIDONLY Extension</name>
      <t indent="0" pn="section-3-1">An IMAP server advertises support for the UIDONLY extension
        by including the "UIDONLY" capability in the CAPABILITY response/response code.</t>
      <t indent="0" pn="section-3-2">
        Once the UIDONLY extension is enabled (see <xref target="enabling" format="default" sectionFormat="of" derivedContent="Section 3.1"/>),
        the client <bcp14>MUST NOT</bcp14> use message sequence numbers (including the special marker "*")
        in any arguments to IMAP commands, and the server <bcp14>MUST</bcp14> return a tagged BAD response
        if the client uses message sequence numbers. The server <bcp14>MUST</bcp14> include the UIDREQUIRED response code in such BAD responses (see below).
        Additionally, once the UIDONLY extension is enabled,
        the server <bcp14>MUST NOT</bcp14> return message sequence numbers in any response.
      </t>
      <t indent="0" pn="section-3-3">The UIDREQUIRED response code is defined as follows:
      </t>
      <dl newline="false" spacing="normal" indent="3" pn="section-3-4">
        <dt pn="section-3-4.1">UIDREQUIRED:</dt>
        <dd pn="section-3-4.2">
          <t indent="0" pn="section-3-4.2.1">Once the UIDONLY extension is enabled, the server returns the UIDREQUIRED response code when the client issues a command that includes message numbers instead of UIDs.
          </t>
          <artwork name="" type="" align="left" alt="" pn="section-3-4.2.2">
  C: 07 FETCH 10000:14589 (UID FLAGS)
  S: 07 BAD [UIDREQUIRED] Message numbers are not allowed
      once UIDONLY is enabled
</artwork>
        </dd>
      </dl>
      <t indent="0" pn="section-3-5">The UIDONLY extension affects how information about new, expunged,
      or changed messages is returned in unsolicited responses.
      In particular,
        it affects responses to UID FETCH/UID STORE/EXPUNGE/UID EXPUNGE,
        as well as how unsolicited mailbox changes are announced.
      </t>
      <t indent="0" pn="section-3-6">The following subsections describe changes introduced by this extension
        in more detail.</t>
      <section anchor="enabling" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-enabling-the-uidonly-extens">Enabling the UIDONLY Extension</name>
        <t indent="0" pn="section-3.1-1">
      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.
        </t>
        <artwork name="" type="" align="left" alt="" pn="section-3.1-2">
  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>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-changes-to-fetch-store-sear">Changes to FETCH/STORE/SEARCH/COPY/MOVE</name>
        <t indent="0" pn="section-3.2-1">When UIDONLY is enabled, the FETCH, STORE, SEARCH, COPY, and MOVE commands are prohibited
          and <bcp14>MUST</bcp14> result in a tagged BAD response. Clients should instead use UID FETCH,
          UID STORE, UID SEARCH, UID COPY, or UID MOVE, respectively.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-changes-to-uid-fetch-uid-st">Changes to UID FETCH / UID STORE</name>
        <t indent="0" pn="section-3.3-1">When UIDONLY is enabled, all FETCH responses that would be returned by UID FETCH / UID STORE
          are replaced by UIDFETCH responses.</t>
        <t indent="0" pn="section-3.3-2">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) implementations to support UIDONLY.</t>
        <artwork name="" type="" align="left" alt="" pn="section-3.3-3">
  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>
        <artwork name="" type="" align="left" alt="" pn="section-3.3-4">
  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>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-changes-to-expunge-uid-expu">Changes to EXPUNGE / UID EXPUNGE</name>
        <t indent="0" pn="section-3.4-1">When UIDONLY is enabled, all EXPUNGED responses that would be returned by EXPUNGE / UID EXPUNGE
          are replaced by VANISHED responses, as defined in <xref target="RFC7162" format="default" sectionFormat="of" derivedContent="RFC7162"/>. Note that a server that implements the UIDONLY extension is not required (but allowed) to also implement the CONDSTORE and/or QRESYNC extensions.</t>
        <artwork name="" type="" align="left" alt="" pn="section-3.4-2">
  C: 12 EXPUNGE
  S: * VANISHED 405,407,410,425
  S: 12 OK expunged
</artwork>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.5">
        <name slugifiedName="name-changes-to-uid-search">Changes to UID SEARCH</name>
        <t indent="0" pn="section-3.5-1">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 numbered="true" toc="include" removeInRFC="false" pn="section-3.6">
        <name slugifiedName="name-changes-to-how-other-mailbo">Changes to How Other Mailbox Changes Are Announced</name>
        <t indent="0" pn="section-3.6-1">When UIDONLY is enabled, all changes to flags (and other dynamic message attributes)
          are returned using UIDFETCH responses instead of FETCH responses.</t>
        <t indent="0" pn="section-3.6-2">Similarly, all expunged messages are announced using VANISHED responses
          instead of EXPUNGE responses.</t>
        <t indent="0" pn="section-3.6-3">This extension doesn't affect EXISTS or RECENT responses.</t>
        <t indent="0" pn="section-3.6-4">The UID MOVE / UID COPY commands <bcp14>SHOULD</bcp14> return the COPYUID response code, as specified in <xref target="RFC4315" format="default" sectionFormat="of" derivedContent="RFC4315"/>.
        </t>
        <t indent="0" pn="section-3.6-5">Use of the UIDNOTSTICKY response code (see <xref target="RFC4315" format="default" sectionFormat="of" derivedContent="RFC4315"/>) is not compatible with the UIDONLY extension, i.e., a server that advertises the UIDONLY extension <bcp14>MUST NOT</bcp14> return a UIDNOTSTICKY response code.</t>
        <artwork name="" type="" align="left" alt="" pn="section-3.6-6">
  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>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.7">
        <name slugifiedName="name-interaction-with-the-condst">Interaction with the CONDSTORE and QRESYNC Extensions</name>
        <t indent="0" pn="section-3.7-1">
          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 indent="0" pn="section-3.7-2">
          The QRESYNC extension is compatible with the UIDONLY extension, but once UIDONLY is enabled,
          the fourth SELECT QRESYNC parameter (see Section <xref target="RFC7162" section="3.2.5.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7162#section-3.2.5.2" derivedContent="RFC7162">"Message Sequence Match Data"</xref> of <xref target="RFC7162" format="default" sectionFormat="of" derivedContent="RFC7162"/>)
          <bcp14>MUST NOT</bcp14> be used. The server <bcp14>MUST</bcp14> return a tagged BAD response if such a parameter is observed once UIDONLY is enabled.
        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.8">
        <name slugifiedName="name-interaction-with-other-exte">Interaction with Other Extensions</name>
        <t indent="0" pn="section-3.8-1">IMAP extensions might define other commands that accept message sequence numbers ("sequence-set" ABNF non-terminal; see <xref target="RFC9051" sectionFormat="of" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9051#section-9" derivedContent="RFC9051"/>).
          Once UIDONLY is enabled, the server <bcp14>MUST</bcp14> reject such commands with a tagged BAD response. For example, the SORT and THREAD <xref target="RFC5256" format="default" sectionFormat="of" derivedContent="RFC5256"/> commands are prohibited, similarly to the SEARCH command. However, UID SORT and UID THREAD can be used instead.
        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-formal-syntax">Formal Syntax</name>
      <t indent="0" pn="section-4-1">The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="ABNF"/>.</t>
      <t indent="0" pn="section-4-2">Non-terminals referenced but not defined below are as defined in <xref target="RFC9051" sectionFormat="of" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9051#section-9" derivedContent="RFC9051">IMAP4</xref>.</t>
      <t indent="0" pn="section-4-3">Except as noted otherwise, all alphabetic characters are case insensitive.
      The use of uppercase or lowercase characters to define token strings is for editorial clarity only.
      Implementations <bcp14>MUST</bcp14> accept these strings in a case-insensitive fashion.</t>
      <sourcecode type="abnf" markers="false" pn="section-4-4">
SP                  = &lt;Defined in RFC 5234&gt;

capability          =/ "UIDONLY"
                       ;; &lt;capability&gt;; 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       = &lt;defines VANISHED response; see RFC 7162&gt;

resp-text-code      =/ "UIDREQUIRED"
</sourcecode>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">
      This IMAP extension is not believed to add any additional Security Considerations
      beyond the ones that are generally applicable to IMAP4rev1 <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/>
      and IMAP4rev2 <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Informational or Experimental RFC.
      </t>
      <t indent="0" pn="section-6-2">IANA has added the UIDONLY extension to
      the "IMAP Capabilities" registry with RFC 9586 as the reference. The registry is located at <eref target="https://www.iana.org/assignments/imap4-capabilities/" brackets="angle"/>.
      </t>
      <t indent="0" pn="section-6-3">IANA has also added the UIDREQUIRED response code
      to the "IMAP Response Codes" registry with RFC 9586 as the reference.
      The registry is located at <eref target="https://www.iana.org/assignments/imap-response-codes/" brackets="angle"/>.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-alternative-solutions-not-t">Alternative Solutions Not Taken</name>
      <t indent="0" pn="section-7-1">
      An earlier draft version of this document proposed use of FETCH responses with
      the message number parameter always set to 0.
      This was considered to be too risky as it could 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 pn="section-8">
      <name slugifiedName="name-normative-references">Normative References</name>
      <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" quoteTitle="true" derivedAnchor="ABNF">
        <front>
          <title>Augmented BNF for Syntax Specifications: ABNF</title>
          <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
          <author fullname="P. Overell" initials="P." surname="Overell"/>
          <date month="January" year="2008"/>
          <abstract>
            <t indent="0">Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="68"/>
        <seriesInfo name="RFC" value="5234"/>
        <seriesInfo name="DOI" value="10.17487/RFC5234"/>
      </reference>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC3501" target="https://www.rfc-editor.org/info/rfc3501" quoteTitle="true" derivedAnchor="RFC3501">
        <front>
          <title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title>
          <author fullname="M. Crispin" initials="M." surname="Crispin"/>
          <date month="March" year="2003"/>
          <abstract>
            <t indent="0">The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="3501"/>
        <seriesInfo name="DOI" value="10.17487/RFC3501"/>
      </reference>
      <reference anchor="RFC4315" target="https://www.rfc-editor.org/info/rfc4315" quoteTitle="true" derivedAnchor="RFC4315">
        <front>
          <title>Internet Message Access Protocol (IMAP) - UIDPLUS extension</title>
          <author fullname="M. Crispin" initials="M." surname="Crispin"/>
          <date month="December" year="2005"/>
          <abstract>
            <t indent="0">The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4315"/>
        <seriesInfo name="DOI" value="10.17487/RFC4315"/>
      </reference>
      <reference anchor="RFC5256" target="https://www.rfc-editor.org/info/rfc5256" quoteTitle="true" derivedAnchor="RFC5256">
        <front>
          <title>Internet Message Access Protocol - SORT and THREAD Extensions</title>
          <author fullname="M. Crispin" initials="M." surname="Crispin"/>
          <author fullname="K. Murchison" initials="K." surname="Murchison"/>
          <date month="June" year="2008"/>
          <abstract>
            <t indent="0">This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5256"/>
        <seriesInfo name="DOI" value="10.17487/RFC5256"/>
      </reference>
      <reference anchor="RFC7162" target="https://www.rfc-editor.org/info/rfc7162" quoteTitle="true" derivedAnchor="RFC7162">
        <front>
          <title>IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)</title>
          <author fullname="A. Melnikov" initials="A." surname="Melnikov"/>
          <author fullname="D. Cridland" initials="D." surname="Cridland"/>
          <date month="May" year="2014"/>
          <abstract>
            <t indent="0">Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox.</t>
            <t indent="0">Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience.</t>
            <t indent="0">This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162.</t>
            <t indent="0">Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7162"/>
        <seriesInfo name="DOI" value="10.17487/RFC7162"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="RFC9051" target="https://www.rfc-editor.org/info/rfc9051" quoteTitle="true" derivedAnchor="RFC9051">
        <front>
          <title>Internet Message Access Protocol (IMAP) - Version 4rev2</title>
          <author fullname="A. Melnikov" initials="A." role="editor" surname="Melnikov"/>
          <author fullname="B. Leiba" initials="B." role="editor" surname="Leiba"/>
          <date month="August" year="2021"/>
          <abstract>
            <t indent="0">The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server.</t>
            <t indent="0">IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.</t>
            <t indent="0">IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9051"/>
        <seriesInfo name="DOI" value="10.17487/RFC9051"/>
      </reference>
    </references>
    <references pn="section-9">
      <name slugifiedName="name-informative-references">Informative References</name>
      <reference anchor="I-D.gulbrandsen-imap-uidonly" target="https://datatracker.ietf.org/doc/html/draft-gulbrandsen-imap-uidonly-00" quoteTitle="true" derivedAnchor="IMAP-UIDONLY-ORIG">
        <front>
          <title>The IMAP UIDONLY Extension</title>
          <author initials="A." surname="Gulbrandsen" fullname="Arnt Gulbrandsen">
         </author>
          <date month="April" day="25" year="2014"/>
          <abstract>
            <t indent="0">   Opening a large mailbox in IMAP can take mailbox; 30 seconds is
   realistic if the mailbox contains ten million messages. Most of that
   time is needed to number the messages consecutively.

   This extension provides a way to avoid having to number the messages
   consecutively.


            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-gulbrandsen-imap-uidonly-00"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
    </references>
    <section numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">
      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: <contact fullname="Arnt Gulbrandsen"/>, <contact fullname="Ken Murchison"/>, <contact fullname="Bron Gondwana"/>, <contact fullname="Barry Leiba"/>, and <contact fullname="Elwyn Davis"/>.
      </t>
      <t indent="0" pn="section-appendix.a-2">
      This document is similar to <xref target="I-D.gulbrandsen-imap-uidonly" format="default" sectionFormat="of" derivedContent="IMAP-UIDONLY-ORIG"/>,
      but some different syntactic choices were made in the end.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
        <organization abbrev="Isode" showOnFrontPage="true">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!" showOnFrontPage="true">Yahoo Inc.</organization>
        <address>
          <email>arunprakash@myyahoo.com</email>
        </address>
      </author>
      <author initials="V." surname="Nagulakonda" fullname="Vikram Nagulakonda">
        <organization abbrev="Yahoo!" showOnFrontPage="true">Yahoo Inc.</organization>
        <address>
          <email>nvikram_imap@yahoo.com</email>
        </address>
      </author>
      <author initials="A." surname="Singh" fullname="Ashutosh Singh">
        <organization abbrev="Yahoo!" showOnFrontPage="true">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>
    </section>
  </back>
</rfc>
