<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-extra-quota-10" indexInclude="true" ipr="pre5378Trust200902" number="9208" obsoletes="2087" prepTime="2022-03-31T14:08:50" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-extra-quota-10" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9208" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="IMAP QUOTA">IMAP QUOTA Extension</title>
    <seriesInfo name="RFC" value="9208" stream="IETF"/>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization abbrev="Isode" showOnFrontPage="true">Isode Limited</organization>
      <address>
        <email>alexey.melnikov@isode.com</email>
        <uri>https://www.isode.com</uri>
      </address>
    </author>
    <date month="03" year="2022"/>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines a QUOTA extension of the Internet Message
      Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits administrative limits
      on resource usage (quotas) to be manipulated through the IMAP
      protocol.</t>
      <t indent="0" pn="section-abstract-2">This document obsoletes RFC 2087 but attempts to remain backwards
      compatible whenever possible.</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/rfc9208" 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) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
        <t indent="0" pn="section-boilerplate.2-3">
            This document may contain material from IETF Documents or IETF
            Contributions published or made publicly available before November
            10, 2008. The person(s) controlling the copyright in some of this
            material may not have granted the IETF Trust the right to allow
            modifications of such material outside the IETF Standards Process.
            Without obtaining an adequate license from the person(s)
            controlling the copyright in such materials, this document may not
            be modified outside the IETF Standards Process, and derivative
            works of it may not be created outside the IETF Standards Process,
            except to format it for publication as an RFC or to translate it
            into languages other than English.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction-and-overview">Introduction and Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-document-conventions">Document Conventions</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terms">Terms</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-resource">Resource</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.1.2">
                  <li pn="section-toc.1-1.3.2.1.2.1">
                    <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.2.1.1"><xref derivedContent="3.1.1" format="counter" sectionFormat="of" target="section-3.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-name">Name</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.1.2.2.1"><xref derivedContent="3.1.2" format="counter" sectionFormat="of" target="section-3.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-definition">Definition</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-quota-root">Quota Root</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-definitions">Definitions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-commands">Commands</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-getquota">GETQUOTA</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-getquotaroot">GETQUOTAROOT</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.3.1"><xref derivedContent="4.1.3" format="counter" sectionFormat="of" target="section-4.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-setquota">SETQUOTA</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.4.1"><xref derivedContent="4.1.4" format="counter" sectionFormat="of" target="section-4.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-status-attributes">New STATUS attributes</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-responses">Responses</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-quota">QUOTA</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-quotaroot">QUOTAROOT</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-response-codes">Response Codes</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overquota">OVERQUOTA</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </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-resource-type-definitions">Resource Type Definitions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-storage">STORAGE</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-message">MESSAGE</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mailbox">MAILBOX</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-annotation-storage">ANNOTATION-STORAGE</xref></t>
              </li>
            </ul>
          </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-interaction-with-imap-acl-e">Interaction with IMAP ACL Extension (RFC 4314)</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-formal-syntax">Formal Syntax</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-security-considerations">Security Considerations</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-iana-considerations">IANA Considerations</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-changes-additions-to-the-im">Changes/Additions to the IMAP Capabilities Registry</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-imap-quota-resource-type-re">IMAP Quota Resource Type Registry</xref></t>
              </li>
            </ul>
          </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-changes-since-rfc-2087">Changes Since RFC 2087</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-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction-and-overview">Introduction and Overview</name>
      <t indent="0" pn="section-1-1">This document defines a couple of extensions to the Internet Message
      Access Protocol <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/> for querying
      and manipulating administrative limits on resource usage (quotas).  This
      extension is compatible with both IMAP4rev1 <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> and IMAP4rev2 <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>.</t>
      <t indent="0" pn="section-1-2">The "QUOTA" capability denotes a server compliant with <xref target="RFC2087" format="default" sectionFormat="of" derivedContent="RFC2087"/>.  Some responses and response codes
      defined in this document are not present in such servers (see <xref target="changes-since" format="default" sectionFormat="of" derivedContent="Section 10"/> for more details), and clients
      <bcp14>MUST NOT</bcp14> rely on their presence in the absence of any
      capability beginning with "QUOTA=".</t>
      <t indent="0" pn="section-1-3">Any server compliant with this document <bcp14>MUST</bcp14> also
      return at least one capability starting with the "QUOTA=RES-" prefix, as
      described in <xref target="Quota-Resource" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.</t>
      <t indent="0" pn="section-1-4">Any server compliant with this document that implements the SETQUOTA
      command (see <xref target="SETQUOTA" format="default" sectionFormat="of" derivedContent="Section 4.1.3"/>)
      <bcp14>MUST</bcp14> also return the "QUOTASET" capability.
      </t>
      <t indent="0" pn="section-1-5">This document also reserves all other capabilities starting with the
      "QUOTA=" prefix for future IETF Stream Standard Track, Informational, or
      Experimental extensions to this document.</t>
      <t indent="0" pn="section-1-6">Quotas can be used to restrict clients for administrative reasons,
      but the QUOTA extension can also be used to indicate system limits and
      current usage levels to clients.</t>
      <t indent="0" pn="section-1-7">Although the IMAP4 QUOTA extension specified in <xref target="RFC2087" format="default" sectionFormat="of" derivedContent="RFC2087"/> has seen deployment in servers, it has
      seen little deployment in clients.  Since the meaning of the resources
      was implementation dependent, it was impossible for a client
      implementation to determine which resources were supported, and it was
      impossible to determine which mailboxes were in a given quota root (see
      <xref target="quota-root" format="default" sectionFormat="of" derivedContent="Section 3.2"/>) without a priori knowledge
      of the implementation.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-document-conventions">Document Conventions</name>
      <t indent="0" pn="section-2-1">In protocol examples, this document uses a prefix of "C: " to denote
      lines sent by the client to the server and "S: " for lines sent by the
      server to the client. Lines prefixed with "//" are comments explaining
      the previous protocol line.  These prefixes and comments are not part of
      the protocol. Lines without any of these prefixes are continuations of
      the previous line, and no line break is present in the protocol before
      such lines unless specifically mentioned.</t>
      <t indent="0" pn="section-2-2">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
      </t>
      <t indent="0" pn="section-2-3">Other capitalized words are IMAP keywords <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/> or keywords
      from this document.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-terms">Terms</name>
      <section anchor="Quota-Resource" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-resource">Resource</name>
        <t indent="0" pn="section-3.1-1">A resource has a name, a formal definition.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-3.1.1">
          <name slugifiedName="name-name">Name</name>
          <t indent="0" pn="section-3.1.1-1">The resource name is an atom, as defined in <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501">IMAP4rev1</xref>. These
          <bcp14>MUST</bcp14> be registered with IANA.</t>
          <t indent="0" pn="section-3.1.1-2">Supported resource names <bcp14>MUST</bcp14> be advertised as a
          capability by prepending the resource name with "QUOTA=RES-".  A
          server compliant with this specification is not required to support
          all reported resource types on all quota roots.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-3.1.2">
          <name slugifiedName="name-definition">Definition</name>
          <t indent="0" pn="section-3.1.2-1">The resource definition or document containing it, while not
          visible through the protocol, <bcp14>SHOULD</bcp14> be registered
          with IANA.</t>
          <t indent="0" pn="section-3.1.2-2">The usage of a resource <bcp14>MUST</bcp14> be represented as a
          63-bit unsigned integer.  0 indicates that the resource is
          exhausted.  Usage integers don't necessarily represent proportional
          use, so clients <bcp14>MUST NOT</bcp14> compare an available resource
          between two separate quota roots on the same or different
          servers.</t>
          <t indent="0" pn="section-3.1.2-3">Limits will be specified as, and <bcp14>MUST</bcp14> be
          represented as, an integer. 0 indicates that any usage is
          prohibited.</t>
          <t indent="0" pn="section-3.1.2-4">Limits may be hard or soft; that is, an implementation
          <bcp14>MAY</bcp14> choose, or be configured, to disallow any command
          if the limit on a resource is or would be exceeded.</t>
          <t indent="0" pn="section-3.1.2-5">All resources that the server handles <bcp14>MUST</bcp14> be
          advertised in a CAPABILITY response/response code consisting of the
          resource name prefixed by "QUOTA=RES-".
          </t>
          <t indent="0" pn="section-3.1.2-6">The resources <xref target="STORAGE" format="default" sectionFormat="of" derivedContent="Section 5.1">STORAGE</xref>, <xref target="MESSAGE" format="default" sectionFormat="of" derivedContent="Section 5.2">MESSAGE</xref>, <xref target="MAILBOX" format="default" sectionFormat="of" derivedContent="Section 5.3">MAILBOX</xref>, and <xref target="ANNOTATION-STORAGE" format="default" sectionFormat="of" derivedContent="Section 5.4">ANNOTATION-STORAGE</xref> are defined in this
          document.</t>
        </section>
      </section>
      <section anchor="quota-root" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-quota-root">Quota Root</name>
        <t indent="0" pn="section-3.2-1">This document introduces the concept of a "quota root", as resource
        limits can apply across multiple IMAP mailboxes.</t>
        <t indent="0" pn="section-3.2-2">Each mailbox has zero or more implementation-defined named "quota
        roots".  Each quota root has zero or more resource limits
        (quotas). All mailboxes that share the same named quota root share the
        resource limits of the quota root.</t>
        <t indent="0" pn="section-3.2-3">Quota root names need not be mailbox names, nor is there any
        relationship defined by this document between a quota root name and a
        mailbox name. A quota root name is an astring, as defined in <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501">IMAP4</xref> <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>. It <bcp14>SHOULD</bcp14> be treated as an opaque string by any
        clients.</t>
        <t indent="0" pn="section-3.2-4">Quota roots are used since not all implementations may be able to
	calculate usage, or apply quotas, on arbitrary mailboxes or mailbox
	hierarchies.</t>
        <t indent="0" pn="section-3.2-5">Not all resources may be limitable or calculable for all quota
        roots. Furthermore, not all resources may support all limits; some limits
        may be present in the underlying system. A server implementation of
        this memo <bcp14>SHOULD</bcp14> advise the client of such inherent
        limits, by generating <xref target="QUOTA" format="default" sectionFormat="of" derivedContent="Section 4.2.1">QUOTA</xref> responses, and <bcp14>SHOULD</bcp14>
        advise the client of which resources are limitable for a particular
        quota root. A <xref target="SETQUOTA" format="default" sectionFormat="of" derivedContent="Section 4.1.3">SETQUOTA</xref>
        command <bcp14>MAY</bcp14> also round a quota limit in an
        implementation-dependent way, if the granularity of the underlying
        system demands it. A client <bcp14>MUST</bcp14> be prepared for a
        <xref target="SETQUOTA" format="default" sectionFormat="of" derivedContent="Section 4.1.3">SETQUOTA</xref> command to
        fail if a limit cannot be set.</t>
        <t indent="0" pn="section-3.2-6">Implementation Notes: This means that, for example, under UNIX, a
        quota root may have a <xref target="MESSAGE" format="default" sectionFormat="of" derivedContent="Section 5.2">MESSAGE</xref> quota always set due to the number of
        inodes available on the filesystem; similarly, <xref target="STORAGE" format="default" sectionFormat="of" derivedContent="Section 5.1">STORAGE</xref> may be rounded to the nearest block
        and limited by free filesystem space.
        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-definitions">Definitions</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-commands">Commands</name>
        <t indent="0" pn="section-4.1-1">The following commands exist for manipulation and querying quotas.</t>
        <section anchor="GETQUOTA" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.1">
          <name slugifiedName="name-getquota">GETQUOTA</name>
          <dl newline="false" spacing="normal" indent="12" pn="section-4.1.1-1">
            <dt pn="section-4.1.1-1.1">Arguments:</dt>
            <dd pn="section-4.1.1-1.2">quota root</dd>
            <dt pn="section-4.1.1-1.3">Responses:</dt>
            <dd pn="section-4.1.1-1.4">
              <t indent="0" pn="section-4.1.1-1.4.1"><bcp14>REQUIRED</bcp14> untagged responses: QUOTA</t>
            </dd>
            <dt pn="section-4.1.1-1.5">Result:   </dt>
            <dd pn="section-4.1.1-1.6">
              <t indent="0" pn="section-4.1.1-1.6.1">OK - getquota completed</t>
              <t indent="0" pn="section-4.1.1-1.6.2">NO - getquota error: no such quota root, permission
              denied</t>
              <t indent="0" pn="section-4.1.1-1.6.3">BAD - command unknown or arguments invalid</t>
            </dd>
          </dl>
          <t indent="0" pn="section-4.1.1-2">
            The GETQUOTA command takes the name of a quota root and returns
            the quota root's resource usage and limits in an untagged QUOTA
            response.  (Names of quota roots applicable to a particular
            mailbox can be discovered by issuing the GETQUOTAROOT command; see
            <xref target="GETQUOTAROOT" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>.)  Note that the
            server is not required to support any specific resource type (as
            advertised in the CAPABILITY response, i.e., all capability items
            with the "QUOTA=RES-" prefix) for any particular quota root.</t>
          <t indent="0" pn="section-4.1.1-3">Example:</t>
          <sourcecode type="" markers="false" pn="section-4.1.1-4">
   S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...]

   [...]

   C: G0001 GETQUOTA "!partition/sda4"

   S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)

   S: G0001 OK Getquota complete
