idnits 2.17.1 draft-bosch-imap-savedate-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 (September 15, 2017) is 2414 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) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4rev1') (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bosch 3 Internet-Draft Dovecot Oy 4 Intended status: Standards Track September 15, 2017 5 Expires: March 19, 2018 7 Internet Message Access Protocol (IMAP) - SAVEDATE Extension 8 draft-bosch-imap-savedate-00 10 Abstract 12 This document adds a new capability called "SAVEDATE" to the Internet 13 Message Access Protocol (IMAP). It defines a new IMAP message 14 attribute called 'save date' that, unlike the existing 'internal 15 date' attribute, always indicates the moment at which the message was 16 saved in its current mailbox. The SAVEDATE capability extends the 17 FETCH command with the means to retrieve the save date attribute and 18 it extends the SEARCH command to allow using that attribute in 19 searching criteria. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 19, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 57 3. Save Date Message Attribute . . . . . . . . . . . . . . . . . 3 58 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 4 59 4.1. CAPABILITY Identification . . . . . . . . . . . . . . . . 4 60 4.2. FETCH Command and Response Extensions . . . . . . . . . . 4 61 4.3. SEARCH Command Extension . . . . . . . . . . . . . . . . 4 62 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 This document extends Internet Message Access Protocol (IMAP) 72 [IMAP4rev1] with a new capability called "SAVEDATE". This capability 73 adds a new IMAP message attribute called 'save date'. The save date 74 is the date and time at which a message was saved in the mailbox it 75 currently resides. The save date is similar to the existing internal 76 date attribute in that it is set at the time of delivery. However, 77 the internal date attribute can be set to an arbitrary value for 78 messages delivered to the mailbox using the APPEND command and it is 79 usually copied from the source message for messages delivered using 80 the COPY command. In contrast, the save date attribute is always set 81 to the current date and time at the moment the message is saved in 82 the mailbox, irrespective of how the message is delivered and from 83 where it originates. 85 The save date message attribute is useful for implementing automated 86 removal of messages from a mailbox after a configured amount of time. 87 For that application, it is necessary to know when the message was 88 saved in the mailbox, which cannot be reliably determined using the 89 the internal date attribute. 91 For example, a common client usage pattern is to move deleted 92 messages to a Trash mailbox [FIXME: reference to SPECIAL-USE RFC for 93 discussion on semantics of a "trash" mailbox (?)]; these messages are 94 considered "deleted" at the time they are moved to the Trash mailbox. 95 In an effort to limit the size of the Trash mailbox, a client may 96 subsequently desire to permanently remove (expunge) all messages in 97 that Trash mailbox deleted before a certain time (e.g. a configurable 98 expiration interval). In that case, the internal date attribute 99 cannot be used, since it likely refers to the time at which the 100 message was originally received. The proper time comparison 101 attribute should instead be the time at which the message was saved 102 to the Trash mailbox. Similar usage patterns can be observed for 103 Archiving solutions. 105 The SAVEDATE capability extends the FETCH command and response to 106 allow retrieving the date and time at which a message was saved. 107 Also, the SAVEDATE capability extends the SEARCH command to allow 108 searching messages with criteria based on when it was saved in the 109 mailbox. 111 2. Conventions Used in This Document 113 In examples, "C:" indicates lines sent by a client that is connected 114 to a server. "S:" indicates lines sent by the server to the client. 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [KEYWORDS]. 120 3. Save Date Message Attribute 122 The save date message attribute is the date and time at which the 123 message was saved in the mailbox it is now located in. Unlike the 124 internal date attribute defined by [IMAP4rev1], this date and time 125 value cannot be set arbitrarily when a message is delivered by the 126 IMAP APPEND command. Also, when a message is delivered by the IMAP 127 COPY command, the save date attribute is not copied from the source 128 message. Instead, the current date and time the message is delivered 129 to a mailbox MUST be used to set the save date attribute. Once 130 calculated, the save date attribute MUST NOT change as long as the 131 message is contained within the mailbox. 133 For some mailboxes the underlying storage may not support the save 134 date message attribute. In such situations, the behavior is 135 implementation-defined. Using the internal date attribute instead is 136 RECOMMENDED. [FIXME: This is what Dovecot currently does, but for a 137 standard this is inappropriate. It should probably indicate the lack 138 of support with a particular NO response code, or it could just 139 return NULL or some other special value]. 141 4. IMAP Protocol Changes 143 4.1. CAPABILITY Identification 145 IMAP servers that support this extension MUST include "SAVEDATE" in 146 the response list to the CAPABILITY command. 148 4.2. FETCH Command and Response Extensions 150 This extension defines one new data item for the FETCH command: 152 SAVEDATE 153 The save date of the message. 155 This extension defines one new data item for the FETCH response: 157 SAVEDATE 158 A string representing the save date of the message. 160 Example: 162 C: A101 FETCH 998 (SAVEDATE) 163 S: * 998 FETCH (SAVEDATE "01-Jan-2015 18:50:53 +0100") 164 S: A101 OK Fetch completed. 166 4.3. SEARCH Command Extension 168 This extension defines three new search keys for the SEARCH command: 170 SAVEDBEFORE 171 Messages whose save date (disregarding time and timezone) is 172 earlier than the specified date. 174 SAVEDON 175 Messages whose save date (disregarding time and timezone) is 176 within the specified date. 178 SAVEDSINCE 179 Messages whose save date (disregarding time and timezone) is 180 within or later than the specified date. 182 Example: 184 C: A102 SEARCH SAVEDON 28-Dec-2014 185 S: * SEARCH 993 994 186 S: A102 OK Search completed. 187 C: A103 SEARCH SAVEDSINCE 28-Dec-2014 188 S: * SEARCH 993 994 995 996 997 998 999 1000 1001 189 S: A103 OK Search completed. 191 5. Formal Syntax 193 The following syntax specification augments the grammar specified in 194 [IMAP4rev1]. It uses the Augmented Backus-Naur Form (ABNF) notation 195 as specified in [ABNF]. Elements not defined here are taken from 196 [IMAP4rev1]. 198 capability =/ "SAVEDATE" 200 fetch-att =/ "SAVEDATE" 201 msg-att-static =/ "SAVEDATE" SP date-time 203 search-key =/ "SAVEDBEFORE" SP date / 204 "SAVEDON" SP date / 205 "SAVEDSINCE" SP date 207 6. Security Considerations 209 There are no known additional security issues with this extension 210 beyond those described in the base protocol described in [IMAP4rev1]. 212 7. IANA Considerations 214 The IANA is requested to add "SAVEDATE" to the "IMAP Capabilities" 215 registry located at . 218 8. Acknowledgements 220 Thanks to Alexey Melnikov and Michael Slusarz for reviews and 221 suggestions. 223 More reviews are appreciated. 225 9. Normative References 227 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 228 Specifications: ABNF", STD 68, RFC 5234, January 2008. 230 [IMAP4rev1] 231 Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 232 4rev1", RFC 3501, March 2003. 234 [KEYWORDS] 235 Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 Author's Address 240 Stephan Bosch 241 Dovecot Oy 242 Lars Sonckin Kaari 10 243 Espoo 02600 244 Finland 246 Email: stephan.bosch@dovecot.fi