<?xml version="1.0"?> version="1.0" encoding="UTF-8"?>

<!-- [CS] updated by Chris 01/23/23 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc3501 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3501.xml'> nbsp    "&#160;">
  <!ENTITY rfc4731 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4731.xml'> zwsp   "&#8203;">
  <!ENTITY rfc5267 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5267.xml'> nbhy   "&#8209;">
  <!ENTITY rfc8174 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml'>
  <!ENTITY rfc9051 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.9051.xml'> wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-extra-imap-partial-04" number="9394" ipr="pre5378Trust200902" updates="5267, 4731" docName="draft-ietf-extra-imap-partial-04">
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc toc="yes" ?>
	<?rfc symrefs="yes" ?>
	<?rfc sortrefs="yes"?>
	<?rfc iprnotified="no" ?>
	<?rfc strict="yes" ?>
	<?rfc comments="yes" ?>
	<?rfc inline="yes" ?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?> updates="4731, 5267" obsoletes="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.15.3 -->

        <front>
    <title abbrev="IMAP PARTIAL"> PARTIAL Extension">
IMAP PARTIAL Extension for Paged SEARCH &amp; and FETCH Extension
    </title>
    <seriesInfo name="RFC" value="9394"/>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization abbrev="Isode">
				Isode Limited
			</organization> abbrev="Isode">Isode Limited</organization>
      <address>
        <email>alexey.melnikov@isode.com</email>
        <uri>https://www.isode.com</uri>
      </address>
    </author>
    <author initials="A. P." surname="Achuthan" fullname="Arun Prakash Achuthan">
      <organization abbrev="Yahoo!">
        Yahoo!
      </organization> abbrev="Yahoo!">Yahoo!</organization>
      <address>
        <email>arunprakash@myyahoo.com</email>
      </address>
    </author>
    <author initials="V." surname="Nagulakonda" fullname="Vikram Nagulakonda">
      <organization abbrev="Yahoo!">
        Yahoo!
      </organization> abbrev="Yahoo!">Yahoo!</organization>
      <address>
        <email>nvikram_imap@yahoo.com</email>
      </address>
    </author>
    <author initials="L." surname="Alves" fullname="Luis Alves">
      <address>
        <email>luis.alves@lafaspot.com</email>
      </address>
    </author>
    <date year="2022"/> year="2023" month="June" />
    <area>art</area>
    <workgroup>extra</workgroup>
    <abstract>
      <t>The PARTIAL extension of the Internet Message Access Protocol (RFC 3501/RFC (see RFCs 3501 and 9051)
                        allows clients to limit the number of search SEARCH results returned, as well as to perform incremental (paged) searches.
      This also helps servers to optimize resource usage when performing searches.
      </t>
      <t>This document extends the PARTIAL SEARCH return option originally specified in RFC 5267.
      It also clarifies some interactions between RFC 5267 and RFC 4731/RFC RFCs 4731 and 9051.</t>

<t>This document updates RFCs 4731 and 5267.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction numbered="true" toc="default">
      <name>Introduction and Overview"> Overview</name>
      <t>This document defines an extension to the Internet Message Access Protocol <xref target="RFC3501"/> target="RFC3501" format="default"/> <xref target="RFC9051" format="default"/>
      for performing incremental searches and fetches.
      This extension is compatible with both IMAP4rev1 <xref target="RFC3501"/> target="RFC3501" format="default"/> and IMAP4rev2 <xref target="RFC9051"/>.</t> target="RFC9051" format="default"/>.
      This extension uses IMAP extensibility rules defined in <xref target="RFC4466"/>.</t>
      <t>
      The PARTIAL extension of the Internet Message Access Protocol (RFC 3501/RFC 9051)
      allows clients to limit the number of search SEARCH results returned, as well as to perform incremental (paged) searches.
      This also helps servers to optimize resource usage when performing searches.
      </t>
      <t>This document extends the PARTIAL SEARCH return option originally specified in RFC 5267.
      It also clarifies some interactions between RFC 5267 and RFC 4731/RFC RFCs 4731 and 9051.</t>
    </section>
    <section title="Document Conventions"> numbered="true" toc="default">
      <name>Document Conventions</name>
      <t>In protocol examples, this document uses a prefix of "C: " to denote lines sent by the client to the server, 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 breaks are present in the protocol unless specifically mentioned.</t>

			<t>
            The
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
            "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
            "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP
            14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.
            </t>

      <!--///Confusion: IMAP keyword is something else. Use "Protocol elements" instead?--> here.</t>
            <t>Other capitalised capitalized words are IMAP keywords key words <xref target="RFC3501"/><xref target="RFC9051"/> target="RFC3501" format="default"/> <xref target="RFC9051" format="default"/>
            or keywords key words from this document.</t>
    </section>
    <section title="The anchor="imap-partial" numbered="true" toc="default">
      <name>The PARTIAL extension" anchor="imap-partial"> Extension</name>
      <t>An IMAP server advertises support for the PARTIAL extension
        by including the "PARTIAL" capability in the CAPABILITY response/response response / response code.</t>
      <section title="Incremental anchor="partial-def" numbered="true" toc="default">
        <name>Incremental SEARCH and partial results" anchor="partial-def"> Partial Results</name>
        <t>
      The PARTIAL SEARCH return option causes the server to provide in an
      ESEARCH <xref target="RFC4731"/><xref target="RFC9051"/> response <xref target="RFC4731" format="default"/> <xref target="RFC9051" format="default"/> a subset of the results denoted by the sequence
      range given as the mandatory argument.
      The first result (message with the lowest matching UID) Unique
   Identifier (UID)) is 1;
      thus, the first 500 results would be obtained by a return option of
      "PARTIAL 1:500", 1:500" and the second 500 by "PARTIAL 501:1000".  This
      intentionally mirrors message sequence numbers.
        </t>
        <t>
      It is also possible to direct the server to start the SEARCH from the latest
      matching (with the highest UID) message. This can be done by prepending "-"
      to the index. For example example, -1 is the last message, -2 is next to the last last, and so on.
      Using this syntax helps server implementations to optimize their SEARCHes.
        </t>
        <t>
      A single command MUST NOT <bcp14>MUST NOT</bcp14> contain more than one PARTIAL or ALL search
      return option -- option; that is, either one PARTIAL, one ALL, or neither
      PARTIAL nor ALL is allowed.
        </t>
        <t>
      For SEARCH results, the entire result list MUST of results <bcp14>MUST</bcp14> be ordered in mailbox
      order,
      order -- that is, in UID or message sequence number order.
        </t>
        <t>
      Where
      In cases where a PARTIAL SEARCH return option references results that do not
      exist,
      exist by using a range which that starts or ends higher (or lower<!--In case "-N" syntax is used-->) lower) than the current
      number of results, then the server returns the results that are in
      the set.  This yields a PARTIAL return data item that has, as
      payload, the original range and a potentially missing set of results
      that may be shorter than the extent of the range.
      If the whole range references results that do not exist,
      a special value "NIL" is returned by the server instead of the sequence set.
        </t>
        <t>
      Clients need not request PARTIAL results in any particular order.
      Because mailboxes may change, clients might wish to use PARTIAL
      in combination with UPDATE (see <xref target="RFC5267"/>) target="RFC5267" format="default"/>) if the server
      also advertises CONTEXT=SEARCH the "CONTEXT=SEARCH" capability, especially if the intent is to walk a
      large set of results; however, these return options do not interact
      -- the UPDATE will provide notifications for all matching results.
        </t>

