<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-jmap-blob-18" number="9404" submissionType="IETF" category="std" consensus="true" xml:lang="en" updates="8620" obsoletes="" symRefs="true" sortRefs="true" tocInclude="true" prepTime="2023-08-16T13:40:43" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-jmap-blob-18" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9404" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="JMAP Blob">JSON Meta Application Protocol (JMAP) Blob Management Extension</title>
    <seriesInfo name="RFC" value="9404" stream="IETF"/>
    <author role="editor" initials="B." surname="Gondwana" fullname="Bron Gondwana">
      <organization showOnFrontPage="true">Fastmail</organization>
      <address>
        <postal>
          <street>Level 2, 114 William St</street>
          <city>Melbourne</city>
          <region>VIC</region>
          <code>3000</code>
          <country>Australia</country>
        </postal>
        <email>brong@fastmailteam.com</email>
        <uri>https://www.fastmail.com</uri>
      </address>
    </author>
    <date month="08" year="2023"/>
    <area>art</area>
    <workgroup>jmap</workgroup>
    <keyword>jmap</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The JSON Meta Application Protocol (JMAP) base protocol (RFC 8620) provides
the ability to upload and download arbitrary binary data via HTTP POST and GET
on a defined endpoint.  This binary data is called a "blob".</t>
      <t indent="0" pn="section-abstract-2">This extension adds additional ways to create and access blobs by making
inline method calls within a standard JMAP request.</t>
      <t indent="0" pn="section-abstract-3">This extension also adds a reverse lookup mechanism to discover where blobs
are referenced within other data types.</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/rfc9404" 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) 2023 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" 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-addition-to-the-capabilitie">Addition to the Capabilities Object</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-urnietfparamsjmapblob">urn:ietf:params:jmap:blob</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-capability-example">Capability Example</xref></t>
                  </li>
                </ul>
              </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-blob-methods">Blob Methods</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-blob-upload">Blob/upload</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-blob-upload-simple-example">Blob/upload Simple Example</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-blob-upload-complex-example">Blob/upload Complex Example</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-blob-get">Blob/get</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-blob-get-simple-example">Blob/get Simple Example</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-blob-get-example-with-range">Blob/get Example with Range and Encoding Errors</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-blob-lookup">Blob/lookup</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-blob-lookup-example">Blob/lookup Example</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-security-considerations">Security Considerations</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-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-jmap-capability-registratio">JMAP Capability Registration for "blob"</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-jmap-error-codes-registrati">JMAP Error Codes Registration for "unknownDataType"</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-creation-of-jmap-data-types">Creation of "JMAP Data Types" Registry</xref></t>
              </li>
            </ul>
          </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-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</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.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Sometimes JMAP <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/> interactions require creating
a blob and then referencing it.  In the same way that IMAP literals were
extended by <xref target="RFC7888" format="default" sectionFormat="of" derivedContent="RFC7888"/>, embedding small blobs directly
into the JMAP method calls array can be an option for reducing round trips.</t>
      <t indent="0" pn="section-1-2">Likewise, when fetching an object, it can be useful to also fetch the raw
content of that object without a separate round trip.</t>
      <t indent="0" pn="section-1-3">Since raw blobs may contain arbitrary binary data, this document defines
a use of the base64 coding specified in <xref target="RFC4648" format="default" sectionFormat="of" derivedContent="RFC4648"/> for both creating and
fetching blob data.</t>
      <t indent="0" pn="section-1-4">When JMAP is proxied through a system that applies additional
access restrictions, it can be useful to know which objects reference
any particular blob; this document defines a way to discover those
references.</t>
    </section>
    <section anchor="conventions-used-in-this-document" 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 definitions of JSON keys and datatypes in the document follow the
conventions described in <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/>.</t>
    </section>
    <section anchor="addition-to-the-capabilities-object" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-addition-to-the-capabilitie">Addition to the Capabilities Object</name>
      <t indent="0" pn="section-3-1">The capabilities object is returned as part of the JMAP Session
object; see <xref target="RFC8620" sectionFormat="comma" section="2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8620#section-2" derivedContent="RFC8620"/>.</t>
      <t indent="0" pn="section-3-2">This document defines an additional capability URI.</t>
      <section anchor="urn-ietf-params-jmap-blob" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-urnietfparamsjmapblob">urn:ietf:params:jmap:blob</name>
        <t indent="0" pn="section-3.1-1">The presence of the capability <tt>urn:ietf:params:jmap:blob</tt> in the
accountCapabilities property of an account represents support for additional
API methods on the Blob datatype.  Servers that include the capability in one
or more accountCapabilities properties <bcp14>MUST</bcp14> also include the
property in the capabilities property.</t>
        <t indent="0" pn="section-3.1-2">The value of this property in the JMAP Session capabilities
property <bcp14>MUST</bcp14> be an empty object.</t>
        <t indent="0" pn="section-3.1-3">The value of this property in an account's accountCapabilities