</sourcecode>
        </section>
        <section anchor="GETQUOTAROOT" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.2">
          <name slugifiedName="name-getquotaroot">GETQUOTAROOT</name>
          <dl indent="12" newline="false" spacing="normal" pn="section-4.1.2-1">
            <dt pn="section-4.1.2-1.1">Arguments:
            </dt>
            <dd pn="section-4.1.2-1.2">mailbox name
	    </dd>
            <dt pn="section-4.1.2-1.3">Responses:
            </dt>
            <dd pn="section-4.1.2-1.4">
              <bcp14>REQUIRED</bcp14> untagged responses: QUOTAROOT, QUOTA
	    </dd>
            <dt pn="section-4.1.2-1.5">Result:
            </dt>
            <dd pn="section-4.1.2-1.6">
              <t indent="0" pn="section-4.1.2-1.6.1">OK - getquotaroot completed
              </t>
              <t indent="0" pn="section-4.1.2-1.6.2">NO - getquotaroot error: permission denied
              </t>
              <t indent="0" pn="section-4.1.2-1.6.3">BAD - command unknown or arguments invalid
              </t>
            </dd>
          </dl>
          <t indent="0" pn="section-4.1.2-2">The GETQUOTAROOT command takes a mailbox name and returns the
          list of quota roots for the mailbox in an untagged QUOTAROOT
          response.  For each listed quota root, it also returns the quota
          root's resource usage and limits in an untagged QUOTA response.</t>
          <t indent="0" pn="section-4.1.2-3">Note that the mailbox name parameter doesn't have to reference an
          existing mailbox. This can be handy in order to determine which
          quota root would apply to a mailbox when it gets created.</t>
          <t indent="0" pn="section-4.1.2-4">Example:</t>
          <sourcecode type="" markers="false" pn="section-4.1.2-5">
   S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE
   [...]

   [...]

   C: G0002 GETQUOTAROOT INBOX

   S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4"

   S: * QUOTA "#user/alice" (MESSAGE 42 1000)

   S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)

   S: G0002 OK Getquotaroot complete
