<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-extra-imap-inprogress-06" number="9585" updates="" obsoletes="" ipr="trust200902" consensus="true" submissionType="IETF" tocInclude="true" xml:lang="en" symRefs="true" sortRefs="true" prepTime="2024-05-31T11:34:07" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-extra-imap-inprogress-06" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9585" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="IMAP Response Code for Command Progress">IMAP Response Code for Command Progress Notifications</title>
    <seriesInfo name="RFC" value="9585" stream="IETF"/>
    <author fullname="Marco Bettini" initials="M." surname="Bettini">
      <organization showOnFrontPage="true">Open-Xchange Oy</organization>
      <address>
        <postal>
          <street>Lars Sonckin kaari 10</street>
          <code>02600</code>
          <city>Espoo</city>
          <country>Finland</country>
        </postal>
        <email>marco.bettini@open-xchange.com</email>
      </address>
    </author>
    <date month="05" year="2024"/>
    <area>ART</area>
    <workgroup>extra</workgroup>
    <keyword>IMAP</keyword>
    <keyword>response code</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines a new IMAP untagged response code,
      "INPROGRESS", that provides progress notifications regarding the status
      of long-running commands.
      </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/rfc9585" 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-capability-identification">CAPABILITY Identification</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-the-inprogress-response-cod">The "INPROGRESS" Response Code</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-iana-considerations">IANA 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-normative-references">Normative References</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
IMAP commands <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>
can require a considerable amount of time to be completed by the server.
In these cases, the client has no information about the progress of the
commands. It is already possible to expose updates with a generic untagged
response, like "* OK Still on it, 57% done"; however, this does not provide
a standard way to communicate with the client and does not allow the server
to inform the client of the progress of the long-running actions.
</t>
      <t indent="0" pn="section-1-2">
This document extends the Internet Message Access Protocol (IMAP)
<xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/> with:
</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1-3">
        <li pn="section-1-3.1">a new "INPROGRESS" response code <xref target="RFC5530" format="default" sectionFormat="of" derivedContent="RFC5530"/>.
    The new response code provides a consistent means for a client to receive
    progress notifications on command completion status.</li>
        <li pn="section-1-3.2">a new "INPROGRESS" capability <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>.
    The new capability informs the client that the server emits progress
    notifications via the "INPROGRESS" response code.</li>
      </ul>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
      </t>
      <t indent="0" pn="section-2-2">
The word "can" (not "may") is used to refer to a possible
circumstance or situation, as opposed to an optional facility of the
protocol.
</t>
      <t indent="0" pn="section-2-3">
Conventions for notations are as in <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/> and
<xref target="RFC5530" format="default" sectionFormat="of" derivedContent="RFC5530"/>.
</t>
      <t indent="0" pn="section-2-4">
In examples, "C:" and "S:" indicate lines sent by the client and
server, respectively. Note that each line includes the terminating CRLF.
</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-capability-identification">CAPABILITY Identification</name>
      <t indent="0" pn="section-3-1">
IMAP servers that support this extension <bcp14>MUST</bcp14> include
"INPROGRESS" in the response list to the CAPABILITY command.
</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-the-inprogress-response-cod">The "INPROGRESS" Response Code</name>
      <t indent="0" pn="section-4-1">
The server <bcp14>MAY</bcp14> send the "INPROGRESS" response code to notify
the client about the progress of the commands in execution or simply to
prevent the client from timing out and terminating the connection.
The notifications <bcp14>MAY</bcp14> be sent for any IMAP command.
If the server elects to send notifications, it is <bcp14>RECOMMENDED</bcp14>
that these are sent every 10-15 seconds.
</t>
      <t indent="0" pn="section-4-2">
The response code is meant to appear embedded inside an untagged OK reply.
The response code <bcp14>MUST NOT</bcp14> appear in a tagged response
(the command has completed and further progress notifications make no sense).
</t>
      <t indent="0" pn="section-4-3">
The response code <bcp14>MAY</bcp14> embed a list of details, which appear
in the following order:
</t>
      <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4-4">