property is an object that <bcp14>MUST</bcp14> contain the following information
on server capabilities and permissions for that account:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.1-4">
          <li pn="section-3.1-4.1">
            <t indent="0" pn="section-3.1-4.1.1">maxSizeBlobSet: "UnsignedInt|null"</t>
            <t indent="0" pn="section-3.1-4.1.2">The maximum size of the blob (in octets) that the server will
  allow to be created (including blobs created by concatenating multiple data
  sources together).</t>
            <t indent="0" pn="section-3.1-4.1.3">Clients <bcp14>MUST NOT</bcp14> attempt to create blobs larger than this
  size.</t>
            <t indent="0" pn="section-3.1-4.1.4">If this value is <tt>null</tt>, then clients are not required to limit
  the size of the blob they try to create, though servers can always reject
  creation of blobs regardless of size, e.g., due to lack of disk space or 
  per-user rate limits.</t>
          </li>
          <li pn="section-3.1-4.2">
            <t indent="0" pn="section-3.1-4.2.1">maxDataSources: "UnsignedInt"</t>
            <t indent="0" pn="section-3.1-4.2.2">The maximum number of DataSourceObjects allowed per creation in a
  Blob/upload.</t>
            <t indent="0" pn="section-3.1-4.2.3">Servers <bcp14>MUST</bcp14> allow at least 64 DataSourceObjects per
  creation.</t>
          </li>
          <li pn="section-3.1-4.3">
            <t indent="0" pn="section-3.1-4.3.1">supportedTypeNames: "String[]"</t>
            <t indent="0" pn="section-3.1-4.3.2">An array of data type names that are supported for <tt>Blob/lookup</tt>.
  If the server does not support lookups, then this will be the empty list.</t>
            <t indent="0" pn="section-3.1-4.3.3">Note that the supportedTypeNames list may include private types that are not
  in the "JMAP Data Types" registry defined by this document.  Clients
  <bcp14>MUST</bcp14> ignore type names they do not recognise.</t>
          </li>
          <li pn="section-3.1-4.4">
            <t indent="0" pn="section-3.1-4.4.1">supportedDigestAlgorithms: "String[]"</t>
            <t indent="0" pn="section-3.1-4.4.2">An array of supported digest algorithms that are supported for
  <tt>Blob/get</tt>.  If the server does not support calculating blob digests,
  then this will be the empty list.  Algorithms in this list
  <bcp14>MUST</bcp14> be present in the "HTTP Digest Algorithm Values"
  registry defined by <xref target="RFC3230" format="default" sectionFormat="of" derivedContent="RFC3230"/>; however, in JMAP, they
  must be lowercased, e.g., "md5" rather than "MD5".</t>
            <t indent="0" pn="section-3.1-4.4.3">Clients <bcp14>SHOULD</bcp14> prefer algorithms listed earlier in this
  list.</t>
          </li>
        </ul>
        <section anchor="capability-example" numbered="true" removeInRFC="false" toc="include" pn="section-3.1.1">
          <name slugifiedName="name-capability-example">Capability Example</name>
          <sourcecode type="json" markers="false" pn="section-3.1.1-1">{
  "capabilities": {
    ...,
    "urn:ietf:params:jmap:blob": {}
  },
  "accounts": {
    "A13842": {
      ...
      "accountCapabilities": {
        "urn:ietf:params:jmap:blob": {
          "maxSizeBlobSet": 50000000,
          "maxDataSources": 100,
          "supportedTypeNames" : [
            "Mailbox",
            "Thread",
            "Email"
          ],
          "supportedDigestAlgorithms" : [
            "sha",
            "sha-256"
          ]
        }
      }
    }
  }
}</sourcecode>
        </section>
      </section>
    </section>
    <section anchor="blob-methods" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-blob-methods">Blob Methods</name>
      <t indent="0" pn="section-4-1">A blob is a sequence of zero or more octets.</t>
      <t indent="0" pn="section-4-2">JMAP <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/> defines the
<tt>Blob/copy</tt> method, which is unchanged by this specification and is
selected by the <tt>urn:ietf:params:jmap:core</tt> capability.</t>
      <t indent="0" pn="section-4-3">The following JMAP methods are selected by the
<tt>urn:ietf:params:jmap:blob</tt> capability.</t>
      <section anchor="blob-upload" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-blob-upload">Blob/upload</name>
        <t indent="0" pn="section-4.1-1">This is similar to a Foo/set in <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/> in some
ways. However, blobs cannot be updated or deleted, so only <tt>create</tt> is
allowed in the method call. Also, blobs do not have state, so there is no
<tt>state</tt> field present in the method response.</t>
        <t indent="0" pn="section-4.1-2"><strong>Parameters</strong></t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.1-3">
          <li pn="section-4.1-3.1">
            <t indent="0" pn="section-4.1-3.1.1">accountId: "Id"</t>
            <t indent="0" pn="section-4.1-3.1.2">The id of the account in which the blobs will be created.</t>
          </li>
          <li pn="section-4.1-3.2">
            <t indent="0" pn="section-4.1-3.2.1">create: "Id[UploadObject]"</t>
            <t indent="0" pn="section-4.1-3.2.2">A map of creation id to UploadObjects.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-4"><strong>Result</strong></t>
        <t indent="0" pn="section-4.1-5">The result is the same as for Foo/set in <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/>, with <tt>created</tt> and <tt>notCreated</tt> objects
mapping from the creation id.</t>
        <t indent="0" pn="section-4.1-6">The <tt>created</tt> objects contain:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.1-7">
          <li pn="section-4.1-7.1">
            <t indent="0" pn="section-4.1-7.1.1">id: "Id"</t>
            <t indent="0" pn="section-4.1-7.1.2">The blobId that was created.</t>
          </li>
          <li pn="section-4.1-7.2">
            <t indent="0" pn="section-4.1-7.2.1">type: "String|null"</t>
            <t indent="0" pn="section-4.1-7.2.2">The media type as given in the creation (if any). If not provided, the
  server <bcp14>MAY</bcp14> perform content analysis and return one of the
  following: the calculated value, "application/octet-string", or
  null.</t>
          </li>
          <li pn="section-4.1-7.3">
            <t indent="0" pn="section-4.1-7.3.1">size: "UnsignedInt"</t>
            <t indent="0" pn="section-4.1-7.3.2">As per <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/>, the size of the
  created blob in octets.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-8">The created objects will also contain any other properties identical to
   those that would be returned in the JSON response of the upload endpoint
   described in <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/>.  This may be
   extended in the future; in this document, it is anticipated that
   implementations will extend both the upload endpoint and the Blob/upload
   responses in the same way.</t>
        <t indent="0" pn="section-4.1-9">If there is a problem with a creation, then the server will return a
<tt>notCreated</tt> response with a map from the failed creation id to a
<tt>SetError</tt> object.</t>
        <t indent="0" pn="section-4.1-10">For each successful upload, servers <bcp14>MUST</bcp14> add an entry to the