</sourcecode>
        </section>
        <section anchor="SETQUOTA" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.3">
          <name slugifiedName="name-setquota">SETQUOTA</name>
          <dl indent="12" newline="false" spacing="normal" pn="section-4.1.3-1">
            <dt pn="section-4.1.3-1.1">Arguments:                                                                                     
            </dt>
            <dd pn="section-4.1.3-1.2">quota root list of resource limits
            </dd>
            <dt pn="section-4.1.3-1.3">Responses:                                                                             
            </dt>
            <dd pn="section-4.1.3-1.4">untagged responses: QUOTA
            </dd>
            <dt pn="section-4.1.3-1.5">Result:                                                                                
            </dt>
            <dd pn="section-4.1.3-1.6">
              <t indent="0" pn="section-4.1.3-1.6.1">OK - setquota completed
              </t>
              <t indent="0" pn="section-4.1.3-1.6.2">NO - setquota error: can't set that data
              </t>
              <t indent="0" pn="section-4.1.3-1.6.3">BAD - command unknown or arguments invalid
              </t>
            </dd>
          </dl>
          <t indent="0" pn="section-4.1.3-2">Note that unlike other command/responses/response codes defined in this document,
          support for the SETQUOTA command requires the server to advertise the "QUOTASET" capability.</t>
          <t indent="0" pn="section-4.1.3-3">The SETQUOTA command takes the name of a mailbox quota root and a
          list of resource limits. The resource limits for the named quota
          root are changed to the specified limits.  Any previous resource
          limits for the named quota root are discarded, even resource limits
          not explicitly listed in the SETQUOTA command.  (For example, if the
          quota root had both STORAGE and MESSAGE limits assigned to the quota
          root before the SETQUOTA is called and the SETQUOTA only includes
          the STORAGE limit, then the MESSAGE limit is removed from the quota
          root.)</t>
          <t indent="0" pn="section-4.1.3-4">If the named quota root did not previously exist, an
          implementation may optionally create it and change the quota roots
          for any number of existing mailboxes in an implementation-defined
          manner.</t>
          <t indent="0" pn="section-4.1.3-5">
          If the implementation chooses to change the quota roots for some
          existing mailboxes, such changes <bcp14>SHOULD</bcp14> be announced
          with untagged QUOTA responses.
          </t>
          <t indent="0" pn="section-4.1.3-6">Example:</t>
          <sourcecode type="" markers="false" pn="section-4.1.3-7">
   S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES-
   MESSAGE [...]

   [...]

   C: S0000 GETQUOTA "#user/alice"

   S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000)

   S: S0000 OK Getquota completed

   C: S0001 SETQUOTA "#user/alice" (STORAGE 510)

   S: * QUOTA "#user/alice" (STORAGE 58 512)

   // The server has rounded the STORAGE quota limit requested to
   the nearest 512 blocks of 1024 octets; otherwise, another client
   has performed a near-simultaneous SETQUOTA using a limit of 512.

   S: S0001 OK Rounded quota

   C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999)

   S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)

   // The server has not changed the quota, since this is a
   filesystem limit, and it cannot be changed. The QUOTA
   response here is entirely optional.

   S: S0002 NO Cannot change system limit
