<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-extra-6855bis-04" number="9755" category="std" consensus="true" submissionType="IETF" xml:lang="en" tocInclude="true" obsoletes="6855" updates="" symRefs="true" sortRefs="true" prepTime="2025-03-16T23:57:48" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-extra-6855bis-04" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9755" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="UTF8=ACCEPT">IMAP Support for UTF-8</title>
    <seriesInfo name="RFC" value="9755" stream="IETF"/>
    <author initials="P." surname="Resnick" fullname="Pete Resnick">
      <organization abbrev="Episteme" showOnFrontPage="true">Episteme Technology Consulting LLC</organization>
      <address>
        <postal>
          <street>503 West Indiana Avenue</street>
          <city>Urbana</city>
          <region>IL</region>
          <code>61801-4941</code>
          <country>United States of America</country>
        </postal>
        <email>resnick@episteme.net</email>
      </address>
    </author>
    <author initials="J." surname="Yao" fullname="Jiankang Yao">
      <organization showOnFrontPage="true">CNNIC</organization>
      <address>
        <postal>
          <street>No.4 South 4th Zhongguancun Street</street>
          <city>Beijing</city>
          <code>100190</code>
          <country>China</country>
        </postal>
        <email>yaojk@cnnic.cn</email>
      </address>
    </author>
    <author initials="A." surname="Gulbrandsen" fullname="Arnt Gulbrandsen">
      <organization showOnFrontPage="true">ICANN</organization>
      <address>
        <postal>
          <street>6 Rond Point Schumann, Bd. 1</street>
          <city>Brussels</city>
          <code>1040</code>
          <country>Belgium</country>
        </postal>
        <email>arnt@gulbrandsen.priv.no</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>ART</area>
    <workgroup>extra</workgroup>
    <keyword>IMAP</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This specification extends the Internet Message Access
    Protocol, specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded international
    characters in user names, mail addresses, and message headers.  This
    specification replaces RFC 6855. This specification does not extend
    IMAP4rev2 (RFC 9051), since that protocol includes
    everything in this 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 is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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).  Further
            information on Internet Standards is available in 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/rfc9755" 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) 2025 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>
      </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">Introduction</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-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" 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-utf8accept-imap-capability-">"UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP Quoted-Strings</xref></t>
          </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-append-command">"APPEND" Command</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-login-command-and-utf-8">"LOGIN" Command and UTF-8</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-fetch-bodystructure-and-mes">FETCH BODYSTRUCTURE and message/global</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-utf8only-capability">"UTF8=ONLY" Capability</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-dealing-with-legacy-clients">Dealing with Legacy Clients</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-issues-with-utf-8-header-ma">Issues with UTF-8 Header Mailstore</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-design-rationale">Design Rationale</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-since-rfc-6855">Changes Since RFC 6855</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.14.2">
              <li pn="section-toc.1-1.14.2.1">
                <t indent="0" pn="section-toc.1-1.14.2.1.1"><xref derivedContent="B.1" format="counter" sectionFormat="of" target="section-appendix.b.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-append-utf8">APPEND UTF8</xref></t>
              </li>
              <li pn="section-toc.1-1.14.2.2">
                <t indent="0" pn="section-toc.1-1.14.2.2.1"><xref derivedContent="B.2" format="counter" sectionFormat="of" target="section-appendix.b.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fetch-bodystructure">FETCH BODYSTRUCTURE</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This specification forms part of the Email Address
Internationalization protocols described in the Email Address
Internationalization Framework document <xref target="RFC6530" format="default" sectionFormat="of" derivedContent="RFC6530"/>.  It extends IMAP
<xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> to permit UTF-8 <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/> in headers, as described in
"Internationalized Email Headers" <xref target="RFC6532" format="default" sectionFormat="of" derivedContent="RFC6532"/>.  It also adds a
mechanism to support mailbox names using the UTF-8 charset.  This
specification creates two new IMAP capabilities to allow servers to
advertise these new extensions.</t>
      <t indent="0" pn="section-1-2">This specification assumes that the IMAP server will be operating in
a fully internationalized environment, i.e., one in which all clients
accessing the server will be able to accept non-ASCII message header
fields and other information, as specified in <xref target="utf8accept-imap-capability-and-utf-8-in-imap-quoted-strings" format="default" sectionFormat="of" derivedContent="Section 3"/>.  At least
during a transition period, that assumption will not be realistic for
many environments; the issues involved are discussed in <xref target="utf8only-capability" format="default" sectionFormat="of" derivedContent="Section 7"/>
below.</t>
      <t indent="0" pn="section-1-3">This specification replaces an earlier, experimental approach to the
