idnits 2.17.1 draft-ietf-extra-imap-status-size-02.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 (May 29, 2018) is 2159 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: 'UNSEEN 7' is mentioned on line 133, but not defined == Missing Reference: 'UIDVALIDITY 1364851417' is mentioned on line 134, but not defined == Missing Reference: 'UIDNEXT 242344' is mentioned on line 135, but not defined == Missing Reference: 'HIGHESTMODSEQ 3914' is mentioned on line 136, but not defined ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4rev1') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2087 (ref. 'QUOTA') (Obsoleted by RFC 9208) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 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 May 29, 2018 5 Expires: November 30, 2018 7 Internet Message Access Protocol (IMAP) - STATUS=SIZE Extension 8 draft-ietf-extra-imap-status-size-02 10 Abstract 12 This document adds a new capability called "STATUS=SIZE" to the 13 Internet Message Access Protocol (IMAP). It allows retrieving the 14 total storage size of a mailbox with a single STATUS command rather 15 than retrieving and summing the sizes of all individual messages in 16 that mailbox. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 30, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 54 3. STATUS Command and Response Extensions . . . . . . . . . . . 3 55 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 This document extends Internet Message Access Protocol (IMAP) 65 [IMAP4rev1] with a new capability called "STATUS=SIZE". To determine 66 the total storage size of a mailbox, an IMAP client currently needs 67 to retrieve all message sizes individually using the FETCH command 68 with the RFC822.SIZE data item. The "STATUS=SIZE" capability 69 provides a more efficient means to achieve this. It extends the 70 STATUS command with a new "SIZE" data item, which indicates the total 71 size of all messages in the target mailbox. This way, this 72 information can be queried with just one STATUS command. When the 73 "LIST-STATUS" IMAP capability [LIST-STATUS] is also available, the 74 SIZE data item can be queried for many mailboxes at once using just 75 one LIST command. 77 This capability is particularly useful for IMAP clients that do not 78 cache the state of the message store, such as most webmail clients. 79 Without the "STATUS=SIZE" capability, such clients need to fetch all 80 message sizes from the server when the size of an individual mailbox 81 needs to be determined. For example, a user may request detailed 82 quota usage information for each mailbox to find out which specific 83 mailboxes consume most of the available storage resources. Using 84 this information, the user can get an overview of which mailboxes 85 need to be cleaned up to reduce quota usage. The "QUOTA" capability 86 [QUOTA] is no help in that scenario, since the provided QUOTAROOT 87 command can only yield the "STORAGE" resource usage of a whole quota 88 root, but not for each individual mailbox within that root. 90 2. Conventions Used in This Document 92 In examples, "C:" indicates lines sent by a client that is connected 93 to a server. "S:" indicates lines sent by the server to the client. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [KEYWORDS]. 99 3. STATUS Command and Response Extensions 101 This extension defines one new status data item for the STATUS 102 command and response: 104 SIZE 105 The total size of the mailbox in octets. This is not strictly 106 required to be an exact value, but it MUST be equal to or greater 107 than the sum of the values of the RFC822.SIZE FETCH message data 108 item [IMAP4rev1] of all messages in the mailbox. When the "QUOTA" 109 capability [QUOTA] is also supported, this value SHOULD be equal 110 to the storage usage value used to enforce the "STORAGE" resource 111 limit for this mailbox. This way, the client can directly infer 112 the quota usage. 114 Since the total storage size of a mailbox can easily exceed 4 GB, 115 clients MUST be capable of receiving 63-bit SIZE data item values. 116 The message size is chosen to be at most 63 bits wide rather than 64 117 bits to make implementations on various platforms (such as Java) 118 easier. 120 Example: 122 C: A01 STATUS frop (MESSAGES SIZE UIDNEXT) 123 S: * STATUS frop (MESSAGES 8 SIZE 44421 UIDNEXT 242344) 124 S: A01 OK STATUS completed 126 The same information can be obtained by using the following commands, 127 albeit less efficient: 129 C: A02 SELECT "frop" 130 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 131 S: * 8 EXISTS 132 S: * 1 RECENT 133 S: * OK [UNSEEN 7] First unseen. 134 S: * OK [UIDVALIDITY 1364851417] UIDs valid 135 S: * OK [UIDNEXT 242344] Predicted next UID 136 S: * OK [HIGHESTMODSEQ 3914] Highest 137 S: A02 OK [READ-WRITE] Select completed. 138 C: A03 FETCH 1:* (RFC822.SIZE) 139 S: * 1 FETCH (RFC822.SIZE 3224) 140 S: * 2 FETCH (RFC822.SIZE 1222) 141 S: * 3 FETCH (RFC822.SIZE 444) 142 S: * 4 FETCH (RFC822.SIZE 4516) 143 S: * 5 FETCH (RFC822.SIZE 544) 144 S: * 6 FETCH (RFC822.SIZE 922) 145 S: * 7 FETCH (RFC822.SIZE 31126) 146 S: * 8 FETCH (RFC822.SIZE 2423) 147 S: A03 OK Fetch completed. 149 When the LIST-STATUS IMAP capability [LIST-STATUS] is also available, 150 the STATUS command can be combined with the LIST command to further 151 improve efficiency. This way, the sizes of many mailboxes can be 152 queried with just one LIST command. 154 Example: 156 C: A04 LIST "" % RETURN (STATUS (MESSAGES SIZE)) 157 S: * LIST () "." "INBOX" 158 S: * STATUS "INBOX" (MESSAGES 17 SIZE 16234) 159 S: * LIST () "." "frop" 160 S: * STATUS "frop" (MESSAGES 8 SIZE 44421) 161 S: A04 OK List completed. 163 4. Formal Syntax 165 The following syntax specification augments the grammar specified in 166 [IMAP4rev1] and [IMAP4-ABNF]. It uses the Augmented Backus-Naur Form 167 (ABNF) notation as specified in [ABNF]. Elements not defined here 168 are taken from [IMAP4rev1] and [IMAP4-ABNF]. 170 capability =/ "STATUS=SIZE" 172 status-att =/ "SIZE" 174 status-att-val =/ "SIZE" SP number64 176 number64 = 1*DIGIT 177 ; Unsigned 63-bit integer 178 ; (0 <= n <= 9,223,372,036,854,775,807) 180 5. Security Considerations 182 There are no known additional security issues with this extension 183 beyond those described for the base protocol [IMAP4rev1] and for the 184 LIST-STATUS extension [LIST-STATUS]. 186 6. IANA Considerations 188 The IANA is requested to add "STATUS=SIZE" to the "IMAP Capabilities" 189 registry located at . 192 7. Acknowledgements 194 Thanks to Bron Gondwana, Alexey Melnikov, Stan Kalisch, and Michael 195 Slusarz for reviews and suggestions. 197 8. Normative References 199 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 200 Specifications: ABNF", STD 68, RFC 5234, January 2008. 202 [IMAP4-ABNF] 203 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 204 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, 205 . 207 [IMAP4rev1] 208 Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 209 4rev1", RFC 3501, March 2003. 211 [KEYWORDS] 212 Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, March 1997. 215 [LIST-STATUS] 216 Melnikov, A. and T. Sirainen, "IMAP4 Extension for 217 Returning STATUS Information in Extended LIST", RFC 5819, 218 March 2010. 220 [QUOTA] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 221 1997. 223 Author's Address 225 Stephan Bosch 226 Dovecot Oy 227 Lars Sonckin Kaari 12 228 Espoo 02600 229 Finland 231 Email: stephan.bosch@dovecot.fi