INTERNET-DRAFT Jayantheesh S B Intended status: Standards Track Samsung Expires: January, 2016 Narendra Singh Bisht Samsung August 14, 2015 The IMAP APPENDLIMIT Extension draft-ietf-imapapnd-appendlimit-extension-02 Abstract This memo defines an extension to the IMAP service whereby a server can advertise its capability, to support maximum mail upload size using CAPABILITY, STATUS and LIST commands. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Jayantheesh & Narendra Expires January, 2016 [Page 1] Internet-Draft IMAP APPENDLIMIT August 2015 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 2. APPENDLIMIT Extension . . . . . . . . . . . . . . . . . . . . . 3 3. Mailbox specific APPENDLIMIT . . . . . . . . . . . . . . . . . . 3 3.1. STATUS response . . . . . . . . . . . . . . . . . . . . . . 3 3.2. LIST response . . . . . . . . . . . . . . . . . . . . . . . 4 4. APPEND response . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1 Normative References . . . . . . . . . . . . . . . . . . . . . 5 8.2 Informative References . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Author's Address . .. . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Several IMAP server have limitation for mail upload size which is not published to the email client. When email client APPEND a mail with huge attachments, it fails due to size restriction set by the IMAP server. This results in unnecessary resource usage. Especially in the mobile device environment, appending mail with huge attachment consumes device resources like device battery power and mobile data. The IMAP APPENDLIMIT extension provides an ability to advertise maximum upload size allowed by the IMAP server, so that email client knows the size limitation beforehand. 1.1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. The five characters [...] means that something has been elided. Jayantheesh & Narendra Expires January, 2016 [Page 2] Internet-Draft IMAP APPENDLIMIT August 2015 2. APPENDLIMIT Extension An IMAP server that supports APPENDLIMIT extension advertises this by including the name APPENDLIMIT in its capability list. IMAP server can publish the APPENDLIMIT capability in two formats. (a) APPENDLIMIT= This indicates that the IMAP server has the same upload limit for all the mailboxes. The following example, demonstrates the APPENDLIMIT capability with same upload limit for all mailboxes. C: t1 CAPABILITY S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890 S: t1 OK foo (b) APPENDLIMIT APPENDLIMIT capability without any value indicates that the IMAP server has specific upload limit for different mailboxes. The following example, demonstrates the APPENDLIMIT capability without any value. C: t1 CAPABILITY S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT S: t1 OK foo In this case the client should get APPENDLIMIT value by issuing STATUS or LIST command. New response code APPENDLIMIT is added to get the mailbox specific limit. Refer section 5 for response code syntax. IMAP client should be able to parse both kind of formats. By looking at the upload size advertised by the IMAP server, client MUST not try to upload mail more than advertised limit. 3. Mailbox specific APPENDLIMIT IMAP server can have mailbox specific APPENDLIMIT value, which will not be advertised as part of CAPABILITY response. In this case, client can issue STATUS or LIST in combination with STATUS command, if the server supports LIST-STATUS capability, to get the per mailbox specific limit. 3.1 STATUS response A new attribute APPENDLIMIT is added to get the limit set by the server for a mailbox as part of STATUS command. IMAP client should issue STATUS command with APPENDLIMIT item to get the mailbox specific upload value. The following example, demonstrates its usage. Jayantheesh & Narendra Expires January, 2016 [Page 3] Internet-Draft IMAP APPENDLIMIT August 2015 C: t1 STATUS INBOX (APPENDLIMIT) S: * STATUS INBOX (APPENDLIMIT 257890) S: t1 OK STATUS completed IMAP server should return the mailbox name that matches the STATUS specification and the requested mailbox status information. In the above example, APPENDLIMIT represents the maximum upload size for INBOX. 3.2 LIST-STATUS response IMAP client can issue LIST in combination with STATUS command to get the mailbox specific upload value, if the server supports LIST-STATUS extension. The following example, demonstrates its usage. C: t1 LIST "" % RETURN (STATUS (APPENDLIMIT)) S: * LIST () "." "INBOX" S: * STATUS "INBOX" (APPENDLIMIT 257890) S: t1 OK List completed. IMAP server should recognize an extra "RETURN (STATUS (APPENDLIMIT))" at the end of a LIST command and emit an extra STATUS response for each matching mailbox. Refer to section 5 for the syntax. Refer RFC 5819 for the usage of LIST in combination with STATUS command. If the server does not support this extension, then client should use STATUS command instead. 4. APPEND response If client uploads a mail which exceeds the maximum upload size set to that mailbox, then server SHALL reject the APPEND command with a tagged TOOBIG response code. Refer RFC 4469 Section (4) for various APPEND response codes and its handling. Client can avoid use of LITERAL+, when maximum upload size supported by the IMAP server is unknown. Refer RFC 4549 section 4.2.2.3 for usage of LITERAL+ and its risk for disconnected IMAP clients. Jayantheesh & Narendra Expires January, 2016 [Page 4] Internet-Draft IMAP APPENDLIMIT August 2015 5. Formal syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234] including the core rules in Appendix B.1. [RFC3501] defines the non-terminals "capability", "resp-text-code" and "status-att". Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. appendlimit-cap = "APPENDLIMIT" ["=" number] capability /= appendlimit-cap appendlimit-respcode = "APPENDLIMIT" SP number resp-text-code /= appendlimit-respcode appendlimit-status-att = "APPENDLIMIT" status-att /=appendlimit-status-att 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. 6. Security Consideration It is believed that this extension doesn't add any new security considerations that are not already present in the base IMAP protocol [RFC3501]. 7. IANA Considerations The IANA is requested to add APPENDLIMIT to the IMAP4 Capabilities Registry. [[Note to RFC-editor: please remove the following before publication: This registration should take place at the following location: http://www.iana.org/assignments/imap4-capabilities]] 8. References 8.1 Normative References The following documents contain definitions or specifications that are necessary to understand this document properly Jayantheesh & Narendra Expires January, 2016 [Page 5] Internet-Draft IMAP APPENDLIMIT August 2015 [RFC2119] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [RFC3501] Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", University of Washington, March 2003 [RFC5234] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, Brandenburg Internetworking, Demon Internet Ltd, January 2008 [RFC5322] P. Resnick, Ed, "Internet Message Format", RFC 5322, Qualcomm Incorporated, October 2008 [RFC2088] J. Myers, Carnegie Mellon, "IMAP4 non-synchronizing literals", January 1997 [RFC4469] P. Resnick, "Internet Message Access Protocol (IMAP) CATENATE Extension", April 2006 [RFC5819] A. Melnikov, T. Sirainen, "IMAP4 Extension for Returning STATUS Information in Extended LIST", March 2010 [RFC5258] A. Melnikov, B. Leiba, "Internet Message Access Protocol version 4 - LIST Command Extensions", March 2010 [RFC4549] A. Melnikov, Ed. "Synchronization Operations for Disconnected IMAP4 Clients", June 2006 8. 2 Informative References The following documents describe related protocols: [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997 [RFC7377] B. Leiba, A. Melnikov, "IMAP4 Multimailbox SEARCH Extension", RFC 7377, October 2014 9. Acknowledgement Thanks to Alexey Melnikov, Dave Cridland, Adrien de Croy, Michael M Slusarz, Timo Sirainen, Chris Newman, Pete Maclean, Jamie Nicolson, Stu Brandt, Bron Gondwana, Arnt Gulbrandsen, Cyrus Daboo, Jan Kundrat, Brandon Long and Barry Leiba for providing valuable comments. Jayantheesh & Narendra Expires January, 2016 [Page 6] Internet-Draft IMAP APPENDLIMIT August 2015 10. Author's Address Jayantheesh S B Samsung Telecommunications America 685 US Highway 202/206 Bridgewater, NJ 08807 USA Email: jayantheesh.sb@gmail.com Narendra Singh Bisht Samsung Telecommunications America 685 US Highway 202/206 Bridgewater, NJ 08807 USA Email: narendrasingh.bisht@gmail.com Jayantheesh & Narendra Expires January, 2016 [Page 7]