<tt>createdIds</tt> map (<xref target="RFC8620" sectionFormat="comma" section="3.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8620#section-3.3" derivedContent="RFC8620"/>) for the request; even if the caller did not explicitly pass a
createdIds, the value must be available to later methods defined in the same
Request Object. This allows the blobId to be used via back-reference in
subsequent method calls.</t>
        <t indent="0" pn="section-4.1-11">The created blob will have the same lifetime and same expiry semantics as
any other binary object created via the mechanism specified in <xref target="RFC8620" sectionFormat="comma" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8620#section-6" derivedContent="RFC8620"/>.</t>
        <t indent="0" pn="section-4.1-12">Uploads using this mechanism will be restricted by the maxUploadSize limit
for JMAP requests specified by the server, and clients <bcp14>SHOULD</bcp14>
consider using the upload mechanism defined by <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/> for blobs larger than a megabyte.</t>
        <t indent="0" pn="section-4.1-13"><strong>UploadObject</strong></t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.1-14">
          <li pn="section-4.1-14.1">
            <t indent="0" pn="section-4.1-14.1.1">data: "DataSourceObject[]"</t>
            <t indent="0" pn="section-4.1-14.1.2">An array of zero or more octet sources in order (zero to create an empty
  blob).  The result of each of these sources is concatenated in
  order to create the blob.</t>
          </li>
          <li pn="section-4.1-14.2">
            <t indent="0" pn="section-4.1-14.2.1">type: "String|null" (default: null)</t>
            <t indent="0" pn="section-4.1-14.2.2">A hint for media type of the data.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-15"><strong>DataSourceObject</strong></t>
        <t indent="0" pn="section-4.1-16">Exactly one of:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-17">
          <li pn="section-4.1-17.1">
            <t indent="0" pn="section-4.1-17.1.1">data:asText: "String|null" (raw octets, must be UTF-8)</t>
          </li>
          <li pn="section-4.1-17.2">
            <t indent="0" pn="section-4.1-17.2.1">data:asBase64: "String|null" (base64 representation of octets)</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-18">or a blobId source:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-19">
          <li pn="section-4.1-19.1">
            <t indent="0" pn="section-4.1-19.1.1">blobId: "Id"</t>
          </li>
          <li pn="section-4.1-19.2">
            <t indent="0" pn="section-4.1-19.2.1">offset: "UnsignedInt|null" (<bcp14>MAY</bcp14> be zero)</t>
          </li>
          <li pn="section-4.1-19.3">
            <t indent="0" pn="section-4.1-19.3.1">length: "UnsignedInt|null" (<bcp14>MAY</bcp14> be zero)</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-20">If <tt>null</tt>, then offset is assumed to be zero.</t>
        <t indent="0" pn="section-4.1-21">If <tt>null</tt>, then length is the remaining octets in the blob.</t>
        <t indent="0" pn="section-4.1-22">If the range cannot be fully satisfied (i.e., it begins or extends past
the end of the data in the blob), then the DataSourceObject is invalid
and results in a notCreated response for this creation id.</t>
        <t indent="0" pn="section-4.1-23">If the data properties have any invalid references or invalid data
contained in them, the server <bcp14>MUST NOT</bcp14> guess the user's intent
and <bcp14>MUST</bcp14> reject the creation and return a notCreated response for that
creation id.</t>
        <t indent="0" pn="section-4.1-24">Likewise, invalid characters in the base64 of data:asBase64 or invalid
UTF-8 in data:asText <bcp14>MUST</bcp14> result in a notCreated response.</t>
        <t indent="0" pn="section-4.1-25">It is envisaged that the definition for DataSourceObject might be
extended in the future, for example, to fetch external content.</t>
        <t indent="0" pn="section-4.1-26">A server <bcp14>MUST</bcp14> accept at least 64 DataSourceObjects per create, as
described in <xref target="urn-ietf-params-jmap-blob" format="default" sectionFormat="of" derivedContent="Section 3.1"/> of this document.</t>
        <section anchor="blob-upload-simple-example" numbered="true" removeInRFC="false" toc="include" pn="section-4.1.1">
          <name slugifiedName="name-blob-upload-simple-example">Blob/upload Simple Example</name>
          <t indent="0" pn="section-4.1.1-1">The data:asBase64 field is set over multiple lines for ease of publication
here; however, the entire data:asBase64 field would be sent as a continuous
string with no wrapping on the wire.</t>
          <t indent="0" pn="section-4.1.1-2">Method Call:</t>
          <sourcecode type="json" markers="false" pn="section-4.1.1-3">
[
 "Blob/upload",
 {
  "accountId": "account1",
  "create": {
   "1": {
    "data" : [
    {
     "data:asBase64": "iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKA
                       AAAA1BMVEX/AAAZ4gk3AAAAAXRSTlN/gFy0ywAAAApJRE
                       FUeJxjYgAAAAYAAzY3fKgAAAAASUVORK5CYII="
    }
   ],
   "type": "image/png"
   }
  }
 },
 "R1"
]</sourcecode>
          <t indent="0" pn="section-4.1.1-4">Response:</t>
          <sourcecode type="json" markers="false" pn="section-4.1.1-5">[
  "Blob/upload",
  {
    "accountId" : "account1",
    "created" : {
      "1": {
        "id" : "G4c6751edf9dd6903ff54b792e432fba781271beb",
        "type" : "image/png",
        "size" : 95
      }
    }
  },
  "R1"
]</sourcecode>
        </section>
        <section anchor="blob-upload-complex-example" numbered="true" removeInRFC="false" toc="include" pn="section-4.1.2">
          <name slugifiedName="name-blob-upload-complex-example">Blob/upload Complex Example</name>
          <t indent="0" pn="section-4.1.2-1">Method Calls:</t>
          <sourcecode type="json" markers="false" pn="section-4.1.2-2">
