<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="std" docName="draft-gondwana-jmap-imapdata-00">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="JMAP IMAPData">JMAP Extension for imap data</title>

<author role="editor" initials="B." surname="Gondwana" fullname="Bron Gondwana">
<organization>FastMail</organization>
<address>
<postal>
<street>Level 2, 114 William St</street>
<city>Melbourne</city>
<code>VIC 3000</code>
<country>Australia</country>
<region></region>
</postal>
<phone></phone>
<email>brong@fastmailteam.com</email>
<uri>https://www.fastmail.com</uri>
</address>
</author>
<date year="2018" month="March" day="19"/>

<area>Applications</area>
<workgroup>JMAP</workgroup>
<keyword>IMAP</keyword>
<keyword>JMAP</keyword>
<keyword>email</keyword>


<abstract>
<t>This document adds additional properties to the JMAP Email and
Mailbox objects so that servers which also support IMAP can
expose metadata about the IMAP Mailstore via JMAP.
</t>
</abstract>


</front>

<middle>

<section anchor="introduction" title="Introduction">
<t><xref target="I-D.ietf-jmap-mail"/> JMAP datastores may be built in such a way that
they also allow <xref target="RFC3501"/> IMAP access to the underlying data.
</t>
<t>IMAP mailboxes have some STATUS data which is not required for JMAP
and hence not exposed by default.  This document provides a way to
access those values via JMAP.
</t>
<t>IMAP mailboxes contain individual messages by UID, and those can
have properties which specific to the individual message.  If the
server supports multiple IMAP messages collapsed into a single JMAP
message (due to identical Email/id or <xref target="I-D.gondwana-imap-uniqueid"/> MSGID)
then it can be useful to expose the underlying IMAP data via JMAP.
</t>
</section>

<section anchor="conventions-used-in-this-document" title="Conventions Used In This Document">
<t>In examples, &quot;C:&quot; indicates data sent by a client that is connected
to a server. &quot;S:&quot; indicates data sent by the server to the client.
</t>
<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;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted as
described in <xref target="RFC2119"/> when they appear in ALL CAPS.  These words may
also appear in this document in lower case as plain English words,
absent their normative meanings.
</t>
</section>

<section anchor="email-object-properties" title="Email Object properties">
<t>This extension adds a single property to the Email object:
</t>
<t>
<list style="symbols">
<t><spanx style="strong">imapdata</spanx>: String[Interger[ImapData]]
This is a map of mailbox id to a map of uid to ImapData Object</t>
</list>
</t>

<section anchor="imapdata-object" title="ImapData Object">
<t>The ImapData Object has the following properties:
</t>
<t>
<list style="symbols">
<t><spanx style="strong">internaldate</spanx>: Date
This is the date at which the message was created.  This
may be the same as the JMAP createdAt value, or different if
the underlying store has different internaldates for different
messages.</t>
<t><spanx style="strong">keywords</spanx>: String[Boolean]
This is identical to the &quot;keywords&quot; fetch item at the top level,
but contains the set of keywords on each individual IMAP message.
This may be the same for all messages, depending on the underlying
storage mechanics.</t>
<t><spanx style="strong">modseq</spanx>: Integer|null
This is the modseq of the individual message within the IMAP store,
or null if the server doesn't support <xref target="RFC7162"/>.</t>
<t><spanx style="strong">savedate</spanx>: Date|null
This is the date at which the message was added to this mailbox,
or null if the server doesn't support <xref target="I-D.ietf-extra-imap-savedate"/>.</t>
</list>
</t>
</section>
</section>

<section anchor="mailbox-object-properties" title="Mailbox Object properties">
<t>This extension adds a single property to the Mailbox object:
</t>
<t>
<list style="symbols">
<t><spanx style="strong">imapstatus</spanx>: ImapStatus|null</t>
</list>
</t>
<t>If the mailbox is not accessible via IMAP (e.g. a virtual mailbox)
then it MUST have a null ImapStatus.
</t>

<section anchor="imapstatus-object" title="ImapStatus Object">
<t>The ImapStatus Object has the following properties:
</t>
<t>
<list style="symbols">
<t><spanx style="strong">imapname</spanx>: String
The name of the mailbox in modified UTF7.  &quot;SELECT {imapname}&quot;
via IMAP would work if given this name.</t>
<t><spanx style="strong">highestmodseq</spanx>: Integer|null
The HIGHESTMODSEQ of the mailbox, or null if the mailbox does not
support <xref target="RFC7162"/>.</t>
<t><spanx style="strong">messages</spanx>: Integer
The MESSAGES status item (number of messages in mailbox) as defined
in <xref target="RFC3501"/> for the underlying mailbox.</t>
<t><spanx style="strong">uidvalidity</spanx>: Integer
The UIDVALIDITY as defined in <xref target="RFC3501"/> for the underlying mailbox.</t>
<t><spanx style="strong">uidnext</spanx>: Integer
The UIDNEXT as defined in <xref target="RFC3501"/> for the underlying mailbox.</t>
</list>
</t>
</section>
</section>

<section anchor="implementation-considerations" title="Implementation considerations">
<t>If the same message occurs multiple times in an IMAP store with different
keywords, the combined keyword contents might be best calculated in different
ways for different keywords, for example:
</t>
<t>
<list style="symbols">
<t>$flagged should be set if any IMAP record has $flagged set</t>
<t>$seen should only be set if ALL messages have $seen set (because
users are generally actually interested in &quot;unseen&quot;)</t>
</list>
</t>
</section>

<section anchor="iana-considerations" title="IANA Considerations">
<t>There will be a registration of an ID, but there's not yet a JMAP
registry to add the it into.  Maybe something like &quot;ietf:jmap:imapdata&quot;.
</t>
</section>

<section anchor="security-considerations" title="Security Considerations">
<t>All this data is visible via IMAP already for users with the same
authentication rights, however implementations must ensure that if
a message is both in mailboxes where the user has the <xref target="RFC4314"/>
READ ACL and other mailboxes where the use does not have read access,
that the imapdata response is filtered to avoid leaking information
about non-visible mailboxes.
</t>
</section>

<section anchor="acknowledgments" title="Acknowledgments">
<t>TBD.
</t>
</section>

</middle>
<back>
<references title="Normative References">
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.gondwana-imap-uniqueid.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-extra-imap-savedate.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-jmap-mail.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3501.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4314.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7162.xml"?>
</references>

</back>
</rfc>
