<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" ipr="trust200902" docName="draft-ietf-extra-imap-list-metadata-05" number="9590" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" consensus="true" prepTime="2024-05-31T13:17:07" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-extra-imap-list-metadata-05" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9590" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="IMAP LIST-METADATA">IMAP Extension for Returning Mailbox METADATA in Extended LIST</title>
    <seriesInfo name="RFC" value="9590" stream="IETF"/>
    <author initials="K." surname="Murchison" fullname="Kenneth Murchison">
      <organization abbrev="Fastmail" showOnFrontPage="true">Fastmail US LLC</organization>
      <address>
        <postal>
          <street>1429 Walnut Street</street>
          <street>Suite 1201</street>
          <city>Philadelphia</city>
          <region>PA</region>
          <code>19102</code>
          <country>United States of America</country>
        </postal>
        <email>murch@fastmailteam.com</email>
      </address>
    </author>
    <author initials="B." surname="Gondwana" fullname="Bron Gondwana">
      <organization abbrev="Fastmail" showOnFrontPage="true">Fastmail Pty Ltd</organization>
      <address>
        <postal>
          <street>Level 2, 114 William Street</street>
          <city>Melbourne</city>
          <region>VIC</region>
          <code>3000</code>
          <country>Australia</country>
        </postal>
        <email>brong@fastmailteam.com</email>
      </address>
    </author>
    <date month="05" year="2024"/>
    <area>ART</area>
    <workgroup>extra</workgroup>
    <keyword>IMAP4</keyword>
    <keyword>LIST</keyword>
    <keyword>METADATA</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines an extension to the Internet Message Access  Protocol (IMAP) LIST
      command that allows the client to request mailbox annotations
      (metadata), along with other information typically returned by
      the LIST command.</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/rfc9590" 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>
      </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-conventions-used-in-this-do">Conventions Used in This Document</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-metadata-return-option-to-l">METADATA Return Option to LIST Command</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-examples">Examples</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-formal-syntax">Formal Syntax</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-security-considerations">Security 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-privacy-considerations">Privacy Considerations</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-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-of-imap-capabi">Registration of IMAP Capability LIST-METADATA</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-of-list-extend">Registration of LIST-EXTENDED Option METADATA</xref></t>
              </li>
            </ul>
          </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-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </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-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">Introduction</name>
      <t indent="0" pn="section-1-1">IMAP clients sometimes fetch mailbox metadata (e.g., color) to
      augment the display of mailboxes for the logged-in user.
      In order to do that, the client is 
      forced to issue a LIST or LSUB command to list all available
      mailboxes, followed by a GETMETADATA command for each mailbox
      found.  This document defines an extension to the IMAP LIST
      command that is identified by the capability string
      "LIST-METADATA".  The LIST-METADATA extension allows the client
      to request annotations on available mailboxes, along with other
      information typically returned by the LIST command.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>
      <t indent="0" pn="section-2-1">In examples, "C:" indicates lines sent by a client that is connected
      to a server.  "S:" indicates lines sent by the server to the
      client.</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">
    Long lines in examples are wrapped using "The Single Backslash Strategy" described in <xref target="RFC8792" format="default" sectionFormat="of" derivedContent="RFC8792"/>.