<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
  // Let's assume that the A01 SEARCH without PARTIAL would return
  // 23764 results.
  C: A01 UID SEARCH RETURN (PARTIAL -1:-100) UNDELETED
      UNKEYWORD $Junk
  S: * ESEARCH (TAG "A01") UID PARTIAL (-1:-100 ...)
  // 100 most recent results in set syntax elided.
  S: A01 OK Completed.
]]></artwork></figure>

<figure><artwork><![CDATA[
]]></artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  // Let's assume that the A02 SEARCH without PARTIAL would return
  // 23764 results.
  C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED
      UNKEYWORD $Junk
  C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED
      UNKEYWORD $Junk
  C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED
      UNKEYWORD $Junk
  S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...)
  // 264 results in set syntax elided, elided;
  // this spans the end of the results.
  S: A02 OK Completed.
  S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...)
  // 500 results in set syntax elided.
  S: A03 OK Completed.
  S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL)
  // No results are present, present; this is beyond the end of the results.
  S: A04 OK Completed.
]]></artwork></figure>
]]></artwork>
      </section>
      <section title="Interaction numbered="true" toc="default">
        <name>Interaction between PARTIAL, MIN, MAX MAX, and SAVE SEARCH return options"> Return Options</name>
        <t>This section only applies if the server advertises PARTIAL the "PARTIAL" IMAP capability or CONTEXT=SEARCH "CONTEXT=SEARCH" <xref target="RFC5267"/>, target="RFC5267" format="default"/>,
      together with ESEARCH "ESEARCH" <xref target="RFC4731"/> target="RFC4731" format="default"/> and/or IMAP4rev2 <xref target="RFC9051"/>.</t> target="RFC9051" format="default"/>.</t>
        <t>
      The SAVE result option doesn't change whether the server would return
      items corresponding to PARTIAL SEARCH result options.
        </t>
        <t>
      As specified in <xref target="partial-def"/>, target="partial-def" format="default"/>, it is an error to specify both the
      PARTIAL and ALL result options in the same SEARCH command.
        </t>
        <t>
      When the SAVE result option is combined with the PARTIAL
      result option, option and none of the MIN/MAX/COUNT result options is are
      present, the corresponding PARTIAL is returned,
      and the "$" marker would contain <!--references to-->all references to all
      messages returned by the PARTIAL result option.
        </t>
        <t>
      When the SAVE and PARTIAL result options are combined with the MIN or the MAX
      result option, option and the COUNT result option is
      absent, the corresponding PARTIAL result and MIN/MAX is are returned (if the search SEARCH result
      is not empty), and the "$" marker would contain <!--references to-->all references to all
      messages returned by the PARTIAL result option together with the corresponding MIN/MAX message.
        </t>
        <t>
      If the SAVE and PARTIAL result options are combined with both the MIN and MAX result
      options,
      options and the COUNT result options option is absent,
      the PARTIAL, MIN MIN, and MAX result options are returned (if the search SEARCH result is not empty),
      and the "$" marker would contain <!--references to-->all references to all
      messages returned by the PARTIAL result option together with the MIN and the MAX messages.
        </t>
        <t>
      If the SAVE and PARTIAL result options are combined with the COUNT
      result option, the PARTIAL and COUNT result options are returned,
      and the "$" marker would always contain references to all messages
      found by the SEARCH or UID SEARCH command.
        </t>

      <texttable>
        <preamble>
          The following table
        <t keepWithNext="true">
          <xref target="tab1"/> summarizes the additional requirement on requirements for ESEARCH
          server implementations described in this section.
        </preamble>

        <ttcol align='center'>Combination
        </t>
        <t>
          Note regarding <xref target="tab1"/>: "[m]" means optional "MIN" and/or "MAX".
        </t>

        <table anchor="tab1" align="center">
          <thead>
            <tr>
              <th align="center">Combination of Result option</ttcol>
        <ttcol align='center'>"$" marker value</ttcol>

        <c>SAVE PARTIAL</c>
        <c>PARTIAL</c>

        <c>SAVE PARTIAL MIN</c>
        <c>PARTIAL Options</th>
              <th align="center">"$" Marker Value</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">SAVE PARTIAL</td>
              <td align="center">PARTIAL</td>
            </tr>
            <tr>
              <td align="center">SAVE PARTIAL MIN</td>
              <td align="center">PARTIAL &amp; MIN</c>

        <c>SAVE PARTIAL MAX</c>
        <c>PARTIAL MIN</td>
            </tr>
            <tr>
              <td align="center">SAVE PARTIAL MAX</td>
              <td align="center">PARTIAL &amp; MAX</c>

        <c>SAVE MAX</td>
            </tr>
            <tr>
              <td align="center">SAVE PARTIAL MIN MAX</c>
        <c>PARTIAL MAX</td>
              <td align="center">PARTIAL &amp; MIN &amp; MAX</c>

        <c>SAVE MAX</td>
            </tr>
            <tr>
              <td align="center">SAVE PARTIAL COUNT [m]</c>
        <c>all [m]</td>
              <td align="center">all found messages</c>

        <postamble>
          Note for the table: '[m]' means optional "MIN" and/or "MAX"
        </postamble>

      </texttable> messages</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="Extension numbered="true" toc="default">
        <name>Extension to UID FETCH"> FETCH</name>
        <t>The PARTIAL extension also extends the UID FETCH command with a PARTIAL FETCH modifier.
      The PARTIAL FETCH modifier has the same syntax as the PARTIAL SEARCH result option.
      Presence
      The presence of the PARTIAL FETCH modifier instructs the server to only return FETCH results
      for messages in the specified range. It is useful when the sequence-set (first) parameter to in
      the UID FETCH command includes an unknown number of messages.</t>