<li pn="section-4-4.1" derivedCounter="1.">CMD-TAG: the tag <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/> that originated the
    long-running command. If the tag is not available or if it contains
    the "]" character, it <bcp14>MUST</bcp14> be set to NIL. This still
    produces a usable notification, unless multiple commands are in flight
    simultaneously. A client can ensure reception of notifications with
    tags by simply refraining from the use of the character "]" in the
    originating command tags.
</li>
        <li pn="section-4-4.2" derivedCounter="2.">PROGRESS: a number indicating the number of items processed so far.
    The number <bcp14>MUST</bcp14> be non-negative and <bcp14>SHOULD</bcp14>
    be monotonically increasing.
    If the PROGRESS is not available, both PROGRESS and GOAL <bcp14>MUST</bcp14>
    be set to NIL.
</li>
        <li pn="section-4-4.3" derivedCounter="3.">GOAL: a number indicating the total number of items to be processed.
    The number <bcp14>MUST</bcp14> be positive, and it <bcp14>SHOULD NOT</bcp14>
    change between successive notifications for the same command tag.
    This is the number that PROGRESS is expected to reach
    after the completion of the command; therefore, it <bcp14>MUST</bcp14> be
    greater than PROGRESS. If the GOAL is not known, it
    <bcp14>MUST</bcp14> be set to NIL.</li>
      </ol>
      <t indent="0" pn="section-4-5">
If the response code does not embed a list of details, all details are to
be interpreted as NIL.
</t>
      <t indent="0" pn="section-4-6">
The server can provide the progress details with different
degrees of completeness:
</t>
      <sourcecode markers="false" pn="section-4-7">
- bare keepalive
  * OK [INPROGRESS] Hang in there...
- keepalive with an indication of the command tag
  * OK [INPROGRESS ("tag" NIL NIL)] Hang in there...
- progress notification with unknown GOAL
  * OK [INPROGRESS ("tag" 175 NIL)] Processed 175 items so far
- progress notification with an indication of the GOAL
  * OK [INPROGRESS ("tag" 175 1000)] Processed 17% of the items
</sourcecode>
      <t indent="0" pn="section-4-8">
Examples:
</t>
      <sourcecode markers="false" pn="section-4-9">
  C: A001 search text "this will be slow"
    [13 seconds later]
  S: * OK [INPROGRESS ("A001" 454 1000)] Processed 45% of the items
    [14 seconds later]
  S: * OK [INPROGRESS ("A001" 999 1000)] Processed 99% of the items
    [5 seconds later]
  S: * SEARCH 447 735
  S: A001 OK Search completed (23.387 + 0.004 + 0.017 secs).
</sourcecode>
      <sourcecode markers="false" pn="section-4-10">
  C: A003 COPY 2000:4000 Meeting-Minutes
    [12 seconds later]
  S: * OK [INPROGRESS ("A003" 175 2001)] Still working on this...
    [14 seconds later]
  S: * OK [INPROGRESS ("A003" 440 2001)] Still working on this...
    [13 seconds later]
  S: * OK [INPROGRESS ("A003" 987 2001)] Still working on this...
    [14 seconds later]
  S: * OK [INPROGRESS ("A003" 1388 2001)] Still working on this...
    [14 seconds later]
  S: * OK [INPROGRESS ("A003" 1876 2001)] Still working on this...
    [9 seconds later]
  S: A003 OK Copy completed
</sourcecode>
      <t indent="0" pn="section-4-11">
PROGRESS and GOAL <bcp14>SHOULD</bcp14> be counts of the kind of item
being processed -- in most cases, messages counts. If that is not possible,
the counts <bcp14>SHOULD</bcp14> be percentages, with GOAL set to 100
and PROGRESS varying between 0 and 99.
</t>
      <t indent="0" pn="section-4-12">
The server <bcp14>SHOULD NOT</bcp14> send a progress notification where
PROGRESS equals GOAL, as that would mean the command is completed.
In that case, the proper tagged response should be emitted instead.
</t>
      <t indent="0" pn="section-4-13">
If the command completes before the first server notification deadline,
there will be no notifications at all. The client <bcp14>MUST</bcp14>
assume PROGRESS to be 0 and GOAL to be unknown until the server issues a
notification for the command.
</t>
      <t indent="0" pn="section-4-14">