</t>
    </section>
    <section anchor="metadata" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-metadata-return-option-to-l">METADATA Return Option to LIST Command</name>
      <t indent="0" pn="section-3-1"><xref target="RFC5464" format="default" sectionFormat="of" derivedContent="RFC5464"/> defines the
      GETMETADATA command that is 
      used by an IMAP client to retrieve mailbox annotations.
      Sometimes,
      a client will have to look up the metadata for some or all of
      the mailboxes returned by the LIST command.  Doing so in
      multiple GETMETADATA commands wastes bandwidth and can degrade
      performance if the client does not pipeline the requests.</t>
      <t indent="0" pn="section-3-2">This document extends the LIST command with a new return option,
      "METADATA", which allows the client to request all of the
      desired information in a single command.  For each listable
      mailbox matching the list pattern and selection options, the
      server <bcp14>MUST</bcp14> return an untagged LIST response, followed by one or more
      untagged METADATA responses containing the mailbox annotations
      requested by the client.
      The untagged METADATA responses to an extended LIST command have
      the same syntax and semantics as those that would be returned by
      GETMETADATA commands on the same set of listable mailboxes
      (see <xref target="RFC5464" section="4.4.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc5464#section-4.4.1" derivedContent="RFC5464"/>).
      As per <xref target="RFC5464" section="4.4" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc5464#section-4.4" derivedContent="RFC5464"/>, the server may
      return all requested annotations in a single METADATA response
      for each mailbox, or it may split the requested annotations into
      multiple METADATA responses for each mailbox.</t>
      <t indent="0" pn="section-3-3">If the server is unable to look up the annotations for
      given mailbox, it <bcp14>MAY</bcp14> drop the corresponding METADATA response.
      In such a situation, the LIST command would still return a tagged
      OK reply.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-examples">Examples</name>
      <t indent="0" pn="section-4-1">The following are examples of fetching metadata from only 
      the top-level hierarchies of the mailbox using different
      sets of selection criteria
      (see <xref target="RFC9051" section="6.3.9" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9051#section-6.3.9" derivedContent="RFC9051"/>).</t>
      <t keepWithNext="true" indent="0" pn="section-4-2">
	In this example:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-3">
        <li pn="section-4-3.1">The "color" annotation for the "foo" mailbox has not been
        set, so the METADATA response has a value of "NIL" (i.e., has no
        value).</li>
        <li pn="section-4-3.2">"bar" has children, but isn't an actual mailbox itself,
        so it has no METADATA response.</li>
      </ul>
      <artwork name="" type="" align="left" alt="" pn="section-4-4">
========== NOTE: '\' line wrapping per RFC 8792 ===========

C: A00 CAPABILITY
S: * CAPABILITY IMAP4rev1 IMAP4rev2 \
                LIST-EXTENDED LIST-METADATA METADATA
S: A00 OK Completed.      
C: A01 LIST "" % \
            RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color"))
S: * LIST () "." "INBOX"
S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c")
S: * LIST () "." "foo"
S: * METADATA "foo" ("/shared/vendor/cmu/cyrus-imapd/color" NIL)
S: * LIST (\NonExistent) "." "bar"
S: A01 OK List completed.
</artwork>
      <t keepWithNext="true" indent="0" pn="section-4-5">
	  In this example, the LIST response for the "foo" mailbox is
          returned because it has matching children, but no METADATA
          response is returned because "foo" itself doesn't match the
          selection criteria.
      </t>
      <artwork name="" type="" align="left" alt="" pn="section-4-6">
========== NOTE: '\' line wrapping per RFC 8792 ===========

C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % \
            RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color"))
S: * LIST (\Subscribed) "." "INBOX"
S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c")
S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
S: A02 OK List completed.
</artwork>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-formal-syntax">Formal Syntax</name>
      <t indent="0" pn="section-5-1">The following syntax specification uses the Augmented Backus-Naur
      Form (ABNF) as described in <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/>.

      Note that "return-option" is defined in
      <xref target="RFC5258" format="default" sectionFormat="of" derivedContent="RFC5258"/> and "entry" is defined in
      <xref target="RFC5464" format="default" sectionFormat="of" derivedContent="RFC5464"/>.</t>
      <sourcecode type="abnf" markers="false" pn="section-5-2">
return-option =/ "METADATA" SP "(" entry *(SP entry) ")"
</sourcecode>
    </section>
    <section anchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">This specification does not introduce any additional security
      concerns beyond those described in
      <xref target="RFC5258" format="default" sectionFormat="of" derivedContent="RFC5258"/> and <xref target="RFC5464" format="default" sectionFormat="of" derivedContent="RFC5464"/>.</t>
    </section>
    <section anchor="privacy" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-7-1">This specification does not introduce any additional privacy
      concerns beyond those described in
      <xref target="RFC5464" format="default" sectionFormat="of" derivedContent="RFC5464"/>.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-registration-of-imap-capabi">Registration of IMAP Capability LIST-METADATA</name>
        <t indent="0" pn="section-8.1-1">Per this document, IANA has added the "LIST-METADATA" IMAP capability
        to the "IMAP Capabilities" registry located at <eref target="https://www.iana.org/assignments/imap4-capabilities/" brackets="angle"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-registration-of-list-extend">Registration of LIST-EXTENDED Option METADATA</name>
        <t indent="0" pn="section-8.2-1">Per this document, IANA has registered the "METADATA" LIST-EXTENDED option
        in the "LIST-EXTENDED options" registry located at
        <eref target="https://www.iana.org/assignments/imap-list-extended/" brackets="angle"/>.</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-8.2-2">
          <dt pn="section-8.2-2.1">LIST-EXTENDED option name:</dt>
          <dd pn="section-8.2-2.2">
	    METADATA
	  </dd>
          <dt pn="section-8.2-2.3">LIST-EXTENDED option type:</dt>
          <dd pn="section-8.2-2.4">
	    RETURN
	  </dd>
          <dt pn="section-8.2-2.5">LIST-EXTENDED option description:</dt>
          <dd pn="section-8.2-2.6">
	    Causes the LIST command to return METADATA responses in
            addition to LIST responses.
	  </dd>
          <dt pn="section-8.2-2.7">Published specification:</dt>
          <dd pn="section-8.2-2.8">
	    RFC 9590, <xref target="metadata" format="default" sectionFormat="of" derivedContent="Section 3"/>
          </dd>
          <dt pn="section-8.2-2.9">Security considerations:</dt>
          <dd pn="section-8.2-2.10">
	    RFC 9590, <xref target="security" format="default" sectionFormat="of" derivedContent="Section 6"/>
          </dd>
          <dt pn="section-8.2-2.11">Intended usage:</dt>
          <dd pn="section-8.2-2.12">
	    COMMON
	  </dd>
          <dt pn="section-8.2-2.13">Person and email address to contact for further information:</dt>
          <dd pn="section-8.2-2.14">
            <t indent="0" pn="section-8.2-2.14.1">
	    <contact fullname="Kenneth Murchison"/> &lt;murch@fastmailteam.com&gt; and
	    <contact fullname="Bron Gondwana"/> &lt;brong@fastmailteam.com&gt;</t>
          </dd>
          <dt pn="section-8.2-2.15">Owner/Change controller:</dt>
          <dd pn="section-8.2-2.16">
	    IESG &lt;iesg@ietf.org&gt;
	  </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.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="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="RFC5258" target="https://www.rfc-editor.org/info/rfc5258" quoteTitle="true" derivedAnchor="RFC5258">
          <front>
            <title>Internet Message Access Protocol version 4 - LIST Command Extensions</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="A. Melnikov" initials="A." surname="Melnikov"/>
            <date month="June" year="2008"/>
            <abstract>
              <t indent="0">IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5258"/>
          <seriesInfo name="DOI" value="10.17487/RFC5258"/>
        </reference>
        <reference anchor="RFC5464" target="https://www.rfc-editor.org/info/rfc5464" quoteTitle="true" derivedAnchor="RFC5464">
          <front>
            <title>The IMAP METADATA Extension</title>
            <author fullname="C. Daboo" initials="C." surname="Daboo"/>
            <date month="February" year="2009"/>
            <abstract>
              <t indent="0">The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5464"/>
          <seriesInfo name="DOI" value="10.17487/RFC5464"/>
        </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.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC8792" target="https://www.rfc-editor.org/info/rfc8792" quoteTitle="true" derivedAnchor="RFC8792">
          <front>
            <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="June" year="2020"/>
            <abstract>
              <t indent="0">This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8792"/>
          <seriesInfo name="DOI" value="10.17487/RFC8792"/>
        </reference>
      </references>
    </references>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="K." surname="Murchison" fullname="Kenneth Murchison">
        <organization abbrev="Fastmail" showOnFrontPage="true">Fastmail US LLC</organization>
        <address>
          <postal>
            <street>1429 Walnut Street</street>
            <street>Suite 1201</street>
            <city>Philadelphia</city>
            <region>PA</region>
            <code>19102</code>
            <country>United States of America</country>
          </postal>
          <email>murch@fastmailteam.com</email>
        </address>
      </author>
      <author initials="B." surname="Gondwana" fullname="Bron Gondwana">
        <organization abbrev="Fastmail" showOnFrontPage="true">Fastmail Pty Ltd</organization>
        <address>
          <postal>
            <street>Level 2, 114 William Street</street>
            <city>Melbourne</city>
            <region>VIC</region>
            <code>3000</code>
            <country>Australia</country>
          </postal>
          <email>brong@fastmailteam.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