[
 [
  "Blob/upload",
  {
   "create": {
    "b4": {
     "data": [
      {
       "data:asText": "The quick brown fox jumped over the lazy dog."
      }
    ]
   }
  }
 },
 "S4"
],
[
  "Blob/upload",
  {
   "create": {
     "cat": {
       "data": [
         {
           "data:asText": "How"
         },
         {
           "blobId": "#b4",
           "length": 7,
           "offset": 3
         },
         {
           "data:asText": "was t"
         },
         {
           "blobId": "#b4",
           "length": 1,
           "offset": 1
         },
         {
           "data:asBase64": "YXQ/"
         }
       ]
     }
   }
  },
  "CAT"
],
[
  "Blob/get",
  {
   "properties": [
     "data:asText",
     "size"
   ],
   "ids": [
     "#cat"
   ]
  },
  "G4"
 ]
]</sourcecode>
          <t indent="0" pn="section-4.1.2-3">Responses:</t>
          <sourcecode type="json" markers="false" pn="section-4.1.2-4">[
  [
    "Blob/upload",
    {
      "oldState": null,
      "created": {
        "b4": {
          "id": "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e",
          "size": 45,
          "type": "application/octet-stream"
        }
      },
      "notCreated": null,
      "accountId": "account1"
    },
    "S4"
  ],
  [
    "Blob/upload",
    {
      "oldState": null,
      "created": {
        "cat": {
          "id": "Gcc60576f036321ae6e8037ffc56bdee589bd3e23",
          "size": 19,
          "type": "application/octet-stream"
        }
      },
      "notCreated": null,
      "accountId": "account1"
    },
    "CAT"
  ],
  [
    "Blob/get",
    {
      "list": [
        {
          "id": "Gcc60576f036321ae6e8037ffc56bdee589bd3e23",
          "data:asText": "How quick was that?",
          "size": 19
        }
      ],
      "notFound": [],
      "accountId": "account1"
    },
    "G4"
  ]
]</sourcecode>
        </section>
      </section>
      <section anchor="blob-get" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-blob-get">Blob/get</name>
        <t indent="0" pn="section-4.2-1">A standard JMAP get, with two additional optional parameters:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.2-2">
          <li pn="section-4.2-2.1">
            <t indent="0" pn="section-4.2-2.1.1">offset: "UnsignedInt|null"</t>
            <t indent="0" pn="section-4.2-2.1.2">Start this many octets into the blob data.  If null or unspecified, this
  defaults to zero.</t>
          </li>
          <li pn="section-4.2-2.2">
            <t indent="0" pn="section-4.2-2.2.1">length: "UnsignedInt|null"</t>
            <t indent="0" pn="section-4.2-2.2.2">Return at most this many octets of the blob data.  If null or
  unspecified, then all remaining octets in the blob are returned.  This can
  be considered equivalent to an infinitely large length value, except that
  the isTruncated warning is not given unless the start offset is past the end
  of the blob.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.2-3"><strong>Request Properties:</strong></t>
        <t indent="0" pn="section-4.2-4">Any of:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2-5">
          <li pn="section-4.2-5.1">data:asText</li>
          <li pn="section-4.2-5.2">data:asBase64</li>
          <li pn="section-4.2-5.3">data (returns data:asText if the selected octets are valid UTF-8 or data:asBase64)</li>
          <li pn="section-4.2-5.4">digest:&lt;algorithm&gt; (where &lt;algorithm&gt; is one of the named algorithms in the <tt>supportedDigestAlgorithms</tt> capability)</li>
          <li pn="section-4.2-5.5">size</li>
        </ul>
        <t indent="0" pn="section-4.2-6">If not given, the properties default to <tt>data</tt> and <tt>size</tt>.</t>
        <t indent="0" pn="section-4.2-7"><strong>Result Properties:</strong></t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.2-8">
          <li pn="section-4.2-8.1">
            <t indent="0" pn="section-4.2-8.1.1">data:asText: "String|null"</t>
            <t indent="0" pn="section-4.2-8.1.2">The raw octets of the selected range if they are valid UTF-8; otherwise,
  null.</t>
          </li>
          <li pn="section-4.2-8.2">
            <t indent="0" pn="section-4.2-8.2.1">data:asBase64: "String"</t>
            <t indent="0" pn="section-4.2-8.2.2">The base64 encoding of the octets in the selected range.</t>
          </li>
          <li pn="section-4.2-8.3">
            <t indent="0" pn="section-4.2-8.3.1">digest:&lt;algorithm&gt;: "String"</t>
            <t indent="0" pn="section-4.2-8.3.2">The base64 encoding of the digest of the octets in the selected range,
  calculated using the named algorithm.</t>
          </li>
          <li pn="section-4.2-8.4">
            <t indent="0" pn="section-4.2-8.4.1">isEncodingProblem: "Boolean" (default: false)</t>
          </li>
          <li pn="section-4.2-8.5">
            <t indent="0" pn="section-4.2-8.5.1">isTruncated: "Boolean" (default: false)</t>
          </li>
          <li pn="section-4.2-8.6">
            <t indent="0" pn="section-4.2-8.6.1">size: "UnsignedInt"</t>
            <t indent="0" pn="section-4.2-8.6.2">The number of octets in the entire blob.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.2-9">The size value <bcp14>MUST</bcp14> always be the number of octets in the underlying blob,
regardless of offset and length.</t>
        <t indent="0" pn="section-4.2-10">The data fields contain a representation of the octets within the selected
range that are present in the blob.  If the octets selected are not valid
UTF-8 (including truncating in the middle of a multi-octet sequence)
and <tt>data</tt> or <tt>data:asText</tt> was requested, then the key <tt>isEncodingProblem</tt>
          <bcp14>MUST</bcp14> be set to <tt>true</tt>, and the <tt>data:asText</tt> response value <bcp14>MUST</bcp14> be <tt>null</tt>.
