idnits 2.17.1 draft-gondwana-jmap-imapdata-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 19, 2018) is 2231 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Boolean' is mentioned on line 105, but not defined == Outdated reference: A later version (-01) exists of draft-gondwana-imap-uniqueid-00 == Outdated reference: A later version (-01) exists of draft-ietf-extra-imap-savedate-00 == Outdated reference: A later version (-16) exists of draft-ietf-jmap-mail-04 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JMAP B. Gondwana, Ed. 3 Internet-Draft FastMail 4 Intended status: Standards Track March 19, 2018 5 Expires: September 20, 2018 7 JMAP Extension for imap data 8 draft-gondwana-jmap-imapdata-00 10 Abstract 12 This document adds additional properties to the JMAP Email and 13 Mailbox objects so that servers which also support IMAP can expose 14 metadata about the IMAP Mailstore via JMAP. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 20, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions Used In This Document . . . . . . . . . . . . . . 2 52 3. Email Object properties . . . . . . . . . . . . . . . . . . . 2 53 3.1. ImapData Object . . . . . . . . . . . . . . . . . . . . . 3 54 4. Mailbox Object properties . . . . . . . . . . . . . . . . . . 3 55 4.1. ImapStatus Object . . . . . . . . . . . . . . . . . . . . 3 56 5. Implementation considerations . . . . . . . . . . . . . . . . 4 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 60 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 [I-D.ietf-jmap-mail] JMAP datastores may be built in such a way that 66 they also allow [RFC3501] IMAP access to the underlying data. 68 IMAP mailboxes have some STATUS data which is not required for JMAP 69 and hence not exposed by default. This document provides a way to 70 access those values via JMAP. 72 IMAP mailboxes contain individual messages by UID, and those can have 73 properties which specific to the individual message. If the server 74 supports multiple IMAP messages collapsed into a single JMAP message 75 (due to identical Email/id or [I-D.gondwana-imap-uniqueid] MSGID) 76 then it can be useful to expose the underlying IMAP data via JMAP. 78 2. Conventions Used In This Document 80 In examples, "C:" indicates data sent by a client that is connected 81 to a server. "S:" indicates data sent by the server to the client. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119] when they 86 appear in ALL CAPS. These words may also appear in this document in 87 lower case as plain English words, absent their normative meanings. 89 3. Email Object properties 91 This extension adds a single property to the Email object: 93 o *imapdata*: String[Interger[ImapData]] This is a map of mailbox id 94 to a map of uid to ImapData Object 96 3.1. ImapData Object 98 The ImapData Object has the following properties: 100 o *internaldate*: Date This is the date at which the message was 101 created. This may be the same as the JMAP createdAt value, or 102 different if the underlying store has different internaldates for 103 different messages. 105 o *keywords*: String[Boolean] This is identical to the "keywords" 106 fetch item at the top level, but contains the set of keywords on 107 each individual IMAP message. This may be the same for all 108 messages, depending on the underlying storage mechanics. 110 o *modseq*: Integer|null This is the modseq of the individual 111 message within the IMAP store, or null if the server doesn't 112 support [RFC7162]. 114 o *savedate*: Date|null This is the date at which the message was 115 added to this mailbox, or null if the server doesn't support 116 [I-D.ietf-extra-imap-savedate]. 118 4. Mailbox Object properties 120 This extension adds a single property to the Mailbox object: 122 o *imapstatus*: ImapStatus|null 124 If the mailbox is not accessible via IMAP (e.g. a virtual mailbox) 125 then it MUST have a null ImapStatus. 127 4.1. ImapStatus Object 129 The ImapStatus Object has the following properties: 131 o *imapname*: String The name of the mailbox in modified UTF7. 132 "SELECT {imapname}" via IMAP would work if given this name. 134 o *highestmodseq*: Integer|null The HIGHESTMODSEQ of the mailbox, or 135 null if the mailbox does not support [RFC7162]. 137 o *messages*: Integer The MESSAGES status item (number of messages 138 in mailbox) as defined in [RFC3501] for the underlying mailbox. 140 o *uidvalidity*: Integer The UIDVALIDITY as defined in [RFC3501] for 141 the underlying mailbox. 143 o *uidnext*: Integer The UIDNEXT as defined in [RFC3501] for the 144 underlying mailbox. 146 5. Implementation considerations 148 If the same message occurs multiple times in an IMAP store with 149 different keywords, the combined keyword contents might be best 150 calculated in different ways for different keywords, for example: 152 o $flagged should be set if any IMAP record has $flagged set 154 o $seen should only be set if ALL messages have $seen set (because 155 users are generally actually interested in "unseen") 157 6. IANA Considerations 159 There will be a registration of an ID, but there's not yet a JMAP 160 registry to add the it into. Maybe something like 161 "ietf:jmap:imapdata". 163 7. Security Considerations 165 All this data is visible via IMAP already for users with the same 166 authentication rights, however implementations must ensure that if a 167 message is both in mailboxes where the user has the [RFC4314] READ 168 ACL and other mailboxes where the use does not have read access, that 169 the imapdata response is filtered to avoid leaking information about 170 non-visible mailboxes. 172 8. Acknowledgments 174 TBD. 176 9. Normative References 178 [I-D.gondwana-imap-uniqueid] 179 Gondwana, B., "IMAP Extension for unique identifiers", 180 draft-gondwana-imap-uniqueid-00 (work in progress), March 181 2018. 183 [I-D.ietf-extra-imap-savedate] 184 Bosch, S., "Internet Message Access Protocol (IMAP) - 185 SAVEDATE Extension", draft-ietf-extra-imap-savedate-00 186 (work in progress), March 2018. 188 [I-D.ietf-jmap-mail] 189 Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-04 190 (work in progress), March 2018. 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 198 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 199 . 201 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 202 RFC 4314, DOI 10.17487/RFC4314, December 2005, 203 . 205 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag 206 Changes Resynchronization (CONDSTORE) and Quick Mailbox 207 Resynchronization (QRESYNC)", RFC 7162, 208 DOI 10.17487/RFC7162, May 2014, 209 . 211 Author's Address 213 Bron Gondwana (editor) 214 FastMail 215 Level 2, 114 William St 216 Melbourne VIC 3000 217 Australia 219 Email: brong@fastmailteam.com 220 URI: https://www.fastmail.com