</sourcecode>
        </section>
        <section anchor="STATUS_RECOVERABLE" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.4">
          <name slugifiedName="name-new-status-attributes">New STATUS attributes</name>
          <t indent="0" pn="section-4.1.4-1">The DELETED and DELETED-STORAGE status data items allow for estimation of the amount of resources that could be freed by an EXPUNGE on a mailbox.
</t>
          <t indent="0" pn="section-4.1.4-2">The DELETED status data item requests the server to return the
          number of messages with the \Deleted flag set. The DELETED status data
          item is only required to be implemented when the server advertises
          the "QUOTA=RES-MESSAGE" capability.</t>
          <t indent="0" pn="section-4.1.4-3">The DELETED-STORAGE status data item requests the server to
          return the amount of storage space that can be reclaimed by
          performing EXPUNGE on the mailbox. The server <bcp14>SHOULD</bcp14>
          return the exact value; however, it is recognized that the server
          may have to do a non-trivial amount of work to calculate it.

	  If the
          calculation of the exact value would take a long time, the server
          <bcp14>MAY</bcp14> instead return the sum of the RFC822.SIZE of
          the messages with the \Deleted flag set. The DELETED-STORAGE status data
          item is only required to be implemented when the server advertises
          the "QUOTA=RES-STORAGE" capability.</t>
          <t indent="0" pn="section-4.1.4-4"> Example:</t>
          <sourcecode type="" markers="false" pn="section-4.1.4-5">
   S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-
   MESSAGE [...]

   [...]

   C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)

   S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)

   // 12 messages, 4 of which would be deleted when an EXPUNGE
   happens.

   S: S0003 OK Status complete.
</sourcecode>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-responses">Responses</name>
        <t indent="0" pn="section-4.2-1">The following responses may be sent by the server.</t>
        <section anchor="QUOTA" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-quota">QUOTA</name>
          <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-4.2.1-1">
            <li pn="section-4.2.1-1.1">
              <t indent="0" pn="section-4.2.1-1.1.1">Data:	quota root name</t>
              <t indent="0" pn="section-4.2.1-1.1.2">list of resource names, usages, and limits</t>
            </li>
          </ul>
          <t indent="0" pn="section-4.2.1-2">This response occurs as a result of a GETQUOTA, GETQUOTAROOT,
          or SETQUOTA command.  The first string is the name of the quota
          root for which this quota applies.</t>
          <t indent="0" pn="section-4.2.1-3">The name is followed by an S-expression format list of the
          resource usage and limits of the quota root.  The list contains zero
          or more triplets.  Each triplet contains a resource name, the
          current usage of the resource, and the resource limit.</t>
          <t indent="0" pn="section-4.2.1-4">Resources not named in the list are not limited in the quota
          root. Thus, an empty list means there are no administrative resource
          limits in the quota root.</t>
          <t indent="0" pn="section-4.2.1-5">Example:</t>
          <sourcecode type="" markers="false" pn="section-4.2.1-6">
   S: * QUOTA "" (STORAGE 10 512)
</sourcecode>
        </section>
        <section anchor="QUOTAROOT" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2">
          <name slugifiedName="name-quotaroot">QUOTAROOT</name>
          <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-4.2.2-1">
            <li pn="section-4.2.2-1.1">
              <t indent="0" pn="section-4.2.2-1.1.1">Data:	mailbox name</t>
              <t indent="0" pn="section-4.2.2-1.1.2">zero or more quota root names</t>
            </li>
          </ul>
          <t indent="0" pn="section-4.2.2-2">This response occurs as a result of a GETQUOTAROOT command.  The first string is the mailbox and the remaining strings are the names of the quota roots for the mailbox.</t>
          <t indent="0" pn="section-4.2.2-3">Examples:</t>
          <sourcecode type="" markers="false" pn="section-4.2.2-4">
   S: * QUOTAROOT INBOX ""

   // The INBOX mailbox is covered by a single quota root with
   name "".

   S: * QUOTAROOT comp.mail.mime

   // The comp.mail.mime mailbox has no quota root associated
   with it, but one can be created.
</sourcecode>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-response-codes">Response Codes</name>
        <section anchor="OVERQUOTA" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.1">
          <name slugifiedName="name-overquota">OVERQUOTA</name>
          <t indent="0" pn="section-4.3.1-1">The OVERQUOTA response code <bcp14>SHOULD</bcp14> be returned in
          the tagged NO response to an APPEND/COPY/MOVE when the addition of
          the message(s) puts the target mailbox over any one of its quota
          limits.</t>
          <t indent="0" pn="section-4.3.1-2">Example 1:</t>
          <sourcecode type="" markers="false" pn="section-4.3.1-3">
   C: A003 APPEND saved-messages (\Seen) {326}
   S: + Ready for literal data
   C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
   C: From: Fred Foobar &lt;foobar@Blurdybloop.example&gt;
   C: Subject: afternoon meeting
   C: To: mooch@owatagu.siam.edu.example
   C: Message-Id: &lt;B27397-0100000@Blurdybloop.example&gt;
   C: MIME-Version: 1.0
   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
   C:
   C: Hello Joe, do you think we can meet at 3:30 tomorrow?
   C:
   S: A003 NO [OVERQUOTA] APPEND Failed
</sourcecode>
          <t indent="0" pn="section-4.3.1-4">
          The OVERQUOTA response code <bcp14>MAY</bcp14> also be returned in
          an untagged NO response in the authenticated or the selected state
          when a mailbox exceeds soft quota.  For example, such OVERQUOTA
          response codes might be sent as a result of an external event (e.g.,
          Local Mail Transfer Protocol (LMTP) <xref target="RFC2033" format="default" sectionFormat="of" derivedContent="RFC2033"/> delivery or COPY/MOVE/APPEND in
          another IMAP connection) that causes the currently selected mailbox
          to exceed soft quota.

          Note that such an OVERQUOTA response code might be ambiguous because it
          might relate to the target mailbox (as specified in COPY/MOVE/APPEND)
          or to the currently selected mailbox.

	  (The EXTRA WG chose not to address this deficiency
          due to syntactic limitations of IMAP response codes and because such events
          are likely to be rare.)

          This form of the OVERQUOTA response codes <bcp14>MUST NOT</bcp14> be returned if there is
          no mailbox selected and no command in progress that adds a message to
          a mailbox (e.g., APPEND).
          </t>
          <t indent="0" pn="section-4.3.1-5">Example 2:</t>
          <sourcecode type="" markers="false" pn="section-4.3.1-6">
   C: A003 APPEND saved-messages (\Seen) {326}
   S: + Ready for literal data
   C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
   C: From: Fred Foobar &lt;foobar@Blurdybloop.example&gt;
   C: Subject: afternoon meeting
   C: To: mooch@owatagu.siam.edu.example
   C: Message-Id: &lt;B27397-0100000@Blurdybloop.example&gt;
   C: MIME-Version: 1.0
   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
   C:
   C: Hello Joe, do you think we can meet at 3:30 tomorrow?
   C:
   S: * NO [OVERQUOTA] Soft quota has been exceeded
   S: A003 OK [APPENDUID 38505 3955] APPEND completed