In the case where <tt>data</tt> was requested and the data is not valid UTF-8,
then <tt>data:asBase64</tt> <bcp14>MUST</bcp14> be returned.</t>
        <t indent="0" pn="section-4.2-11">If the selected range requests data outside the blob (i.e., the
offset+length is larger than the blob), then the result is either just the
octets from the offset to the end of the blob or an empty string if the
offset is past the end of the blob.  Either way, the isTruncated
property in the result <bcp14>MUST</bcp14> be set to <tt>true</tt> to tell the
client that the requested range could not be fully satisfied.  If digest was
requested, any <tt>digest</tt> is calculated on the octets that would be
returned for a <tt>data</tt> field.</t>
        <t indent="0" pn="section-4.2-12">Servers <bcp14>SHOULD</bcp14> store the size for blobs in a format that is
efficient to read, and clients <bcp14>SHOULD</bcp14> limit their request to
just the size parameter if that is all they need, as fetching blob content
could be significantly more expensive and slower for the server.</t>
        <section anchor="blob-get-simple-example" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.1">
          <name slugifiedName="name-blob-get-simple-example">Blob/get Simple Example</name>
          <t indent="0" pn="section-4.2.1-1">In this example, a blob containing the string "The quick brown fox jumped over
the lazy dog." has blobId <tt>Gc0854fb9fb03c41cce3802cb0d220529e6eef94e</tt>.</t>
          <t indent="0" pn="section-4.2.1-2">The first method call requests just the size for multiple blobs, and
the second requests both the size and a short range of the data for one
of the blobs.</t>
          <t indent="0" pn="section-4.2.1-3">Method Calls:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.1-4">[
  [
    "Blob/get",
    {
      "accountId" : "account1",
      "ids" : [
        "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e",
        "not-a-blob"
      ],
      "properties" : [
        "data:asText",
        "digest:sha",
        "size"
      ]
    },
    "R1"
  ],
  [
    "Blob/get",
    {
      "accountId" : "account1",
      "ids" : [
        "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e"
      ],
      "properties" : [
        "data:asText",
        "digest:sha",
        "digest:sha-256",
        "size"
      ],
      "offset" : 4,
      "length" : 9
    },
    "R2"
  ]
]</sourcecode>
          <t indent="0" pn="section-4.2.1-5">Responses:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.1-6">
[
 [
  "Blob/get",
  {
   "accountId": "account1",
   "list": [
    {
     "id": "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e",
     "data:asText": "The quick brown fox jumped over the lazy dog.",
     "digest:sha": "wIVPufsDxBzOOALLDSIFKebu+U4=",
     "size": 45
    }
  ],
  "notFound": [
   "not-a-blob"
  ]
 },
 "R1"
],
[
 "Blob/get",
 {
  "accountId": "account1",
  "list": [
   {
    "id": "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e",
    "data:asText": "quick bro",
    "digest:sha": "QiRAPtfyX8K6tm1iOAtZ87Xj3Ww=",
    "digest:sha-256": "gdg9INW7lwHK6OQ9u0dwDz2ZY/gubi0En0xlFpKt0OA=",
    "size": 45
    }
   ]
  },
  "R2"
 ]
]</sourcecode>
        </section>
        <section anchor="blob-get-example-with-range-and-encoding-errors" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.2">
          <name slugifiedName="name-blob-get-example-with-range">Blob/get Example with Range and Encoding Errors</name>
          <t indent="0" pn="section-4.2.2-1">The <tt>b1</tt> value is the text "The quick brown fox jumped over the \x81\x81 dog.", which contains an invalid UTF-8 sequence.</t>
          <t indent="0" pn="section-4.2.2-2">The results have the following properties:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.2.2-3">
            <li pn="section-4.2.2-3.1">
              <t indent="0" pn="section-4.2.2-3.1.1">G1: Defaults to <tt>data</tt> and <tt>size</tt>, so b1 returns
<tt>isEncodingProblem</tt> and a base64 value.</t>
            </li>
            <li pn="section-4.2.2-3.2">
              <t indent="0" pn="section-4.2.2-3.2.1">G2: Since <tt>data:asText</tt> was explicitly selected, does not
attempt to return a value for the data, just <tt>isEncodingProblem</tt> for
b1.</t>
            </li>
            <li pn="section-4.2.2-3.3">
              <t indent="0" pn="section-4.2.2-3.3.1">G3: Since only <tt>data:asBase64</tt> was requested, there is no
encoding problem, and both values are returned.</t>
            </li>
            <li pn="section-4.2.2-3.4">
              <t indent="0" pn="section-4.2.2-3.4.1">G4: Since the requested range could be satisfied as text, both blobs
are returned as <tt>data:asText</tt>, and there is no encoding problem.</t>
            </li>
            <li pn="section-4.2.2-3.5">
              <t indent="0" pn="section-4.2.2-3.5.1">G5: Both blobs cannot satisfy the requested range, so isTruncated is
true for both.</t>
            </li>
          </ul>
          <aside pn="section-4.2.2-4">
            <t indent="0" pn="section-4.2.2-4.1">Note: Some values have been wrapped for line length. There would be
