idnits 2.17.1 draft-ietf-extra-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 (January 7, 2018) is 2295 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 EXTRA S. Bosch 3 Internet-Draft Dovecot Oy 4 Intended status: Standards Track January 7, 2018 5 Expires: July 11, 2018 7 Internet Message Access Protocol (IMAP) - SAVEDATE Extension 8 draft-ietf-extra-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 July 11, 2018. 38 Copyright Notice 40 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . 6 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; these messages are considered "deleted" 93 at the time they are moved to the Trash mailbox. In an effort to 94 limit the size of the Trash mailbox, a client may subsequently desire 95 to permanently remove (expunge) all messages in that Trash mailbox 96 deleted before a certain time (e.g. a configurable expiration 97 interval). In that case, the internal date attribute cannot be used, 98 since it likely refers to the time at which the message was 99 originally received. The proper time comparison attribute should 100 instead be the time at which the message was saved to the Trash 101 mailbox. Similar usage patterns can be observed for Archiving 102 solutions. 104 The SAVEDATE capability extends the FETCH command and response to 105 allow retrieving the date and time at which a message was saved. 106 Also, the SAVEDATE capability extends the SEARCH command to allow 107 searching messages with criteria based on when it was saved in the 108 mailbox. 110 2. Conventions Used in This Document 112 In examples, "C:" indicates lines sent by a client that is connected 113 to a server. "S:" indicates lines sent by the server to the client. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [KEYWORDS]. 119 3. Save Date Message Attribute 121 The save date message attribute is the date and time at which the 122 message was saved in the mailbox it is now located in. Unlike the 123 internal date attribute defined by [IMAP4rev1], this date and time 124 value cannot be set arbitrarily when a message is delivered by the 125 IMAP APPEND command. Also, when a message is delivered to the 126 mailbox by the IMAP COPY command [IMAP4rev1] or the IMAP MOVE command 127 [IMAP-MOVE], the save date attribute is not copied from the source 128 message. Instead, the current date and time at which the message is 129 delivered to a mailbox MUST be used to set the save date attribute. 130 Once calculated, the save date attribute MUST NOT change as long as 131 the message is contained within the same mailbox. 133 This means that when the message is copied to another mailbox, the 134 save date of the message in source mailbox remains unaffected; only 135 the new copy of the message gets a new save date. Consequently, when 136 the the message is moved to another mailbox, either using the MOVE 137 command or a command sequence involving the COPY command [IMAP-MOVE], 138 the message always gets a new save date in the destination mailbox. 140 For some specific mailboxes, the underlying storage may not support 141 the save date message attribute. The handling of this situation is 142 described in detail in the next section for each involved IMAP 143 command. 145 4. IMAP Protocol Changes 147 4.1. CAPABILITY Identification 149 IMAP servers that support this extension MUST include "SAVEDATE" in 150 the response list to the CAPABILITY command. 152 4.2. FETCH Command and Response Extensions 154 This extension defines one new data item for the FETCH command: 156 SAVEDATE 157 The save date of the message. 159 This extension defines one new data item for the FETCH response: 161 SAVEDATE 162 A string representing the save date of the message. However, if 163 the underlying mailbox storage does not support the save date 164 message attribute, the value returned for the SAVEDATE item is 165 always NIL, rather than a string. 167 Example: 169 C: A101 FETCH 998 (SAVEDATE) 170 S: * 998 FETCH (SAVEDATE "01-Jan-2015 18:50:53 +0100") 171 S: A101 OK Fetch completed. 173 4.3. SEARCH Command Extension 175 This extension defines three new search keys for the SEARCH command: 177 SAVEDBEFORE 178 Messages whose save date (disregarding time and timezone) is 179 earlier than the specified date. 181 SAVEDON 182 Messages whose save date (disregarding time and timezone) is 183 within the specified date. 185 SAVEDSINCE 186 Messages whose save date (disregarding time and timezone) is 187 within or later than the specified date. 189 These search keys cannot be used with a mailbox for which the 190 underlying storage does not support the save date message attribute. 191 If any of these search keys are used with the SEARCH command when the 192 selected mailbox has no support for the save date attribute, the 193 SEARCH command MUST return a tagged NO response. 195 Example: 197 C: A102 SEARCH SAVEDON 28-Dec-2014 198 S: * SEARCH 993 994 199 S: A102 OK Search completed. 200 C: A103 SEARCH SAVEDSINCE 28-Dec-2014 201 S: * SEARCH 993 994 995 996 997 998 999 1000 1001 202 S: A103 OK Search completed. 204 5. Formal Syntax 206 The following syntax specification augments the grammar specified in 207 [IMAP4rev1]. It uses the Augmented Backus-Naur Form (ABNF) notation 208 as specified in [ABNF]. Elements not defined here are taken from 209 [IMAP4rev1]. 211 capability =/ "SAVEDATE" 213 fetch-att =/ "SAVEDATE" 214 msg-att-static =/ "SAVEDATE" SP (date-time / nil) 216 search-key =/ "SAVEDBEFORE" SP date / 217 "SAVEDON" SP date / 218 "SAVEDSINCE" SP date 220 6. Security Considerations 222 There are no known additional security issues with this extension 223 beyond those described in the base protocol described in [IMAP4rev1]. 225 7. IANA Considerations 227 The IANA is requested to add "SAVEDATE" to the "IMAP Capabilities" 228 registry located at . 231 8. Acknowledgements 233 Thanks to Bron Gondwana, Alexey Melnikov, Timo Sirainen, and Michael 234 Slusarz for reviews and suggestions. 236 9. Normative References 238 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 239 Specifications: ABNF", STD 68, RFC 5234, January 2008. 241 [IMAP-MOVE] 242 Gulbrandsen, A. and N. Freed, "Internet Message Access 243 Protocol (IMAP) - MOVE Extension", RFC 6851, January 2013. 245 [IMAP4rev1] 246 Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 247 4rev1", RFC 3501, March 2003. 249 [KEYWORDS] 250 Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, March 1997. 253 Author's Address 255 Stephan Bosch 256 Dovecot Oy 257 Lars Sonckin Kaari 10 258 Espoo 02600 259 Finland 261 Email: stephan.bosch@dovecot.fi