</sourcecode>
          <t indent="0" pn="section-4.3.1-7">Example 3:</t>
          <sourcecode type="" markers="false" pn="section-4.3.1-8">
   C: A004 COPY 2:4 MEETING
   S: * NO [OVERQUOTA] Soft quota has been exceeded
   S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY
       command completed
</sourcecode>
        </section>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-resource-type-definitions">Resource Type Definitions</name>
      <t indent="0" pn="section-5-1">The following resource types are defined in this memo. A server
      supporting a resource type <bcp14>MUST</bcp14> advertise this as a
      CAPABILITY with a name consisting of the resource name prefixed by
      "QUOTA=RES-". A server <bcp14>MAY</bcp14> support multiple resource
      types and <bcp14>MUST</bcp14> advertise all resource types it
      supports.</t>
      <section anchor="STORAGE" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-storage">STORAGE</name>
        <t indent="0" pn="section-5.1-1">"STORAGE" is the physical space estimate, in units of 1024 octets, of the
        mailboxes governed by the quota root.  This <bcp14>MAY</bcp14> not be
        the same as the sum of the RFC822.SIZE of the messages.  Some
        implementations <bcp14>MAY</bcp14> include metadata sizes for the
        messages and mailboxes, and other implementations <bcp14>MAY</bcp14> store
        messages in such a way that the physical space used is smaller, for
        example, due to use of compression.  Additional messages might not
        increase the usage. Clients <bcp14>MUST NOT</bcp14> use the usage
        figure for anything other than informational purposes; for example,
        they <bcp14>MUST NOT</bcp14> refuse to APPEND a message if the limit
        less the usage is smaller than the RFC822.SIZE divided by 1024 octets of the
        message, but it <bcp14>MAY</bcp14> warn about such condition.</t>
        <t indent="0" pn="section-5.1-2">The usage figure may change as a result of performing actions not
        associated with adding new messages to the mailbox, such as SEARCH,
        since this may increase the amount of metadata included in the
        calculations.</t>
        <t indent="0" pn="section-5.1-3">When the server supports this resource type, it <bcp14>MUST</bcp14>
        also support the DELETED-STORAGE status data item.</t>
        <t indent="0" pn="section-5.1-4">Support for this resource <bcp14>MUST</bcp14> be indicated by the
        server by advertising the "QUOTA=RES-STORAGE" capability.</t>
        <t indent="0" pn="section-5.1-5">A resource named the same was also given as an example in <xref target="RFC2087" format="default" sectionFormat="of" derivedContent="RFC2087"/>.  This document
        provides a more precise definition.</t>
      </section>
      <section anchor="MESSAGE" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-message">MESSAGE</name>
        <t indent="0" pn="section-5.2-1">"MESSAGE" is the number of messages stored within the mailboxes governed by the
        quota root. This <bcp14>MUST</bcp14> be an exact number; however,
        clients <bcp14>MUST NOT</bcp14> assume that a change in the usage
        indicates a change in the number of messages available, since the
        quota root may include mailboxes the client has no access
        to.
	
        </t>
        <t indent="0" pn="section-5.2-2">When the server supports this resource type, it <bcp14>MUST</bcp14>
        also support the DELETED status data item.</t>
        <t indent="0" pn="section-5.2-3">Support for this resource <bcp14>MUST</bcp14> be indicated by the
        server by advertising the "QUOTA=RES-MESSAGE" capability.</t>
        <t indent="0" pn="section-5.2-4">A resource named the same was also given as an example in <xref target="RFC2087" format="default" sectionFormat="of" derivedContent="RFC2087"/>.  This document
        provides a more precise definition.</t>
      </section>
      <section anchor="MAILBOX" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-mailbox">MAILBOX</name>
        <t indent="0" pn="section-5.3-1">"MAILBOX" is the number of mailboxes governed by the quota root. This
        <bcp14>MUST</bcp14> be an exact number; however, clients <bcp14>MUST NOT</bcp14> assume that a change in the usage indicates a change in
        the number of mailboxes, since the quota root may include mailboxes
        the client has no access to.
	
        </t>
        <t indent="0" pn="section-5.3-2">Support for this resource <bcp14>MUST</bcp14> be indicated by the server by advertising the "QUOTA=RES-MAILBOX" capability.</t>
      </section>
      <section anchor="ANNOTATION-STORAGE" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-annotation-storage">ANNOTATION-STORAGE</name>
        <t indent="0" pn="section-5.4-1">
        "ANNOTATION-STORAGE" is the maximum size of all annotations <xref target="RFC5257" format="default" sectionFormat="of" derivedContent="RFC5257"/>, in units of 1024 octets, associated with all messages in the mailboxes governed by the quota root.
        </t>
        <t indent="0" pn="section-5.4-2">Support for this resource <bcp14>MUST</bcp14> be indicated by the server by advertising the "QUOTA=RES-ANNOTATION-STORAGE" capability.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-interaction-with-imap-acl-e">Interaction with IMAP ACL Extension (RFC 4314)</name>
      <t indent="0" pn="section-6-1">This section lists <xref target="RFC4314" format="default" sectionFormat="of" derivedContent="RFC4314"/> rights
      required to execute quota-related commands when both RFC 4314 and this
      document are implemented.</t>
      <table align="center" pn="table-1">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Operations\Rights</th>
            <th align="center" colspan="1" rowspan="1">l</th>
            <th align="center" colspan="1" rowspan="1">r</th>
            <th align="center" colspan="1" rowspan="1">s</th>
            <th align="center" colspan="1" rowspan="1">w</th>
            <th align="center" colspan="1" rowspan="1">i</th>
            <th align="center" colspan="1" rowspan="1">c</th>
            <th align="center" colspan="1" rowspan="1">x</th>
            <th align="center" colspan="1" rowspan="1">t</th>
            <th align="center" colspan="1" rowspan="1">e</th>
            <th align="center" colspan="1" rowspan="1">a</th>
            <th align="center" colspan="1" rowspan="1">Any</th>
            <th align="center" colspan="1" rowspan="1">Non</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">GETQUOTA</td>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">+</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">GETQUOTAROOT</td>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">*</td>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">*</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">SETQUOTA</td>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">+</td>
            <td align="center" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1"/>
          </tr>
        </tbody>
      </table>
      <t keepWithPrevious="true" indent="0" pn="section-6-3">See <xref target="RFC4314" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4314#section-4" derivedContent="RFC4314"/> for conventions used in this table.</t>
      <t indent="0" pn="section-6-4">Legend:
      </t>
      <dl newline="false" spacing="normal" indent="8" pn="section-6-5">
        <dt pn="section-6-5.1">"+":</dt>
        <dd pn="section-6-5.2">The right is required</dd>
        <dt pn="section-6-5.3">"*":</dt>
        <dd pn="section-6-5.4">Only one of the rights marked with * is required</dd>
        <dt pn="section-6-5.5">"Any":</dt>
        <dd pn="section-6-5.6">At least one of the "l", "r", "i", "k", "x", or "a" rights is required</dd>
        <dt pn="section-6-5.7">"Non":</dt>
        <dd pn="section-6-5.8">No rights required to perform the command</dd>
      </dl>
      <t indent="0" pn="section-6-6">
      Note that which permissions are needed in order to perform a
      GETQUOTAROOT command depends on the quota resource type being requested.
      For example, a quota on the number of messages (MESSAGE resource type) or
      total size of messages (STORAGE resource type) requires "r" right on the
      mailbox in question, since the quota involved would reveal information
      about the number (or total size) of messages in the mailbox. By
      comparison, the MAILBOX resource type doesn't require any right.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-formal-syntax">Formal Syntax</name>
      <t indent="0" pn="section-7-1">The following syntax specification uses the Augmented Backus-Naur
      Form (ABNF) notation as specified in <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="ABNF"/>.</t>
      <t indent="0" pn="section-7-2">Non-terminals referenced but not defined below are as defined by <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501">IMAP4</xref> <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>.</t>
      <t indent="0" pn="section-7-3">Except as noted otherwise, all alphabetic characters are
      case insensitive.  The use of uppercase or lowercase characters to define
      token strings is for editorial clarity only.  Implementations
      <bcp14>MUST</bcp14> accept these strings in a case-insensitive
      fashion.</t>
      <sourcecode type="abnf" markers="false" pn="section-7-4">