no wrapping in the <tt>data:asBase64</tt> values on the wire.</t>
          </aside>
          <t indent="0" pn="section-4.2.2-5">Method Calls:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.2-6">[
  [
    "Blob/upload",
    {
      "create": {
        "b1": {
          "data": [
            {
              "data:asBase64": "VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZW
                                Qgb3ZlciB0aGUggYEgZG9nLg=="
            }
          ]
        },
        "b2": {
          "data": [
            {
              "data:asText": "hello world"
            }
          ],
          "type" : "text/plain"
        }
      }
    },
    "S1"
  ],
  [
    "Blob/get",
    {
      "ids": [
        "#b1",
        "#b2"
      ]
    },
    "G1"
  ],
  [
    "Blob/get",
    {
      "ids": [
        "#b1",
        "#b2"
      ],
      "properties": [
        "data:asText",
        "size"
      ]
    },
    "G2"
  ],
  [
    "Blob/get",
    {
      "ids": [
        "#b1",
        "#b2"
      ],
      "properties": [
        "data:asBase64",
        "size"
      ]
    },
    "G3"
  ],
  [
    "Blob/get",
    {
      "offset": 0,
      "length": 5,
      "ids": [
        "#b1",
        "#b2"
      ]
    },
    "G4"
  ],
  [
    "Blob/get",
    {
      "offset": 20,
      "length": 100,
      "ids": [
        "#b1",
        "#b2"
      ]
    },
    "G5"
  ]
]</sourcecode>
          <t indent="0" pn="section-4.2.2-7">Responses:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.2-8">[
  [
    "Blob/upload",
    {
      "oldState": null,
      "created": {
        "b2": {
          "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
          "size": 11,
          "type": "application/octet-stream"
        },
        "b1": {
          "id": "G72cfa4804194563685d9a4b695f7ba20e7739576",
          "size": 43,
          "type": "text/plain"
        }
      },
      "updated": null,
      "destroyed": null,
      "notCreated": null,
      "notUpdated": null,
      "notDestroyed": null,
      "accountId": "account1"
    },
    "S1"
  ],
  [
    "Blob/get",
    {
      "list": [
        {
          "id": "G72cfa4804194563685d9a4b695f7ba20e7739576",
          "isEncodingProblem": true,
          "data:asBase64": "VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZW
                            Qgb3ZlciB0aGUggYEgZG9nLg==",
          "size": 43
        },
        {
          "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
          "data:asText": "hello world",
          "size": 11
        }
      ],
      "notFound": [],
      "accountId": "account1"
    },
    "G1"
  ],
  [
    "Blob/get",
    {
      "list": [
        {
          "id": "G72cfa4804194563685d9a4b695f7ba20e7739576",
          "isEncodingProblem": true,
          "size": 43
        },
        {
          "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
          "data:asText": "hello world",
          "size": 11
        }
      ],
      "notFound": [],
      "accountId": "account1"
    },
    "G2"
  ],
  [
    "Blob/get",
    {
      "list": [
        {
          "id": "G72cfa4804194563685d9a4b695f7ba20e7739576",
          "data:asBase64": "VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZW
                            Qgb3ZlciB0aGUggYEgZG9nLg==",
          "size": 43
        },
        {
          "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
          "data:asBase64": "aGVsbG8gd29ybGQ=",
          "size": 11
        }
      ],
      "notFound": [],
      "accountId": "account1"
    },
    "G3"
  ],
  [
    "Blob/get",
    {
      "list": [
        {
          "id": "G72cfa4804194563685d9a4b695f7ba20e7739576",
          "data:asText": "The q",
          "size": 43
        },
        {
          "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
          "data:asText": "hello",
          "size": 11
        }
      ],
      "notFound": [],
      "accountId": "account1"
    },
    "G4"
  ],
  [
    "Blob/get",
    {
      "list": [
        {
          "id": "G72cfa4804194563685d9a4b695f7ba20e7739576",
          "isTruncated": true,
          "isEncodingProblem": true,
          "data:asBase64": "anVtcGVkIG92ZXIgdGhlIIGBIGRvZy4=",
          "size": 43
        },
        {
          "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
          "isTruncated": true,
          "data:asText": "",
          "size": 11
        }
      ],
      "notFound": [],
      "accountId": "account1"
    },
    "G5"
  ]
]</sourcecode>
        </section>
      </section>
      <section anchor="blob-lookup" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-blob-lookup">Blob/lookup</name>
        <t indent="0" pn="section-4.3-1">Given a list of blobIds, this method does a reverse lookup in each of
the provided type names to find the list of Ids within that data type
that reference the provided blob.</t>
        <t indent="0" pn="section-4.3-2">Since different datatypes will have different semantics of "contains",
the definition of "reference" is somewhat loose but roughly
means "you could discover this blobId by looking at this object or
at other objects recursively contained within this object".</t>
        <t indent="0" pn="section-4.3-3">For example, with a server that supports <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621"/>, if a Mailbox references a blob and if any Emails
within that Mailbox reference the blobId, then the Mailbox references that
blobId.  For any Thread that references an Email that references a blobId, it
can be said that the Thread references the blobId.</t>
        <t indent="0" pn="section-4.3-4">However, this does not mean that if an Email references a Mailbox in its
mailboxIds property, then any blobId referenced by other Emails in
that Mailbox are also referenced by the initial Email.</t>
        <t indent="0" pn="section-4.3-5"><strong>Parameters</strong></t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.3-6">
          <li pn="section-4.3-6.1">
            <t indent="0" pn="section-4.3-6.1.1">accountId: "Id"</t>
            <t indent="0" pn="section-4.3-6.1.2">The id of the account used for the call.</t>
          </li>
          <li pn="section-4.3-6.2">
            <t indent="0" pn="section-4.3-6.2.1">typeNames: "String[]"</t>
            <t indent="0" pn="section-4.3-6.2.2">A list of names from the "JMAP Data Types" registry or defined by
private extensions that the client has requested.  Only names
for which "Can reference blobs" is true may be specified, and the
capability that defines each type must also be used by the overall
JMAP request in which this method is called.</t>
            <t indent="0" pn="section-4.3-6.2.3">If a type name is not known by the server, or the associated capability