<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
  // Returning information for the last 3 messages in the UID range
  C: 10 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL -1:-3)
  S: * 12888 FETCH (FLAGS (\Seen) UID 25996)
  S: * 12889 FETCH (FLAGS (\Flagged \Answered) UID 25997)
  S: * 12890 FETCH (FLAGS () UID 26600)
  S: 10 OK FETCH completed
]]></artwork></figure>

<figure><artwork><![CDATA[
]]></artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  // Returning information for the first 5 messages in the UID range
  C: 11 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL 1:5)
  S: * 12591 FETCH (FLAGS (\Seen) UID 25900)
  S: * 12592 FETCH (FLAGS (\Flagged) UID 25902)
  S: * 12593 FETCH (FLAGS (\Answered) UID 26310)
  S: * 12594 FETCH (FLAGS () UID 26311)
  S: * 12595 FETCH (FLAGS (\Answered) UID 26498)
  S: 11 OK FETCH completed
]]></artwork></figure>
]]></artwork>
      </section>
      <section title="Use numbered="true" toc="default">
        <name>Use of PARTIAL &quot;PARTIAL&quot; and CONDSTORE &quot;CONDSTORE&quot; IMAP extensions together"> Extensions Together</name>
        <t>This section is informative.</t>
        <t>The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE FETCH modifier.</t>