getquota =         "GETQUOTA" SP quota-root-name

getquotaroot =     "GETQUOTAROOT" SP mailbox

quota-list =       "(" quota-resource *(SP quota-resource) ")"

quota-resource =   resource-name SP resource-usage SP resource-limit

quota-response =   "QUOTA" SP quota-root-name SP quota-list

quotaroot-response =  "QUOTAROOT" SP mailbox *(SP quota-root-name)

setquota =         "SETQUOTA" SP quota-root-name SP setquota-list

setquota-list =    "(" [setquota-resource *(SP setquota-resource)]
                   ")"

setquota-resource =  resource-name SP resource-limit

quota-root-name =  astring

resource-limit =   number64

resource-name =    "STORAGE" / "MESSAGE" / "MAILBOX" /
                   "ANNOTATION-STORAGE" / resource-name-ext

resource-name-ext =  atom
                   ;; Future resource registrations

resource-usage =  number64
                   ;; must be less than corresponding resource-limit

capability-quota = capa-quota-res / "QUOTASET"
                   ;; One or more capa-quota-res must be returned.
                   ;; Also "QUOTASET" can optionally be returned.

capa-quota-res =   "QUOTA=RES-" resource-name

status-att =/      "DELETED" / "DELETED-STORAGE"
                   ;; DELETED status data item MUST be supported
                   ;; when the "QUOTA=RES-MESSAGE" capability is
                   ;; advertised.
                   ;; DELETED-STORAGE status data item MUST be
                   ;; supported when the "QUOTA=RES-STORAGE"
                   ;; capability is advertised.

status-att-val =/  status-att-deleted /
                   status-att-deleted-storage

status-att-deleted =  "DELETED" SP number
                   ;; DELETED status data item MUST be supported
                   ;; when the "QUOTA=RES-MESSAGE" capability is
                   ;; advertised.

status-att-deleted-storage =  "DELETED-STORAGE" SP number64
                   ;; DELETED-STORAGE status data item MUST be
                   ;; supported when the "QUOTA=RES-STORAGE"
                   ;; capability is advertised.

resp-text-code =/  "OVERQUOTA"

number64 =         &lt;Defined in RFC 9051&gt;
</sourcecode>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">
      Implementors should be careful to make sure the implementation of
      these commands does not violate the site's security policy. The
      resource usage of other users is likely to be considered confidential
      information and should not be divulged to unauthorized persons.
      In particular, no quota information should be disclosed to
      anonymous users.
      
      </t>
      <t indent="0" pn="section-8-2">
      As for any resource shared across users (for example, a quota root attached to a set of shared mailboxes),
      a user that can consume or render unusable the resource can affect the resources available
      to the other users; this might occur, for example, by a user with permission to
      execute the SETQUOTA setting, which sets an artificially small value.
      </t>
      <t indent="0" pn="section-8-3">
      Note that computing resource usage might incur a heavy load on the server.
      Server implementers should consider implementation techniques that
      lower the load on servers such as caching of resource usage information
      or usage of less precise computations when under heavy load.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section numbered="true" toc="include" anchor="changes-to-imap" removeInRFC="false" pn="section-9.1">
        <name slugifiedName="name-changes-additions-to-the-im">Changes/Additions to the IMAP Capabilities Registry</name>
        <t indent="0" pn="section-9.1-1">
	IMAP4 capabilities are registered by publishing a Standards Track or
	an IESG-approved Informational or Experimental RFC.  The "IMAP Capabilities" registry is
	currently located at <eref target="https://www.iana.org/assignments/imap4-capabilities" brackets="angle"/>.
        </t>
        <t indent="0" pn="section-9.1-2">IANA has updated the reference for the QUOTA extension to point