has not been requested, then the server returns an "unknownDataType"
error.</t>
          </li>
          <li pn="section-4.3-6.3">
            <t indent="0" pn="section-4.3-6.3.1">ids: "Id[]"</t>
            <t indent="0" pn="section-4.3-6.3.2">A list of blobId values to be looked for.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.3-7"><strong>Response</strong></t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.3-8">
          <li pn="section-4.3-8.1">
            <t indent="0" pn="section-4.3-8.1.1">list: "BlobInfo[]"</t>
            <t indent="0" pn="section-4.3-8.1.2">A list of BlobInfo objects.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.3-9"><strong>BlobInfo Object</strong></t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.3-10">
          <li pn="section-4.3-10.1">
            <t indent="0" pn="section-4.3-10.1.1">id: "Id"</t>
            <t indent="0" pn="section-4.3-10.1.2">The blobId.</t>
          </li>
          <li pn="section-4.3-10.2">
            <t indent="0" pn="section-4.3-10.2.1">matchedIds: "String[Id[]]"</t>
            <t indent="0" pn="section-4.3-10.2.2">A map from type name to a list of Ids of that data type (e.g., the name
"Email" maps to a list of emailIds).</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.3-11">If a blob is not visible to a user or does not exist on the server at all,
then the server <bcp14>MUST</bcp14> still return an empty array for each type
as this doesn't leak any information about whether the blob is on the server
but not visible to the requesting user.</t>
        <section anchor="blob-lookup-example" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.1">
          <name slugifiedName="name-blob-lookup-example">Blob/lookup Example</name>
          <t indent="0" pn="section-4.3.1-1">Method Call:</t>
          <sourcecode type="json" markers="false" pn="section-4.3.1-2">[
  "Blob/lookup",
  {
    "typeNames": [
      "Mailbox",
      "Thread",
      "Email"
    ],
    "ids": [
      "Gd2f81008cf07d2425418f7f02a3ca63a8bc82003",
      "not-a-blob"
    ]
  },
  "R1"
]</sourcecode>
          <t indent="0" pn="section-4.3.1-3">Response:</t>
          <sourcecode type="json" markers="false" pn="section-4.3.1-4">[
  "Blob/lookup",
  {
    "list": [
      {
        "id": "Gd2f81008cf07d2425418f7f02a3ca63a8bc82003",
        "matchedIds": {
          "Mailbox": [
            "M54e97373",
            "Mcbe6b662"
          ],
          "Thread": [
            "T1530616e"
          ],
          "Email": [
            "E16e70a73eb4",
            "E84b0930cf16"
          ]
        }
      }
    ],
    "notFound": [
      "not-a-blob"
    ]
  },
  "R1"
]</sourcecode>
        </section>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">All security considerations for JMAP <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/> apply to this specification.
Additional considerations specific to the data types and functionality
introduced by this document are described here.</t>
      <t indent="0" pn="section-5-2">JSON parsers are not all consistent in handling non-UTF-8 data.
JMAP requires that all JSON data be UTF-8 encoded, so servers
<bcp14>MUST</bcp14> only return a null value if <tt>data:asText</tt> is
requested for a range of octets that is not valid UTF-8 and set
<tt>isEncodingProblem: true</tt>.</t>
      <t indent="0" pn="section-5-3">Servers <bcp14>MUST</bcp14> apply any access controls, such that if the authenticated user would
be unable to discover the blobId by making queries, then this fact cannot be
discovered via a Blob/lookup.  For example, if an Email exists in a Mailbox that
the authenticated user does not have access to see, then that emailId <bcp14>MUST NOT</bcp14> be
returned in a lookup for a blob that is referenced by that email.</t>
      <t indent="0" pn="section-5-4">The server <bcp14>MUST NOT</bcp14> trust that the data given to a
Blob/upload is a well-formed instance of the specified media type. Also, if
the server attempts to parse the given blob, only hardened parsers designed to
deal with arbitrary untrusted data should be used.  The server <bcp14>SHOULD NOT</bcp14> reject data on the grounds that it is not a valid specimen of the
stated type.</t>
      <t indent="0" pn="section-5-5">With carefully chosen data sources, Blob/upload can be used to recreate
dangerous content on the far side of security scanners (anti-virus or
exfiltration scanners, for example) that may be watching the upload endpoint.
Server implementations <bcp14>SHOULD</bcp14> provide a hook to allow security
scanners to check the resulting blob after concatenating the data sources in
the same way that they do for the upload endpoint.</t>
      <t indent="0" pn="section-5-6">Digest algorithms can be expensive for servers to calculate.  Servers that
share resources between multiple users should track resource usage by clients
and rate-limit expensive operations to avoid resource starvation.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="jmap-capability-registration-for-blob" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-jmap-capability-registratio">JMAP Capability Registration for "blob"</name>
        <t indent="0" pn="section-6.1-1">IANA has registered the "blob" JMAP capability as follows:</t>
        <dl newline="false" spacing="compact" indent="3" pn="section-6.1-2">
          <dt pn="section-6.1-2.1">Capability Name:</dt>
          <dd pn="section-6.1-2.2">urn:ietf:params:jmap:blob</dd>
          <dt pn="section-6.1-2.3">Specification document:</dt>
          <dd pn="section-6.1-2.4">RFC 9404</dd>
          <dt pn="section-6.1-2.5">Intended use:</dt>
          <dd pn="section-6.1-2.6">common</dd>
          <dt pn="section-6.1-2.7">Change Controller:</dt>
          <dd pn="section-6.1-2.8">IETF</dd>
          <dt pn="section-6.1-2.9">Security and privacy considerations:</dt>
          <dd pn="section-6.1-2.10">RFC 9404, <xref target="security-considerations" format="default" sectionFormat="of" derivedContent="Section 5"/></dd>
        </dl>
      </section>
      <section anchor="jmap-error-codes-registration-for-unknowndatatype" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-jmap-error-codes-registrati">JMAP Error Codes Registration for "unknownDataType"</name>
        <t indent="0" pn="section-6.2-1">IANA has registered the "unknownDataType" JMAP error code as follows:</t>
        <dl newline="false" spacing="compact" indent="3" pn="section-6.2-2">
          <dt pn="section-6.2-2.1">JMAP Error Code:</dt>
          <dd pn="section-6.2-2.2">unknownDataType</dd>
          <dt pn="section-6.2-2.3">Intended use:</dt>
          <dd pn="section-6.2-2.4">common</dd>
          <dt pn="section-6.2-2.5">Change Controller:</dt>
          <dd pn="section-6.2-2.6">IETF</dd>
          <dt pn="section-6.2-2.7">Reference:</dt>
          <dd pn="section-6.2-2.8">RFC 9404</dd>
          <dt pn="section-6.2-2.9">Description:</dt>
          <dd pn="section-6.2-2.10">The server does not recognise this data type, or
  the capability to enable it is not present in the current Request
  Object.</dd>
        </dl>
      </section>
      <section anchor="creation-of-jmap-data-types-registry" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-creation-of-jmap-data-types">Creation of "JMAP Data Types" Registry</name>
        <t indent="0" pn="section-6.3-1">IANA has created a new registry called "JMAP Data Types".  <xref target="ianatable" format="default" sectionFormat="of" derivedContent="Table 1"/> shows the initial contents of this
