idnits 2.17.1 draft-jayantheesh-imap-appendlimit-extension-04.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: By looking at the upload size restriction set by the IMAP server, client MUST not try to upload mail more than advertised limit in the APPEND command. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: A number indicating the fixed maximum message size in bytes that the server will accept. APPENDLIMIT=0 indicates the server SHALL not accept APPEND command due to size restriction. The syntax of the parameter follows the augmented BNF notation of [RFC5234]. If this capability is omitted, no information is conveyed about the server's fixed maximum mail upload size. -- The document date (February 27, 2015) is 3339 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: 'APPENDLIMIT 257890' is mentioned on line 156, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 126, but not defined == Missing Reference: 'RFC2087' is mentioned on line 292, but not defined ** Obsolete undefined reference: RFC 2087 (Obsoleted by RFC 9208) == Missing Reference: 'RFC7377' is mentioned on line 295, but not defined == Unused Reference: 'RFC2119' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'RFC2088' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'RFC4469' is defined on line 279, but no explicit reference was found in the text == Unused Reference: 'RFC5819' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'RFC5258' is defined on line 285, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2088 (Obsoleted by RFC 7888) Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jayantheesh S B 2 Intended status: Standards Track Samsung 3 Expires: August 2015 Narendra Singh Bisht 4 Samsung 5 February 27, 2015 7 The IMAP APPENDLIMIT Extension 8 draft-jayantheesh-imap-appendlimit-extension-04 10 Abstract 12 This memo defines an extension to the IMAP service whereby a server can 13 advertise its capability, to support maximum mail upload size using 14 CAPABILITY, SELECT/EXAMINE and LIST command. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may not be modified, and 20 derivative works of it may not be created, except to publish it as an 21 RFC and to translate it into languages other than English. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other groups 25 may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on August, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents carefully, 49 as they describe your rights and restrictions with respect to this 50 document. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 56 2. APPENDLIMIT Extension . . . . . . . . . . . . . . . . . . . . . 2 57 3. Mailbox specific APPENDLIMIT . . . . . . . . . . . . . . . . . . 3 58 3.1. SELECT response . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. LIST response . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. APPEND response . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1 Normative References . . . . . . . . . . . . . . . . . . . . . 6 66 8.2 Informative References . . . . . . . . . . . . . . . . . . . . 7 67 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 68 10. Author's Address . .. . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Several IMAP server have limitation for mail upload size which is not 73 published to the email client. When email client APPEND a mail with 74 huge attachments, it fails due to size restriction set by the IMAP 75 server. This results in unnecessary resource usage. Especially in the 76 mobile device environment, appending mail with huge attachment consumes 77 device resources like device battery power and mobile data. 79 The IMAP APPENDLIMIT extension provides an ability to advertise maximum 80 upload size allowed by the IMAP server, so that email client knows the 81 size limitation beforehand. 83 1.1. Conventions and Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 86 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 87 this document are to be interpreted as described in RFC 2119. 89 Example lines prefaced by "C:" are sent by the client and ones prefaced 90 by "S:" by the server. The five characters [...] means that something 91 has been elided. 93 2. APPENDLIMIT Extension 95 An IMAP server that supports APPENDLIMIT advertises this by including 96 the word APPENDLIMIT in its capability list. IMAP server shall publish 97 the supported mail upload size as part of CAPABILITY response. The 98 advertised upload limit is common across the mailboxes, but client 99 can still issue SELECT/EXAMINE or LIST command to get the mailbox 100 specific upload limit set by the IMAP server. In this case, 101 APPENDLIMIT value obtained as part of SELECT/EXAMINE or LIST command 102 takes precedence over the value returned as part of CAPABILITY 103 response. 105 The following example, demonstrates the APPENDLIMIT capability with 106 mailbox limit. 108 C: t1 CAPABILITY 109 S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890 110 S: t1 OK foo 112 If APPENDLIMIT value is omitted in CAPABILITY response, then client 113 SHOULD issue SELECT/EXAMINE or LIST command to get the mailbox specific 114 limit set by the server. New response code APPENDLIMIT is added to get 115 the mailbox specific limit. Refer section 5 for response code syntax. 117 The following example demonstrates, its usage. 119 C: t1 CAPABILITY 120 S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT 121 S: t1 OK foo 123 C: t2 SELECT INBOX 124 S: * 172 EXISTS 125 S: * OK [APPENDLIMIT 257890] Maximum upload limit 126 S: * OK [UIDVALIDITY 3857529045] UIDs valid 127 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 128 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 129 S: t2 OK [READ-WRITE] SELECT completed 131 By looking at the upload size restriction set by the IMAP server, client 132 MUST not try to upload mail more than advertised limit in the APPEND 133 command. 135 3. Mailbox specific APPENDLIMIT 137 IMAP server can still have mailbox specific APPENDLIMIT restriction, 138 which may not be advertised as part of CAPABILITY response. In this 139 case, client can issue SELECT/EXAMINE command to get the per mailbox 140 specific limit set by the server. Similarly, if client wish to know 141 the mailbox specific limit in authenticated state, can be done by 142 issuing the LIST command in combination with STATUS command. 144 3.1 SELECT response 146 Client can get the per mailbox append limit by issuing the SELECT/ 147 EXAMINE command. APPENDLIMIT size to this mailbox is obtained as part 148 of untagged OK response. In this case, this APPENDLIMIT value will 149 supersede the value received as part of CAPABILITY response. If no 150 per-mailbox APPENDLIMIT is specified for a folder, but the server did 151 specify a common APPENDLIMIT in the CAPABILITY response, then the 152 common APPENDLIMIT applies to that folder. 154 C: t2 SELECT INBOX 155 S: * 172 EXISTS 156 S: * OK [APPENDLIMIT 257890] Maximum upload limit 157 S: [...] 158 S: t2 OK [READ-WRITE] SELECT completed 160 In the above example, APPENDLIMIT represents the maximum upload size for 161 this mailbox. 163 OK [APPENDLIMIT ] Maximum upload limit for this mailbox, in bytes. 164 Refer to section 5 for more information. If this 165 is missing, the client can always honour the 166 value received as part of CAPABILITY response. 168 3.2 LIST response 170 IMAP client can get the mailbox specific APPENDLIMIT in authenticated 171 state, where it do not need to issue SELECT/EXAMINE command. LIST 172 command in combination with STATUS command can be issued to get the per 173 mailbox specific APPENDLIMIT set by the server. Refer RFC 5819 for the 174 usage of LIST command in combination with STATUS command. Note that a 175 server implementing this extension, is syntactically compatible with 176 RFC 5819, however support for RFC 5258 or RFC 5819 is not required, 177 when implementing this extension. 179 The following example demonstrates, its usage. 181 C: t1 LIST "" % RETURN (STATUS (APPENDLIMIT)) 182 S: * LIST () "." "INBOX" 183 S: * STATUS "INBOX" (APPENDLIMIT 257890) 184 S: t1 OK List completed. 186 New attribute APPENDLIMIT is added to get the limit set by the server 187 for this mailbox as part of STATUS command. The STATUS response occurs 188 as a result of an STATUS command. It returns the mailbox name that 189 matches the STATUS specification and the requested mailbox status 190 information. IMAP server should recognize an extra "RETURN (STATUS 191 (APPENDLIMIT))" at the end of a LIST command and emit an extra STATUS 192 response for each matching mailbox. Refer to section 5 for the syntax. 194 Invoking STATUS command with APPENDLIMIT is also acceptable. Below 195 example demonstrates, its usage. 197 C: t1 STATUS INBOX (APPENDLIMIT) 198 S: * STATUS INBOX (APPENDLIMIT 257890) 199 S: t1 OK STATUS completed 201 4. APPEND response 203 If client uploads a mail which exceeds the maximum upload size set 204 to that mailbox, then server SHALL reject the APPEND command with a 205 tagged TOOBIG response code. Refer RFC 4469 Section (4) for various 206 APPEND response codes and its handling. 208 Client can avoid use of LITERAL+, when maximum upload size 209 supported by the IMAP server is unknown. 211 5. Formal syntax 213 The following syntax specification uses the Augmented Backus-Naur 214 Form (ABNF) notation as specified in [RFC5234] including the core 215 rules in Appendix B.1. [RFC3501] defines the non-terminals 216 "capability", "resp-text-code" and "status-att". 217 Except as noted otherwise, all alphabetic characters are case- 218 insensitive. The use of upper or lower case characters to define 219 token strings is for editorial clarity only. Implementations MUST 220 accept these strings in a case-insensitive fashion. 222 appendlimit-cap = "APPENDLIMIT" ["=" append-limit-value] 223 capability /= appendlimit-cap 225 appendlimit-respcode = "APPENDLIMIT" SP append-limit-value 226 resp-text-code /= appendlimit-respcode 228 append-limit-value = 1*DIGIT 229 ; Unsigned 64-bit integer 230 ; (0 <= n < 18,446,744,073,709,551,615) 232 appendlimit-status-att = "APPENDLIMIT" 233 status-att /=appendlimit-status-att 235 A number indicating the fixed maximum message size in bytes that the 236 server will accept. APPENDLIMIT=0 indicates the server SHALL not 237 accept APPEND command due to size restriction. The syntax of the 238 parameter follows the augmented BNF notation of [RFC5234]. If this 239 capability is omitted, no information is conveyed about the server's 240 fixed maximum mail upload size. 242 6. Security Consideration 244 It is believed that this extension doesn't add any new security 245 considerations that are not already present in the base IMAP 246 protocol [RFC3501]. 248 7. IANA Considerations 250 The IANA is requested to add APPENDLIMIT to the IMAP4 Capabilities 251 Registry. [[Note to RFC-editor: please remove the following before 252 publication: This registration should take place at the following 253 location: http://www.iana.org/assignments/imap4-capabilities]] 255 8. References 257 8.1 Normative References 259 The following documents contain definitions or specifications that 260 are necessary to understand this document properly 262 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 263 Requirement Levels", RFC 2119, Harvard University, March 264 1997. 266 [RFC3501] Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 267 University of Washington, March 2003 269 [RFC5234] Crocker, Overell, "Augmented BNF for Syntax 270 Specifications: ABNF", RFC 5234, Brandenburg 271 Internetworking, Demon Internet Ltd, January 2008 273 [RFC5322] P. Resnick, Ed, "Internet Message Format", RFC 5322, 274 Qualcomm Incorporated, October 2008 276 [RFC2088] J. Myers, Carnegie Mellon, "IMAP4 non-synchronizing 277 literals", January 1997 279 [RFC4469] P. Resnick, "Internet Message Access Protocol (IMAP) 280 CATENATE Extension", April 2006 282 [RFC5819] A. Melnikov, T. Sirainen, "IMAP4 Extension for Returning 283 STATUS Information in Extended LIST", March 2010 285 [RFC5258] A. Melnikov, B. Leiba, "Internet Message Access Protocol 286 version 4 - LIST Command Extensions", March 2010 288 8. 2 Informative References 290 The following documents describe related protocols: 292 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, 293 January 1997 295 [RFC7377] B. Leiba, A. Melnikov, "IMAP4 Multimailbox SEARCH 296 Extension", RFC 7377, October 2014 298 9. Acknowledgement 300 TBD 302 10. Author's Address 304 Jayantheesh S B 305 Samsung Telecommunications America, 306 685 US Highway 202/206, 307 Bridgewater, NJ 08807. 308 USA 309 Email: jayantheesh.sb@gmail.com 311 Narendra Singh Bisht 312 Samsung Telecommunications America, 313 685 US Highway 202/206, 314 Bridgewater, NJ 08807. 315 USA 316 Email: narendrasingh.bisht@gmail.com