to this document.




IANA has also added the "QUOTA=" prefix and the "QUOTASET" capability to
the "IMAP Capabilities" registry with this document as the reference.


</t>
        <t indent="0" pn="section-9.1-3">
 IANA has added the following notes to the "IMAP Capabilities"
   registry:
        </t>
        <t indent="0" pn="section-9.1-4">
The prefix "QUOTA=RES-" is reserved per RFC 9208, <xref target="changes-to-imap" format="default" sectionFormat="of" derivedContent="Section 9.1"/>. See <xref target="iana-quota-res-types" format="default" sectionFormat="of" derivedContent="Section 9.2"/> of that document for values that follow this prefix. 

        </t>
        <t indent="0" pn="section-9.1-5">

	  All other capabilities starting with the "QUOTA=" prefix are reserved
      for future IETF Stream extensions to RFC 9208.
        </t>
      </section>
      <section anchor="iana-quota-res-types" numbered="true" toc="include" removeInRFC="false" pn="section-9.2">
        <name slugifiedName="name-imap-quota-resource-type-re">IMAP Quota Resource Type Registry</name>
        <t indent="0" pn="section-9.2-1">IANA has created a new registry for IMAP quota resource
        types. The registration policy for the "IMAP Quota Resource Types" registry is "Specification Required"	<xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
        <t indent="0" pn="section-9.2-2">When registering a new quota resource type, the registrant needs to provide the following:
</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-9.2-3">
          <li pn="section-9.2-3.1"> the name of the quota resource type
  </li>
          <li pn="section-9.2-3.2">a short description
  </li>
          <li pn="section-9.2-3.3">extra required IMAP commands/responses (if any)
  </li>
          <li pn="section-9.2-3.4">extra optional IMAP commands/responses (if any)
  </li>
          <li pn="section-9.2-3.5">name and email address of author
  </li>
          <li pn="section-9.2-3.6">name and email address of change controller
  </li>
          <li pn="section-9.2-3.7">a reference to a specification that describes the quota resource type in more detail
  </li>
        </ul>
        <t indent="0" pn="section-9.2-4">Designated experts should check that the provided references are
        correct, the references describe the quota resource type being registered
        in sufficient detail to be implementable, the syntax of any optional
        commands/responses is correct (e.g., ABNF validates), and the
        syntax/description complies with rules and limitations imposed by IMAP
        <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>.  Designated experts should avoid registering
        multiple identical quota resource types under different names and
        should provide advice to requestors about other possible quota
        resource types to use.
        </t>
        <t indent="0" pn="section-9.2-5">
     The initial contents of the "IMAP Quota Resource Types" registry are as follows:
        </t>
        <table align="left" pn="table-2">
          <name slugifiedName="name-storage-2">STORAGE</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">field name
      </th>
              <th align="left" colspan="1" rowspan="1">field value
      </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">Name of the quota resource type:

      </td>
              <td align="left" colspan="1" rowspan="1">STORAGE
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Description:
      </td>
              <td align="left" colspan="1" rowspan="1">The physical space estimate, in units of 1024 octets, of the mailboxes governed by the quota root.
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Extra required IMAP commands/responses:
      </td>
              <td align="left" colspan="1" rowspan="1">DELETED-STORAGE STATUS request data item and response data item
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Extra optional IMAP commands/responses:
      </td>
              <td align="left" colspan="1" rowspan="1">N/A
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Author:
      </td>
              <td align="left" colspan="1" rowspan="1">Alexey Melnikov &lt;alexey.melnikov@isode.com&gt;
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Change Controller:
      </td>
              <td align="left" colspan="1" rowspan="1">IESG &lt;iesg@ietf.org&gt;
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Reference:
      </td>
              <td align="left" colspan="1" rowspan="1">Section 5.1 of RFC 9208
     </td>
            </tr>
          </tbody>
        </table>
        <table align="left" pn="table-3">
          <name slugifiedName="name-message-2">MESSAGE</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">field name
      </th>
              <th align="left" colspan="1" rowspan="1">field value
      </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">Name of the quota resource type:
      </td>
              <td align="left" colspan="1" rowspan="1">MESSAGE
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Description:
      </td>
              <td align="left" colspan="1" rowspan="1">The number of messages stored within the mailboxes governed by the quota root.
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Extra required IMAP commands/responses:
      </td>
              <td align="left" colspan="1" rowspan="1">DELETED STATUS request data item and response data item
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Extra optional IMAP commands/responses:
      </td>
              <td align="left" colspan="1" rowspan="1">N/A
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Author:
      </td>
              <td align="left" colspan="1" rowspan="1">Alexey Melnikov &lt;alexey.melnikov@isode.com&gt;
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Change Controller:
      </td>
              <td align="left" colspan="1" rowspan="1">IESG &lt;iesg@ietf.org&gt;
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Reference:
      </td>
              <td align="left" colspan="1" rowspan="1">Section 5.2 of RFC 9208
     </td>
            </tr>
          </tbody>
        </table>
        <table align="left" pn="table-4">
          <name slugifiedName="name-mailbox-2">MAILBOX