new registry.</t>
        <table anchor="ianatable" align="center" pn="table-1">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Type Name</th>
              <th align="left" colspan="1" rowspan="1">Can Ref Blobs</th>
              <th align="left" colspan="1" rowspan="1">Can Use for State Change</th>
              <th align="left" colspan="1" rowspan="1">Capability</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">Core</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">urn:ietf:params:jmap:core</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">PushSubscription</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">urn:ietf:params:jmap:core</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8620" format="default" sectionFormat="of" derivedContent="RFC8620"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Mailbox</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">urn:ietf:params:jmap:mail</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Thread</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">urn:ietf:params:jmap:mail</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Email</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">urn:ietf:params:jmap:mail</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">EmailDelivery</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">urn:ietf:params:jmap:mail</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">SearchSnippet</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">urn:ietf:params:jmap:mail</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">Identity</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">urn:ietf:params:jmap:​submission</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">EmailSubmission</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">urn:ietf:params:jmap:​submission</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">VacationResponse</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">Yes</td>
              <td align="left" colspan="1" rowspan="1">urn:ietf:params:jmap:​vacationresponse</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8621" format="default" sectionFormat="of" derivedContent="RFC8621"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MDN</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">No</td>
              <td align="left" colspan="1" rowspan="1">urn:ietf:params:jmap:mdn</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC9007" format="default" sectionFormat="of" derivedContent="RFC9007"/></td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-6.3-3">The registration policy for this registry is "Specification Required" <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. Either an RFC or a similarly stable reference document defines a JMAP Data Type
and associated capability.</t>
        <t indent="0" pn="section-6.3-4">IANA will appoint designated experts to review requests for additions to this
registry, with guidance to allow any registration that provides a stable document describing
the capability and control over the URI namespace to which the capability URI points.</t>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3230" target="https://www.rfc-editor.org/info/rfc3230" quoteTitle="true" derivedAnchor="RFC3230">
          <front>
            <title>Instance Digests in HTTP</title>
            <author fullname="J. Mogul" initials="J." surname="Mogul"/>
            <author fullname="A. Van Hoff" initials="A." surname="Van Hoff"/>
            <date month="January" year="2002"/>
            <abstract>
              <t indent="0">HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3230"/>
          <seriesInfo name="DOI" value="10.17487/RFC3230"/>
        </reference>
        <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648" quoteTitle="true" derivedAnchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t indent="0">This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </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="RFC8620" target="https://www.rfc-editor.org/info/rfc8620" quoteTitle="true" derivedAnchor="RFC8620">
          <front>
            <title>The JSON Meta Application Protocol (JMAP)</title>
            <author fullname="N. Jenkins" initials="N." surname="Jenkins"/>
            <author fullname="C. Newman" initials="C." surname="Newman"/>
            <date month="July" year="2019"/>
            <abstract>
              <t indent="0">This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8620"/>
          <seriesInfo name="DOI" value="10.17487/RFC8620"/>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC7888" target="https://www.rfc-editor.org/info/rfc7888" quoteTitle="true" derivedAnchor="RFC7888">
          <front>
            <title>IMAP4 Non-synchronizing Literals</title>
            <author fullname="A. Melnikov" initials="A." role="editor" surname="Melnikov"/>
            <date month="May" year="2016"/>
            <abstract>
              <t indent="0">The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip.</t>
              <t indent="0">This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.</t>
              <t indent="0">This document obsoletes RFC 2088.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7888"/>
          <seriesInfo name="DOI" value="10.17487/RFC7888"/>
        </reference>
        <reference anchor="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 fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <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>
        <reference anchor="RFC8621" target="https://www.rfc-editor.org/info/rfc8621" quoteTitle="true" derivedAnchor="RFC8621">
          <front>
            <title>The JSON Meta Application Protocol (JMAP) for Mail</title>
            <author fullname="N. Jenkins" initials="N." surname="Jenkins"/>
            <author fullname="C. Newman" initials="C." surname="Newman"/>
            <date month="August" year="2019"/>
            <abstract>
              <t indent="0">This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP). Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8621"/>
          <seriesInfo name="DOI" value="10.17487/RFC8621"/>
        </reference>
        <reference anchor="RFC9007" target="https://www.rfc-editor.org/info/rfc9007" quoteTitle="true" derivedAnchor="RFC9007">
          <front>
            <title>Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP)</title>
            <author fullname="R. Ouazana" initials="R." role="editor" surname="Ouazana"/>
            <date month="March" year="2021"/>
            <abstract>
              <t indent="0">This document specifies a data model for handling Message Disposition Notifications (MDNs) (see RFC 8098) in the JSON Meta Application Protocol (JMAP) (see RFCs 8620 and 8621).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9007"/>
          <seriesInfo name="DOI" value="10.17487/RFC9007"/>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1"><contact fullname="Joris Baum"/>, <contact fullname="Jim Fenton"/>, <contact fullname="Neil Jenkins"/>, <contact fullname="Alexey Melnikov"/>, <contact fullname="Ken Murchison"/>, <contact fullname="Robert Stepanek"/>, and
the JMAP Working Group in the IETF.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author role="editor" initials="B." surname="Gondwana" fullname="Bron Gondwana">
        <organization showOnFrontPage="true">Fastmail</organization>
        <address>
          <postal>
            <street>Level 2, 114 William St</street>
            <city>Melbourne</city>
            <region>VIC</region>
            <code>3000</code>
            <country>Australia</country>
          </postal>
          <email>brong@fastmailteam.com</email>
          <uri>https://www.fastmail.com</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