same problem; see <xref target="RFC5738" format="default" sectionFormat="of" derivedContent="RFC5738"/> as well as <xref target="RFC6855" format="default" sectionFormat="of" derivedContent="RFC6855"/>.</t>
    </section>
    <section anchor="requirements-language" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-1">
    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>
    </section>
    <section anchor="utf8accept-imap-capability-and-utf-8-in-imap-quoted-strings" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-utf8accept-imap-capability-">"UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP Quoted-Strings</name>
      <t indent="0" pn="section-3-1">The "UTF8=ACCEPT" capability indicates that the server supports the
ability to open mailboxes containing internationalized messages with
the "SELECT" and "EXAMINE" commands, and the server can provide UTF-8
responses to the "LIST" and "LSUB" commands.  This capability also
affects other IMAP extensions that can return mailbox names or their
prefixes, such as NAMESPACE <xref target="RFC2342" format="default" sectionFormat="of" derivedContent="RFC2342"/> and ACL <xref target="RFC4314" format="default" sectionFormat="of" derivedContent="RFC4314"/>.</t>
      <t indent="0" pn="section-3-2">The "UTF8=ONLY" capability, described in <xref target="utf8only-capability" format="default" sectionFormat="of" derivedContent="Section 7"/>, implies the
"UTF8=ACCEPT" capability.  A server is said to support "UTF8=ACCEPT"
if it advertises either "UTF8=ACCEPT" or "UTF8=ONLY".</t>
      <t indent="0" pn="section-3-3">A client <bcp14>MUST</bcp14> use the "ENABLE" command <xref target="RFC5161" format="default" sectionFormat="of" derivedContent="RFC5161"/> with the
"UTF8=ACCEPT" option (defined in <xref target="append-command" format="default" sectionFormat="of" derivedContent="Section 4"/> below) to indicate to the
server that the client accepts UTF-8 in quoted-strings and supports
the "UTF8=ACCEPT" extension.  The "ENABLE UTF8=ACCEPT" command is
only valid in the authenticated state.</t>
      <t indent="0" pn="section-3-4">The IMAP base specification <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> forbids the use of 8-bit
characters in atoms or quoted-strings.  Thus, a UTF-8 string can only
be sent as a literal.  This can be inconvenient from a coding
standpoint, and unless the server offers IMAP non-synchronizing
literals <xref target="RFC7888" format="default" sectionFormat="of" derivedContent="RFC7888"/>, this requires an extra round trip for each UTF-8
string sent by the client.  When the IMAP server supports
"UTF8=ACCEPT", it supports UTF-8 in quoted-strings with the following ABNF
syntax <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/>:</t>
      <sourcecode type="abnf" markers="false" pn="section-3-5">
      quoted        =/ DQUOTE *uQUOTED-CHAR DQUOTE
             ; QUOTED-CHAR is not modified, as it will affect
             ; other RFC 3501 ABNF non-terminals.

      uQUOTED-CHAR  = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4

      UTF8-2        =   &lt;Defined in Section 4 of RFC 3629&gt;

      UTF8-3        =   &lt;Defined in Section 4 of RFC 3629&gt;

      UTF8-4        =   &lt;Defined in Section 4 of RFC 3629&gt;
</sourcecode>
      <t indent="0" pn="section-3-6">When this extended quoting mechanism is used by the client, the
server <bcp14>MUST</bcp14> reject, with a "BAD" response, any octet sequences with
the high bit set that fail to comply with the formal syntax
requirements of UTF-8 <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/>.  The IMAP server <bcp14>MUST NOT</bcp14> send UTF-8
in quoted-strings to the client unless the client has indicated
support for that syntax by using the "ENABLE UTF8=ACCEPT" command.</t>
      <t indent="0" pn="section-3-7">If the server supports "UTF8=ACCEPT", the client <bcp14>MAY</bcp14> use extended
quoted syntax with any IMAP argument that permits a string (including
astring and nstring).  However, if characters outside the US-ASCII
repertoire are used in an inappropriate place, the results would be
the same as if other syntactically valid but semantically invalid
characters were used.  Specific cases where UTF-8 characters are
permitted or not permitted are described in the following paragraphs.</t>
      <t indent="0" pn="section-3-8">
  All IMAP servers that support "UTF8=ACCEPT" <bcp14>SHOULD</bcp14> accept UTF-8 in
  mailbox names, and those that also support the Mailbox International
  Naming Convention described in <xref section="5.1.3" sectionFormat="comma" target="RFC3501" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3501#section-5.1.3" derivedContent="RFC3501"/>, <bcp14>MUST</bcp14> accept
  UTF-8 in mailbox names and convert them to the appropriate
  internal format.
 Mailbox names <bcp14>MUST</bcp14> comply with the Net-Unicode