</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">field name
      </th>
              <th align="left" colspan="1" rowspan="1">field value
      </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">Name of the quota resource type:
      </td>
              <td align="left" colspan="1" rowspan="1">MAILBOX
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Description:
      </td>
              <td align="left" colspan="1" rowspan="1">The number of mailboxes governed by the quota root.
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Extra required IMAP commands/responses:
      </td>
              <td align="left" colspan="1" rowspan="1">N/A
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Extra optional IMAP commands/responses:
      </td>
              <td align="left" colspan="1" rowspan="1">N/A
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Author:
      </td>
              <td align="left" colspan="1" rowspan="1">Alexey Melnikov &lt;alexey.melnikov@isode.com&gt;
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Change Controller:
      </td>
              <td align="left" colspan="1" rowspan="1">IESG &lt;iesg@ietf.org&gt;
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Reference:
      </td>
              <td align="left" colspan="1" rowspan="1">Section 5.3 of RFC 9208
     </td>
            </tr>
          </tbody>
        </table>
        <table align="left" pn="table-5">
          <name slugifiedName="name-annotation-storage-2">ANNOTATION-STORAGE</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">field name
      </th>
              <th align="left" colspan="1" rowspan="1">field value
      </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">Name of the quota resource type:
      </td>
              <td align="left" colspan="1" rowspan="1">ANNOTATION-STORAGE
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Description:
      </td>
              <td align="left" colspan="1" rowspan="1">The maximum size of all annotations [RFC5257], in units of 1024 octets, associated with all messages in the mailboxes governed by the quota root.
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Extra required IMAP commands/responses:
      </td>
              <td align="left" colspan="1" rowspan="1">N/A
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Extra optional IMAP commands/responses:
      </td>
              <td align="left" colspan="1" rowspan="1">N/A
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Author:
      </td>
              <td align="left" colspan="1" rowspan="1">Alexey Melnikov &lt;alexey.melnikov@isode.com&gt;
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Change Controller:
      </td>
              <td align="left" colspan="1" rowspan="1">IESG &lt;iesg@ietf.org&gt;
     </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Reference:
      </td>
              <td align="left" colspan="1" rowspan="1">Section 5.4 of RFC 9208
     </td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="changes-since" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-changes-since-rfc-2087">Changes Since RFC 2087</name>
      <t indent="0" pn="section-10-1">
	This document is a revision of <xref target="RFC2087" format="default" sectionFormat="of" derivedContent="RFC2087"/>, and it aims to clarify the
	meaning of different terms that were used in that RFC. It also provides more
	examples, gives guidance on allowed server behavior, defines an IANA
	registry for quota resource types, and provides initial registrations
	for 4 of them.</t>
      <t indent="0" pn="section-10-2">
	When compared with <xref target="RFC2087" format="default" sectionFormat="of" derivedContent="RFC2087"/>, this document defines two more commonly
	used resource types, adds an optional OVERQUOTA response code, and
	defines two extra STATUS data items ("DELETED" and "DELETED-STORAGE").
	The DELETED STATUS data item must be implemented if the
	"QUOTA=RES-MESSAGE" capability is advertised. The DELETED-STORAGE STATUS
	data item must be implemented if the "QUOTA=RES-STORAGE" capability is
	advertised.  For extensibility, quota usage and quota limits are now
	63-bit unsigned integers.
      </t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC5234" to="ABNF"/>
    <references pn="section-11">
      <name slugifiedName="name-references">References</name>
      <references pn="section-11.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" quoteTitle="true" derivedAnchor="ABNF">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author initials="D." surname="Crocker" fullname="D. Crocker" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Overell" fullname="P. Overell">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="January"/>
            <abstract>
              <t indent="0">Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <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 initials="M." surname="Crispin" fullname="M. Crispin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="March"/>
            <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="RFC4314" target="https://www.rfc-editor.org/info/rfc4314" quoteTitle="true" derivedAnchor="RFC4314">
          <front>
            <title>IMAP4 Access Control List (ACL) Extension</title>
            <author initials="A." surname="Melnikov" fullname="A. Melnikov">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="December"/>
            <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="RFC5257" target="https://www.rfc-editor.org/info/rfc5257" quoteTitle="true" derivedAnchor="RFC5257">
          <front>
            <title>Internet Message Access Protocol - ANNOTATE Extension</title>
            <author initials="C." surname="Daboo" fullname="C. Daboo">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Gellens" fullname="R. Gellens">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="June"/>
            <abstract>
              <t indent="0">The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server.  For example, this can be used to attach comments and other useful information to a message.  It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.</t>
              <t indent="0">Note that this document was the product of a WG that had good consensus on how to approach the problem.  Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard.  The IETF solicits implementations and implementation reports in order to make further progress.</t>
              <t indent="0">Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension.  This memo defines an Experimental Protocol  for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5257"/>
          <seriesInfo name="DOI" value="10.17487/RFC5257"/>
        </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 initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <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 initials="A." surname="Melnikov" fullname="A. Melnikov" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Leiba" fullname="B. Leiba" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="August"/>
            <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-11.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC2033" target="https://www.rfc-editor.org/info/rfc2033" quoteTitle="true" derivedAnchor="RFC2033">
          <front>
            <title>Local Mail Transfer Protocol</title>
            <author initials="J." surname="Myers" fullname="J. Myers">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1996" month="October"/>
            <abstract>
              <t indent="0">SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently.  The design of the SMTP protocol effectively requires the server to manage a mail delivery queue.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2033"/>
          <seriesInfo name="DOI" value="10.17487/RFC2033"/>
        </reference>
        <reference anchor="RFC2087" target="https://www.rfc-editor.org/info/rfc2087" quoteTitle="true" derivedAnchor="RFC2087">
          <front>
            <title>IMAP4 QUOTA extension</title>
            <author initials="J." surname="Myers" fullname="J. Myers">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="January"/>
            <abstract>
              <t indent="0">The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2087"/>
          <seriesInfo name="DOI" value="10.17487/RFC2087"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author initials="M." surname="Cotton" fullname="M. Cotton">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="June"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">
	The editor of this document would like to thank the following people
	who provided useful comments or participated in discussions that lead
	to this update of <xref target="RFC2087" format="default" sectionFormat="of" derivedContent="RFC2087"/>: <contact fullname="John Myers"/>, <contact fullname="Cyrus Daboo"/>, <contact fullname="Lyndon Nerenberg"/>,
	<contact fullname="Benjamin Kaduk"/>, <contact fullname="Roman  Danyliw"/>, and <contact fullname="Éric Vyncke"/>.
      </t>
      <t indent="0" pn="section-appendix.a-2">This document is a revision of <xref target="RFC2087" format="default" sectionFormat="of" derivedContent="RFC2087"/>, and it borrows a lot of text
      from that RFC. Thus, the work of <contact fullname="John       Myers"/>, the author of <xref target="RFC2087" format="default" sectionFormat="of" derivedContent="RFC2087"/>, is appreciated.
      </t>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.b-1">
        <contact fullname="Dave Cridland"/> wrote a lot of text in an earlier
        draft version that became the basis for this document.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
        <organization abbrev="Isode" showOnFrontPage="true">Isode Limited</organization>
        <address>
          <email>alexey.melnikov@isode.com</email>
          <uri>https://www.isode.com</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