<figure><artwork><![CDATA[ modifier <xref target="RFC7162"/>.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  // Returning information for the last 30 messages in the UID range
  // that have any flag/keyword flags/keywords modified since modseq MODSEQ 98305
  C: 101 UID FETCH 25900:26600 (UID FLAGS) FLAGS
     ) (PARTIAL -1:-30 CHANGEDSINCE 98305)
  S: * 12888 FETCH (FLAGS (\Flagged \Answered) \Answered
     ) MODSEQ (98306) UID 25997)
  S: * 12890 FETCH (FLAGS () MODSEQ (98312) UID 26600)
  S: 101 OK FETCH completed
]]></artwork></figure>
]]></artwork>

        <t>The above example causes the server to first select the last 30 messages
            and then only return flag changes for a subset of these those messages which that
            have MODSEQ higher than 98305.</t>
        <t>Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers in the UID FETCH command
            is not important, i.e. i.e., the above example can also use the
            "UID FETCH 25900:26600 (UID FLAGS) (CHANGEDSINCE 98305 PARTIAL -1:-30)"
            command and it would result in the same responses.</t>
      </section>
    </section>
    <section title="Formal syntax"> numbered="true" toc="default">
      <name>Formal Syntax</name>
      <t>The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in <xref target="ABNF"/>.</t> target="RFC5234" format="default"/>.</t>
      <t>Non-terminals referenced but not defined below are as defined by <xref target="RFC3501">IMAP4rev1</xref> target="RFC3501" format="default">IMAP4rev1</xref> or <xref target="RFC9051">IMAP4rev2</xref>.</t> target="RFC9051" format="default">IMAP4rev2</xref>.</t>
      <t>Except as noted otherwise, all alphabetic characters are case-insensitive. case insensitive.
      The use of upper uppercase or lower case lowercase characters to define token strings is for editorial clarity only.
      Implementations MUST <bcp14>MUST</bcp14> accept these strings in a case-insensitive fashion.</t>

