<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-baum-jmap-backend-info-00" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true" consensus="true">

<front>
<title abbrev="JMAP Backend Info">JMAP Backend Information</title><seriesInfo value="draft-baum-jmap-backend-info-00" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>
<author role="editor" initials="J.M." surname="Baum" fullname="Joris Baum"><organization>audriga</organization><address><postal><street>Alter Schlachthof 57</street>
<city>Karlsruhe </city>
<code>76137</code>
<country>Germany</country>
</postal><email>joris@audriga.com</email>
<uri>https://www.audriga.com</uri>
</address></author><author role="editor" initials="H.J." surname="Happel" fullname="Hans-Joerg"><organization>audriga</organization><address><postal><street>Alter Schlachthof 57</street>
<city>Karlsruhe </city>
<code>76137</code>
<country>Germany</country>
</postal><email>hans-joerg@audriga.com</email>
<uri>https://www.audriga.com</uri>
</address></author><date year="2023" month="April" day="6"></date>
<area>Applications</area>
<workgroup>JMAP</workgroup>
<keyword>jmap</keyword>
<keyword>metadata</keyword>

<abstract>
<t>It is likely that any JMAP implementation has either bugs or intentionally deviates from the standard. To cope with such a unique behavior, JMAP clients need to identify the software behind the JMAP endpoint and apply custom logic. This specification defines the ability to provide details about the product, backend and environment for JMAP servers.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>Every server-side software has its own quirks. For example, the JMAP standard
might only have been partially implemented by a server or design decisions might
have been taken that let the server deviate from what is actually required by
<xref target="RFC8620"></xref>. Servers might also have unintended bugs or have certain
restrictions that are not sufficiently reflected by their list of supported
server capabilities.</t>
<t>Such behavior typically occurs for edge-cases. Nonetheless, interoperable clients that aim to have a successful structured data
exchange with such &quot;unique&quot; servers need to handle these quirks with workarounds
on the client-side. Clients only want to apply special workarounds in
situations where they are truly necessary. This is typically done by identifying
which server-side software they are communicating with.</t>
<t>JMAP does not provide a standardized way to retrieve an identifier of the
product that is residing on the server side. Due to the lack of standardization
clients are left to identify misbehaving servers by error-prone means. Examples
are checking against a list of known URLs or checking known unique responses,
typically only sent by certain products. This makes identifying products
time-consuming and brittle.</t>
<t>Related functionality in other standards are the PRODID property in iCalendar <xref target="RFC5545"></xref> and vCard <xref target="RFC6350"></xref>, which allows
identifying the product that produced the files. ManageSieve <xref target="RFC5804"></xref> and JMAP Sieve <xref target="I-D.ietf-jmap-sieve"></xref> define an implementation property, which allows identifying the Sieve implementation.</t>

<section anchor="conventions-used-in-this-document"><name>Conventions Used In This Document</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL
NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;,
&quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and only when,
they appear in all capitals, as shown here.</t>
<t>The definitions of JSON keys and datatypes in the document follow
the conventions described in the core JMAP specification <xref target="RFC8620"></xref>.</t>
</section>

<section anchor="addition-to-the-capabilities-object"><name>Addition to the capabilities object</name>
<t>The capabilities object is returned as part of the JMAP Session object;
see <xref target="RFC8620"></xref>, Section 2. This document defines one additional capability URI.</t>

<section anchor="urn-ietf-params-jmap-core-backendinfo"><name>urn:ietf:params:jmap:core:backendinfo</name>
<t>This extension defines
one additional <tt>urn:ietf:params:jmap:core:backendinfo</tt> server capability that provides
details about the product, backend and environment.</t>
<t>The value of this property in the JMAP Session capabilities property is an object that MUST contain the following information on server capabilities:</t>

<ul spacing="compact">
<li><strong>apiBackend</strong>: <tt>SoftwareInfo|null</tt> Information on the JMAP API backend component.</li>
<li><strong>product</strong>: <tt>SoftwareInfo|null</tt> Information on the overall application or product.</li>
<li><strong>environment</strong>: <tt>String|null</tt> Information on the environment the software is running in.</li>
</ul>
<t>A SoftwareInfo object has the following properties:</t>

<ul spacing="compact">
<li><strong>name</strong>: <tt>String</tt> The JMAP API backend software.</li>
<li><strong>version</strong>: <tt>String|null</tt> The software version.</li>
</ul>
<t>This extension does not add anything to the account's accountCapabilities property.</t>
<t>Here is an example JSON snippet:</t>

<sourcecode type="json">{
  &quot;capabilities&quot;: {
    &quot;urn:ietf:params:jmap:core:backendinfo&quot;: {
      &quot;apiBackend&quot;: {
        &quot;name&quot;: &quot;OpenXPort/Horde&quot;,
        &quot;version&quot;: &quot;1.0.0&quot;
      },
      &quot;product&quot;: {
        &quot;name&quot;: &quot;Horde Webmailer&quot;,
        &quot;version&quot;: &quot;1.0.0&quot;
      },
      &quot;environment&quot;: {
        &quot;name&quot;: &quot;PHP&quot;,
        &quot;version&quot;: &quot;5.5&quot;
      }
    }
  },
    ...
}
</sourcecode>
</section>
</section>
</section>

<section anchor="security"><name>Security considerations</name>
<t>All security considerations of JMAP <xref target="RFC8620"></xref> apply to this specification.</t>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="jmap-capability-registration-for-backendinfo"><name>JMAP Capability Registration for &quot;backendinfo&quot;</name>
<t>IANA will register the &quot;backendinfo&quot; JMAP Capability as follows:</t>
<t>Capability Name: &quot;urn:ietf:params:jmap:backendinfo&quot;</t>
<t>Specification document: this document</t>
<t>Intended use: common</t>
<t>Change Controller: IETF</t>
<t>Security and privacy considerations: this document, <xref target="security"></xref>.</t>
</section>
</section>

<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>Bron Gondwana, Neil Jenkins, Alexey Melnikov, Ken Murchison, Robert Stepanek and
the JMAP working group at the IETF.</t>
</section>

</middle>

<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-jmap-sieve.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5545.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5804.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8620.xml"/>
</references>

</back>

</rfc>