While the server <bcp14>SHOULD</bcp14> keep GOAL constant and PROGRESS
monotonically increasing, there are circumstances where this might not
be possible. The client <bcp14>MUST</bcp14> be prepared to handle cases
where the server cannot keep GOAL constant and/or PROGRESS monotonically
increasing. When the GOAL changes or the PROGRESS goes backward, the
<bcp14>RECOMMENDED</bcp14> interpretation is that the previous GOAL has
been reached, but the server discovered that further (long-running) work
is required (with a new known or unknown GOAL).
</t>
      <t indent="0" pn="section-4-15">
The client <bcp14>MAY</bcp14> disregard progress notifications entirely or
process them only in relation to specific commands. If a user interface is
involved, it is the client's duty to decide which of these 
notifications should emerge to the user interface and/or modify the user's
ability to interact in their presence, since this may differ based on
implementation details.
</t>
      <t indent="0" pn="section-4-16">
Also, the client <bcp14>MUST NOT</bcp14> consider the values to be authoritative
for any other use than evaluating the progress of the commands.
For example, the client must not use the GOAL field in place of the proper output of a
SEARCH command to know the number of messages in a folder.
</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" 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) <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> notation. Elements not defined here can
be found in the formal syntax of the ABNF <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> and IMAP
<xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/> specifications.
</t>
      <t indent="0" pn="section-5-2">
Except as noted otherwise, all alphabetic characters are case-insensitive.
The use of uppercase or lowercase characters to define token strings are
for editorial clarity only. Implementations <bcp14>MUST</bcp14> accept
these strings in a case-insensitive fashion.
</t>
      <sourcecode type="abnf" markers="false" pn="section-5-3">
inprogress-tag              = quoted / nil
inprogress-state-unknown    = nil    SP nil
inprogress-state-counting   = number SP nil
inprogress-state-known-goal = number SP nz-number

inprogress-state = inprogress-state-unknown
                 / inprogress-state-counting
                 / inprogress-state-known-goal

resp-text-code =/ "INPROGRESS" [ SP "(" inprogress-tag SP
                                        inprogress-state ")" ]
</sourcecode>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">
The details of the response code are not expected to disclose any information
that isn't currently available from the command output. The progress details
could be obtained anyway by sending a series of commands with different
workloads -- by either constructing data sets or searching in the appropriate
way.
</t>
      <t indent="0" pn="section-6-2">
The client must protect itself against data sent by a malicious server.
Specifically, the client should guard against values that can cause arithmetic
exceptions, like GOAL = 0, GOAL/VALUE &lt; 0, GOAL/VALUE ≥ 2<sup>32</sup>
(these are not possible within a correct implementation of the ABNF syntax
above), and VALUE &gt; GOAL. In these cases, the notification <bcp14>MUST</bcp14>
be disregarded.
</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">
   IANA has added "INPROGRESS" to the "IMAP Response Codes" registry
   located at <eref target="https://www.iana.org/assignments/imap-response-codes" brackets="angle"/>,
   with a reference to this document.
</t>
      <t indent="0" pn="section-7-2">
   IANA had added "INPROGRESS" to the "IMAP Capabilities" registry
   located at <eref target="https://www.iana.org/assignments/imap-capabilities" brackets="angle"/>,
   with a reference to this document.
</t>
    </section>
  </middle>
  <back>
    <references pn="section-8">
      <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="RFC5530" target="https://www.rfc-editor.org/info/rfc5530" quoteTitle="true" derivedAnchor="RFC5530">
        <front>
          <title>IMAP Response Codes</title>
          <author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/>
          <date month="May" year="2009"/>
          <abstract>
            <t indent="0">IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.</t>
            <t indent="0">This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5530"/>
        <seriesInfo name="DOI" value="10.17487/RFC5530"/>
      </reference>
      <reference anchor="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>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Marco Bettini" initials="M." surname="Bettini">
        <organization showOnFrontPage="true">Open-Xchange Oy</organization>
        <address>
          <postal>
            <street>Lars Sonckin kaari 10</street>
            <code>02600</code>
            <city>Espoo</city>
            <country>Finland</country>
          </postal>
          <email>marco.bettini@open-xchange.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