<figure><artwork>
      <![CDATA[

   <sourcecode type="abnf"><![CDATA[
SP                  = <Defined in RFC 5234>
MINUS               = "-"

capability          =/ "PARTIAL"
                       ;; <capability> from [RFC3501] [RFC3501].

modifier-partial    = "PARTIAL" SP partial-range

partial-range-first = nz-number ":" nz-number
    ;; Request to search from oldest (lowest UIDs) to
    ;; more recent messages.
    ;; A range 500:400 is the same as 400:500.
    ;; This is similar to <seq-range> from [RFC3501], [RFC3501]
    ;; but cannot contain "*".

partial-range-last  = MINUS nz-number ":" MINUS nz-number
    ;; Request to search from newest (highest UIDs) to
    ;; oldest messages.
    ;; A range -500:-400 is the same as -400:-500.

partial-range       = partial-range-first / partial-range-last

search-return-opt   =/ modifier-partial
    ;; All conform to <search-return-opt>, <search-return-opt> from [IMAP-ABNF]/[RFC9051]
    ;; [RFC4466] and [RFC9051].

search-return-data  =/ ret-data-partial

ret-data-partial    = "PARTIAL"
                      SP "(" partial-range SP partial-results ")"
    ;; <partial-range> is the requested range.

partial-results     = sequence-set / "NIL"
    ;; <sequence-set> from [RFC3501].
    ;; NIL indicates that no results correspond to
    ;; the requested range.

tagged-ext-simple   =/ partial-range-last

fetch-modifier      =/ modifier-partial
]]></artwork></figure>
                       ;; <fetch-modifier> from [RFC4466].
]]></sourcecode>

    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
      This document defines an additional IMAP4 capability.  As such, it
      does not change the underlying security considerations of IMAP4rev1
<xref target="RFC3501"/> target="RFC3501" format="default"/> and IMAP4rev2 <xref target="RFC9051"/>. target="RFC9051" format="default"/>.
      The authors and reviewers believe that no new security issues are
      introduced with these additional IMAP4 capabilities.
      </t>
      <t>
      This document defines an optimization that can both reduce both the amount of work
      performed by the server, as well at server and the amount of data returned to the client.
      Use of this extension is likely to cause the server and the client to use less memory
      than when the extension is not used. However, as this is going
      to be new code in both the client and the server, rigorous testing of such code
      is required in order to avoid introducing of new implementation bugs.
      </t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="Changes/additions numbered="true" toc="default">
        <name>Changes/Additions to the IMAP4 capabilities registry"> IMAP Capabilities Registry</name>
        <t>
                                IMAP4 capabilities are registered by publishing a standards track Standards Track or
				IESG approved
                                IESG-approved Informational or Experimental RFC.
        The registry is currently located at: at
   <eref target="https://www.iana.org/assignments/imap-capabilities" brackets="angle"/>.
        </t>

			<figure><artwork><![CDATA[
   https://www.iana.org/assignments/imap4-capabilities
    ]]></artwork></figure>
        <t>IANA is requested to add definition of has added the PARTIAL extension to the "IMAP Capabilities" registry
         with RFC XXXX 9394 as the reference.
        </t>
      </section>
    </section>
  </middle>
  <back>

<displayreference target="RFC5234" to="ABNF"/>

  <references>
    <name>References</name>
    <references>
      <name>Normative References</name>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3501.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4466.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4731.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5267.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9051.xml"/>
    </references>
    <references>
      <name>Informative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7162.xml"/>
    </references>
  </references>

    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>This document was motivated by the Yahoo! team and their questions
      about best client practices for dealing with large mailboxes.</t>
      <t>
			Editor
                        The authors of this document would like to thank the following people people,
                        who provided useful comments or participated in discussions of
      this document: Timo Sirainen and Barry Leiba. <contact fullname="Timo Sirainen"/> and <contact fullname="Barry Leiba"/>.
      </t>

      <t>This document uses lots a lot of text from RFC 5267. Thus Thus, the work of
      the RFC 5267 authors Dave Cridland -- <contact fullname="Dave Cridland"/> and Curtis King <contact fullname="Curtis King"/> -- is appreciated.
      </t>
    </section>

	</middle>
	<back>
		<references title="Normative References">
			&rfc2119;
      &rfc8174;
      &rfc3501;
      &rfc4731;
      &rfc5267;
      <reference anchor="ABNF">
				<front>
					<title>Augmented BNF for Syntax Specifications: ABNF</title>
					<author initials="D" surname="Crocker" fullname="Dave Crocker" role="editor">
						<organization />
					</author>
					<author initials="P" surname="Overell" fullname="Paul Overell" role="editor">
						<organization />
					</author>
					<date year="2008" month="January"/>
				</front>
				<seriesInfo name="RFC" value="5234" />
				<format type="TXT" target="https://www.rfc-editor.org/info/rfc5234" />
			</reference>

      &rfc9051;

    </references>

    <!--
    <references title="Informative References">
    </references>
    -->
        </back>
</rfc>