Definition (<xref section="2" sectionFormat="comma" target="RFC5198" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5198#section-2" derivedContent="RFC5198"/>) with the specific exception that
they <bcp14>MUST NOT</bcp14> contain control characters (U+0000 - U+001F and U+0080 - U+009F), a delete character (U+007F), a line separator (U+2028), or a
paragraph separator (U+2029).</t>
      <t indent="0" pn="section-3-9">
   Once an IMAP client has enabled UTF-8 support with the "ENABLE
   UTF8=ACCEPT" command, it <bcp14>MUST NOT</bcp14> issue a "SEARCH" command that
   contains a charset specification. If an IMAP server receives such a
   "SEARCH" command in that situation, it <bcp14>SHOULD</bcp14> reject the command with
   a "BAD" response (due to the conflicting charset labels). This also
   applies to any IMAP command or extension that includes an optional
   charset label and associated strings in the command arguments,
   including the MULTISEARCH extension. For commands with a mandatory
   charset field, such as SORT and THREAD, servers <bcp14>SHOULD</bcp14> reject charset
   values other than UTF-8 with a "BAD" response (due to the conflicting
   charset labels).
      </t>
    </section>
    <section anchor="append-command" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-append-command">"APPEND" Command</name>
      <t indent="0" pn="section-4-1">If the server supports "UTF8=ACCEPT", then the server accepts UTF-8
headers in the "APPEND" command message argument.</t>
      <t indent="0" pn="section-4-2">If an IMAP server supports "UTF8=ACCEPT" and the IMAP client has not
issued the "ENABLE UTF8=ACCEPT" command, the server <bcp14>MUST</bcp14> reject, with
a "NO" response, an "APPEND" command that includes any 8-bit
character in message header fields.</t>
    </section>
    <section anchor="login-command-and-utf-8" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-login-command-and-utf-8">"LOGIN" Command and UTF-8</name>
      <t indent="0" pn="section-5-1">This specification does not extend the IMAP "LOGIN" command <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/>
to support UTF-8 usernames and passwords.  Whenever a client needs to
use UTF-8 usernames or passwords, it <bcp14>MUST</bcp14> use the IMAP "AUTHENTICATE"
command, which is already capable of passing UTF-8 usernames and
credentials.</t>
      <t indent="0" pn="section-5-2">Although using the IMAP "AUTHENTICATE" command in this way makes it
syntactically legal to have a UTF-8 username or password, there is no
guarantee that the user provisioning system utilized by the IMAP
server will allow such identities.  This is an implementation
decision and may depend on what identity system the IMAP server is
configured to use.</t>
    </section>
    <section anchor="fetch-bodystructure-and-messageglobal" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-fetch-bodystructure-and-mes">FETCH BODYSTRUCTURE and message/global</name>
      <t indent="0" pn="section-6-1"><xref section="7.5.2" sectionFormat="comma" target="RFC9051" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9051#section-7.5.2" derivedContent="RFC9051"/> treats message/global like message/rfc,
which means that for some messages, the response to FETCH
BODYSTRUCTURE varies depending on whether IMAP4rev1 or IMAP4rev2 is
in use.</t>
      <t indent="0" pn="section-6-2"><xref target="RFC6855" format="default" sectionFormat="of" derivedContent="RFC6855"/> does not extend <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> in this respect. This document
extends the media-message ABNF production to match <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>.</t>
      <sourcecode type="abnf" markers="false" pn="section-6-3">
      media-message   = DQUOTE "MESSAGE" DQUOTE SP
                        DQUOTE ("RFC822" / "GLOBAL") DQUOTE
</sourcecode>
      <t indent="0" pn="section-6-4">When IMAP4rev1 and UTF8=ACCEPT has been enabled, the server <bcp14>MAY</bcp14> treat
message/global like message/rfc822 when computing the body structure,
but <bcp14>MAY</bcp14> also treat it as described in <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/>. Clients <bcp14>MUST</bcp14> accept
both cases.</t>
      <t indent="0" pn="section-6-5">When IMAP4rev2 and UTF8=ACCEPT are in use, the server <bcp14>MUST</bcp14> behave as
described in <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>.</t>
    </section>
    <section anchor="utf8only-capability" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-utf8only-capability">"UTF8=ONLY" Capability</name>
      <t indent="0" pn="section-7-1">The "UTF8=ONLY" capability indicates that the server supports
"UTF8=ACCEPT" (see <xref target="utf8accept-imap-capability-and-utf-8-in-imap-quoted-strings" format="default" sectionFormat="of" derivedContent="Section 3"/>) and that it requires support for UTF-8
from clients.  In particular, this means that the server will send
UTF-8 in quoted-strings, and it will not accept the older
international mailbox name convention (modified UTF-7 <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/>).
Because these are incompatible changes to IMAP, explicit server
announcement and client confirmation are necessary: clients <bcp14>MUST</bcp14> use
the "ENABLE UTF8=ACCEPT" command before using this server.  A server
that advertises "UTF8=ONLY" will reject, with a "NO [CANNOT]"
response <xref target="RFC5530" format="default" sectionFormat="of" derivedContent="RFC5530"/>, any command that might require UTF-8 support and
is not preceded by an "ENABLE UTF8=ACCEPT" command.</t>
      <t indent="0" pn="section-7-2">IMAP clients that find support for a server that announces
"UTF8=ONLY" problematic are encouraged to at least detect the
announcement and provide an informative error message to the
end user.</t>
      <t indent="0" pn="section-7-3">Because the "UTF8=ONLY" server capability includes support for
"UTF8=ACCEPT", the capability string will include, at most, one of
those and never both.  For the client, "ENABLE UTF8=ACCEPT" is always
used -- never "ENABLE UTF8=ONLY".</t>
    </section>
    <section anchor="dealing-with-legacy-clients" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-dealing-with-legacy-clients">Dealing with Legacy Clients</name>
      <t indent="0" pn="section-8-1">In most situations, it will be difficult or impossible for the
implementer or operator of an IMAP (or POP) server to know whether
all of the clients that might access it, or the associated mail store
more generally, will be able to support the facilities defined in
this document.  In almost all cases, servers that conform to this
specification will have to be prepared to deal with clients that do
not enable the relevant capabilities.  Unfortunately, there is no
completely satisfactory way to do so other than for systems that wish
to receive email that requires SMTPUTF8 capabilities to be sure that
all components of those systems -- including IMAP and other clients
selected by users -- are upgraded appropriately.</t>
      <t indent="0" pn="section-8-2">When a message that requires SMTPUTF8 is encountered and the client
does not enable UTF-8 capability, choices available to the server
include hiding the problematic message(s), creating in-band or
out-of-band notifications or error messages, or somehow trying to
create a surrogate of the message with the intention of providing
useful information to that client about what has occurred.  Such
surrogate messages cannot be actual substitutes for the original
message: they will almost always be impossible to reply to (either at
all or without loss of information) and the new header fields or
specialized constructs for server-client communications may go beyond
the requirements of current email specifications (e.g., <xref target="RFC5322" format="default" sectionFormat="of" derivedContent="RFC5322"/>).
Consequently, such messages may confuse some legacy mail user agents
(including IMAP clients) or not provide expected information to
users.  There are also trade-offs in constructing surrogates of the
original message between accepting complexity and additional
computation costs in order to try to preserve as much information as
possible (for example, in "Post-Delivery Message Downgrading for
Internationalized Email Messages" <xref target="RFC6857" format="default" sectionFormat="of" derivedContent="RFC6857"/>) and trying to minimize
those costs while still providing useful information (for example, in
"Simplified POP and IMAP Downgrading for Internationalized Email"
<xref target="RFC6858" format="default" sectionFormat="of" derivedContent="RFC6858"/>).</t>
      <t indent="0" pn="section-8-3">Implementations that choose to perform downgrading <bcp14>SHOULD</bcp14> use one of
the standardized algorithms provided in <xref target="RFC6857" format="default" sectionFormat="of" derivedContent="RFC6857"/> or <xref target="RFC6858" format="default" sectionFormat="of" derivedContent="RFC6858"/>.
Getting downgrade algorithms right, and minimizing the risk of
operational problems and harm to the email system, is tricky and
requires careful engineering.  These two algorithms are well
understood and carefully designed.</t>
      <t indent="0" pn="section-8-4">Because such messages are really surrogates of the original ones, not
really "downgraded" ones (although that terminology is often used for
convenience), they inevitably have relationships to the originals
that the IMAP specification <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> did not anticipate.  This
brings up two concerns in particular: First, digital signatures
computed over and intended for the original message will often not be
applicable to the surrogate message, and will often fail signature
verification.  (It will be possible for some digital signatures to be
verified, if they cover only parts of the original message that are
not affected in the creation of the surrogate.)  Second, servers that
may be accessed by the same user with different clients or methods
(e.g., POP or webmail systems in addition to IMAP or IMAP clients
with different capabilities) will need to exert extreme care to be
sure that UIDVALIDITY <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> behaves as the user would expect.
Those issues may be especially sensitive if the server caches the
surrogate message or computes and stores it when the message arrives
with the intent of making either form available depending on client
capabilities.  Additionally, in order to cope with the case when a
server compliant with this extension returns the same UIDVALIDITY to
both legacy and "UTF8=ACCEPT"-aware clients, a client upgraded from
being non-"UTF8=ACCEPT"-aware <bcp14>MUST</bcp14> discard its cache of messages
downloaded from the server.</t>
      <t indent="0" pn="section-8-5">The best (or "least bad") approach for any given environment will
depend on local conditions, local assumptions about user behavior,
the degree of control the server operator has over client usage and
upgrading, the options that are actually available, and so on.  It is
impossible, at least at the time of publication of this
specification, to give good advice that will apply to all situations,
or even particular profiles of situations, other than "upgrade legacy
clients as soon as possible".</t>
    </section>
    <section anchor="issues-with-utf-8-header-mailstore" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-issues-with-utf-8-header-ma">Issues with UTF-8 Header Mailstore</name>
      <t indent="0" pn="section-9-1">When an IMAP server uses a mailbox format that supports UTF-8 headers
and it permits selection or examination of that mailbox without
issuing "ENABLE UTF8=ACCEPT" first, it is the responsibility of the
server to comply with the IMAP base specification <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> and the
Internet Message Format <xref target="RFC5322" format="default" sectionFormat="of" derivedContent="RFC5322"/> with respect to all header
information transmitted over the wire.  The issue of handling
messages containing non-ASCII characters in legacy environments is
discussed in <xref target="dealing-with-legacy-clients" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
    </section>
    <section anchor="IANA" numbered="true" removeInRFC="false" toc="include" pn="section-10">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-10-1">the "IMAP Capabilities" registry contained a number of references to
<xref target="RFC6855" format="default" sectionFormat="of" derivedContent="RFC6855"/>. IANA has updated them point to this document instead. The affected references are:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-10-2">
        <li pn="section-10-2.1">
          <t indent="0" pn="section-10-2.1.1">UTF8=ACCEPT</t>
        </li>
        <li pn="section-10-2.2">
          <t indent="0" pn="section-10-2.2.1">UTF8=ALL (OBSOLETE)</t>
        </li>
        <li pn="section-10-2.3">
          <t indent="0" pn="section-10-2.3.1">UTF8=APPEND (OBSOLETE)</t>
        </li>
        <li pn="section-10-2.4">
          <t indent="0" pn="section-10-2.4.1">UTF8=ONLY</t>
        </li>
        <li pn="section-10-2.5">
          <t indent="0" pn="section-10-2.5.1">UTF8=USER (OBSOLETE)</t>
        </li>
      </ul>
    </section>
    <section anchor="SECURITY" numbered="true" removeInRFC="false" toc="include" pn="section-11">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-11-1">The security considerations of UTF-8 <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/> and PRECIS Usernames and Passwords <xref target="RFC8265" format="default" sectionFormat="of" derivedContent="RFC8265"/> apply to this specification, particularly with respect to
use of UTF-8 in usernames and passwords.  Otherwise, this is not
believed to alter the security considerations of IMAP.</t>
      <t indent="0" pn="section-11-2">Special considerations, some of them with security implications, occur
if a server that conforms to this specification is accessed by a
client that does not, as well as in some more complex situations in
which a given message is accessed by multiple clients that might use
different protocols and/or support different capabilities.  Those
issues are discussed in <xref target="dealing-with-legacy-clients" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references" pn="section-12">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-12.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <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="RFC3629" target="https://www.rfc-editor.org/info/rfc3629" quoteTitle="true" derivedAnchor="RFC3629">
          <front>
            <title>UTF-8, a transformation format of ISO 10646</title>
            <author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
            <date month="November" year="2003"/>
            <abstract>
              <t indent="0">ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="63"/>
          <seriesInfo name="RFC" value="3629"/>
          <seriesInfo name="DOI" value="10.17487/RFC3629"/>
        </reference>
        <reference anchor="RFC5161" target="https://www.rfc-editor.org/info/rfc5161" quoteTitle="true" derivedAnchor="RFC5161">
          <front>
            <title>The IMAP ENABLE Extension</title>
            <author fullname="A. Gulbrandsen" initials="A." role="editor" surname="Gulbrandsen"/>
            <author fullname="A. Melnikov" initials="A." role="editor" surname="Melnikov"/>
            <date month="March" year="2008"/>
            <abstract>
              <t indent="0">Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5161"/>
          <seriesInfo name="DOI" value="10.17487/RFC5161"/>
        </reference>
        <reference anchor="RFC5198" target="https://www.rfc-editor.org/info/rfc5198" quoteTitle="true" derivedAnchor="RFC5198">
          <front>
            <title>Unicode Format for Network Interchange</title>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <author fullname="M. Padlipsky" initials="M." surname="Padlipsky"/>
            <date month="March" year="2008"/>
            <abstract>
              <t indent="0">The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5198"/>
          <seriesInfo name="DOI" value="10.17487/RFC5198"/>
        </reference>
        <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" quoteTitle="true" derivedAnchor="RFC5234">
          <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="RFC5322" target="https://www.rfc-editor.org/info/rfc5322" quoteTitle="true" derivedAnchor="RFC5322">
          <front>
            <title>Internet Message Format</title>
            <author fullname="P. Resnick" initials="P." role="editor" surname="Resnick"/>
            <date month="October" year="2008"/>
            <abstract>
              <t indent="0">This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5322"/>
          <seriesInfo name="DOI" value="10.17487/RFC5322"/>
        </reference>
        <reference anchor="RFC6530" target="https://www.rfc-editor.org/info/rfc6530" quoteTitle="true" derivedAnchor="RFC6530">
          <front>
            <title>Overview and Framework for Internationalized Email</title>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <author fullname="Y. Ko" initials="Y." surname="Ko"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6530"/>
          <seriesInfo name="DOI" value="10.17487/RFC6530"/>
        </reference>
        <reference anchor="RFC6532" target="https://www.rfc-editor.org/info/rfc6532" quoteTitle="true" derivedAnchor="RFC6532">
          <front>
            <title>Internationalized Email Headers</title>
            <author fullname="A. Yang" initials="A." surname="Yang"/>
            <author fullname="S. Steele" initials="S." surname="Steele"/>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.</t>
              <t indent="0">This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6532"/>
          <seriesInfo name="DOI" value="10.17487/RFC6532"/>
        </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="RFC8265" target="https://www.rfc-editor.org/info/rfc8265" quoteTitle="true" derivedAnchor="RFC8265">
          <front>
            <title>Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="A. Melnikov" initials="A." surname="Melnikov"/>
            <date month="October" year="2017"/>
            <abstract>
              <t indent="0">This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8265"/>
          <seriesInfo name="DOI" value="10.17487/RFC8265"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-12.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC2342" target="https://www.rfc-editor.org/info/rfc2342" quoteTitle="true" derivedAnchor="RFC2342">
          <front>
            <title>IMAP4 Namespace</title>
            <author fullname="M. Gahrns" initials="M." surname="Gahrns"/>
            <author fullname="C. Newman" initials="C." surname="Newman"/>
            <date month="May" year="1998"/>
            <abstract>
              <t indent="0">This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2342"/>
          <seriesInfo name="DOI" value="10.17487/RFC2342"/>
        </reference>
        <reference anchor="RFC4314" target="https://www.rfc-editor.org/info/rfc4314" quoteTitle="true" derivedAnchor="RFC4314">
          <front>
            <title>IMAP4 Access Control List (ACL) Extension</title>
            <author fullname="A. Melnikov" initials="A." surname="Melnikov"/>
            <date month="December" year="2005"/>
            <abstract>
              <t indent="0">The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol.</t>
              <t indent="0">This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4314"/>
          <seriesInfo name="DOI" value="10.17487/RFC4314"/>
        </reference>
        <reference anchor="RFC5530" target="https://www.rfc-editor.org/info/rfc5530" quoteTitle="true" derivedAnchor="RFC5530">
          <front>
            <title>IMAP Response Codes</title>
            <author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/>
            <date month="May" year="2009"/>
            <abstract>
              <t indent="0">IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.</t>
              <t indent="0">This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5530"/>
          <seriesInfo name="DOI" value="10.17487/RFC5530"/>
        </reference>
        <reference anchor="RFC5738" target="https://www.rfc-editor.org/info/rfc5738" quoteTitle="true" derivedAnchor="RFC5738">
          <front>
            <title>IMAP Support for UTF-8</title>
            <author fullname="P. Resnick" initials="P." surname="Resnick"/>
            <author fullname="C. Newman" initials="C." surname="Newman"/>
            <date month="March" year="2010"/>
            <abstract>
              <t indent="0">This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5738"/>
          <seriesInfo name="DOI" value="10.17487/RFC5738"/>
        </reference>
        <reference anchor="RFC6855" target="https://www.rfc-editor.org/info/rfc6855" quoteTitle="true" derivedAnchor="RFC6855">
          <front>
            <title>IMAP Support for UTF-8</title>
            <author fullname="P. Resnick" initials="P." role="editor" surname="Resnick"/>
            <author fullname="C. Newman" initials="C." role="editor" surname="Newman"/>
            <author fullname="S. Shen" initials="S." role="editor" surname="Shen"/>
            <date month="March" year="2013"/>
            <abstract>
              <t indent="0">This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6855"/>
          <seriesInfo name="DOI" value="10.17487/RFC6855"/>
        </reference>
        <reference anchor="RFC6857" target="https://www.rfc-editor.org/info/rfc6857" quoteTitle="true" derivedAnchor="RFC6857">
          <front>
            <title>Post-Delivery Message Downgrading for Internationalized Email Messages</title>
            <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
            <date month="March" year="2013"/>
            <abstract>
              <t indent="0">The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6857"/>
          <seriesInfo name="DOI" value="10.17487/RFC6857"/>
        </reference>
        <reference anchor="RFC6858" target="https://www.rfc-editor.org/info/rfc6858" quoteTitle="true" derivedAnchor="RFC6858">
          <front>
            <title>Simplified POP and IMAP Downgrading for Internationalized Email</title>
            <author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/>
            <date month="March" year="2013"/>
            <abstract>
              <t indent="0">This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6858"/>
          <seriesInfo name="DOI" value="10.17487/RFC6858"/>
        </reference>
        <reference anchor="RFC7888" target="https://www.rfc-editor.org/info/rfc7888" quoteTitle="true" derivedAnchor="RFC7888">
          <front>
            <title>IMAP4 Non-synchronizing Literals</title>
            <author fullname="A. Melnikov" initials="A." role="editor" surname="Melnikov"/>
            <date month="May" year="2016"/>
            <abstract>
              <t indent="0">The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip.</t>
              <t indent="0">This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.</t>
              <t indent="0">This document obsoletes RFC 2088.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7888"/>
          <seriesInfo name="DOI" value="10.17487/RFC7888"/>
        </reference>
        <reference anchor="RFC8620" target="https://www.rfc-editor.org/info/rfc8620" quoteTitle="true" derivedAnchor="RFC8620">
          <front>
            <title>The JSON Meta Application Protocol (JMAP)</title>
            <author fullname="N. Jenkins" initials="N." surname="Jenkins"/>
            <author fullname="C. Newman" initials="C." surname="Newman"/>
            <date month="July" year="2019"/>
            <abstract>
              <t indent="0">This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8620"/>
          <seriesInfo name="DOI" value="10.17487/RFC8620"/>
        </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>
    <section anchor="design-rationale" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-design-rationale">Design Rationale</name>
      <t indent="0" pn="section-appendix.a-1">This non-normative section discusses the reasons behind some of the
design choices in this specification.</t>
      <t indent="0" pn="section-appendix.a-2">The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability
problems when legacy support goes away.  In the situation where
backwards compatibility is not working anyway, the non-conforming
"just-send-UTF-8 IMAP" has the advantage that it might work with some
legacy clients.  However, the difficulty of diagnosing
interoperability problems caused by a "just-send-UTF-8 IMAP" mechanism
is the reason the "UTF8=ONLY" capability mechanism was chosen.</t>
    </section>
    <section anchor="changes-since-rfc-6855" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-changes-since-rfc-6855">Changes Since RFC 6855</name>
      <t indent="0" pn="section-appendix.b-1">This non-normative section describes the changes made since
<xref target="RFC6855" format="default" sectionFormat="of" derivedContent="RFC6855"/>.</t>
      <section anchor="append-utf8" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.1">
        <name slugifiedName="name-append-utf8">APPEND UTF8</name>
        <t indent="0" pn="section-appendix.b.1-1">This document removes APPEND's UTF8 data item, making the UTF8-related
syntax compatible with IMAP4rev2 as defined by <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/> and making
it simpler for clients to support IMAP4rev1 and IMAP4rev2 with the
same code.</t>
        <t indent="0" pn="section-appendix.b.1-2">IMAP4rev2 <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/> provides roughly the same abilities as
<xref target="RFC6855" format="default" sectionFormat="of" derivedContent="RFC6855"/> but does not include APPEND's UTF8 item. None of
<xref target="RFC6855" format="default" sectionFormat="of" derivedContent="RFC6855"/>, IMAP4rev2, or JMAP <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/> specify any way to learn
whether a particular message was stored using the UTF8 data item. As
of today, an IMAP client cannot learn whether a particular message was
stored using the UTF8 data item, nor would it be able to trust that
information even if IMAP4rev1 and 2 were extended to provide that
information.</t>
        <t indent="0" pn="section-appendix.b.1-3">In July 2023, one of the authors found only one IMAP client that uses
the UTF8 data item, and that client uses it incorrectly (it sends the
data item for all messages if the server supports UTF8=ACCEPT, without
regard to whether a particular message includes any UTF8 at all).</t>
        <t indent="0" pn="section-appendix.b.1-4">For these reasons, it was judged best to revise <xref target="RFC6855" format="default" sectionFormat="of" derivedContent="RFC6855"/> and adopt
the same syntax as IMAP4rev2.</t>
      </section>
      <section anchor="fetch-bodystructure" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.2">
        <name slugifiedName="name-fetch-bodystructure">FETCH BODYSTRUCTURE</name>
        <t indent="0" pn="section-appendix.b.2-1"><xref target="RFC6532" format="default" sectionFormat="of" derivedContent="RFC6532"/> defines a new media type, message/global, which is
substantially like message/rfc822 except that the submessage may
(also) use the syntax defined in <xref target="RFC6532" format="default" sectionFormat="of" derivedContent="RFC6532"/>. <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> and
<xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/> define a FETCH item to return the MIME structure of a message, which servers usually compute once and store.</t>
        <t indent="0" pn="section-appendix.b.2-2">None of the RFCs point out to implementers that IMAP4rev1 and
IMAP4rev2 are slightly different, so storing the BODYSTRUCTURE in the
way servers and clients often do can easily lead to problems.</t>
        <t indent="0" pn="section-appendix.b.2-3">This document makes the syntax optional, making it simple for server
authors to implement this extension correctly. This implies that
clients need to parse and handle both varieties, which they need to do
anyway if they want to support both IMAP4rev1 and IMAP4rev2.</t>
      </section>
    </section>
    <section anchor="acknowledgments" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.c-1">This document is an almost unchanged copy of <xref target="RFC6855" format="default" sectionFormat="of" derivedContent="RFC6855"/>, which was written by <contact fullname="Pete       Resnick"/>, <contact fullname="Chris Newman"/>, and <contact fullname="Sean Shen"/>. Sean has since changed jobs and the current
      authors do not have a new email address for him. We cannot be sure that
      he would approve of the changes in this document, so we did not list him
      as author, but do gratefully acknowledge his work on <xref target="RFC6855" format="default" sectionFormat="of" derivedContent="RFC6855"/>. <contact fullname="Jiankang Yao"/> replaces him.</t>
      <t indent="0" pn="section-appendix.c-2">The next paragraph is a straight copy of the acknowledgments in <xref target="RFC6855" format="default" sectionFormat="of" derivedContent="RFC6855"/>:</t>
      <blockquote pn="section-appendix.c-3">
        <t indent="0" pn="section-appendix.c-3.1">The authors wish to thank the participants of the EAI working group
      for their contributions to this document, with particular thanks to
      <contact fullname="Harald Alvestrand"/>, <contact fullname="David       Black"/>, <contact fullname="Randall Gellens"/>, <contact fullname="Arnt       Gulbrandsen"/>, <contact fullname="Kari Hurtta"/>, <contact fullname="John Klensin"/>, <contact fullname="Xiaodong Lee"/>, <contact fullname="Charles Lindsey"/>, <contact fullname="Alexey Melnikov"/>,
      <contact fullname="Subramanian Moonesamy"/>, <contact fullname="Shawn       Steele"/>, <contact fullname="Daniel Taharlev"/>, and <contact fullname="Joseph Yee"/> for their specific contributions to the
      discussion.</t>
      </blockquote>
      <t indent="0" pn="section-appendix.c-4">Many of them also reread the document during this revision.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="P." surname="Resnick" fullname="Pete Resnick">
        <organization abbrev="Episteme" showOnFrontPage="true">Episteme Technology Consulting LLC</organization>
        <address>
          <postal>
            <street>503 West Indiana Avenue</street>
            <city>Urbana</city>
            <region>IL</region>
            <code>61801-4941</code>
            <country>United States of America</country>
          </postal>
          <email>resnick@episteme.net</email>
        </address>
      </author>
      <author initials="J." surname="Yao" fullname="Jiankang Yao">
        <organization showOnFrontPage="true">CNNIC</organization>
        <address>
          <postal>
            <street>No.4 South 4th Zhongguancun Street</street>
            <city>Beijing</city>
            <code>100190</code>
            <country>China</country>
          </postal>
          <email>yaojk@cnnic.cn</email>
        </address>
      </author>
      <author initials="A." surname="Gulbrandsen" fullname="Arnt Gulbrandsen">
        <organization showOnFrontPage="true">ICANN</organization>
        <address>
          <postal>
            <street>6 Rond Point Schumann, Bd. 1</street>
            <city>Brussels</city>
            <code>1040</code>
            <country>Belgium</country>
          </postal>
          <email>arnt@gulbrandsen.priv.no</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
