Skip to main content

The IMAP APPENDLIMIT Extension
draft-jayantheesh-imap-appendlimit-extension-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Jayantheesh , Narendra Singh Bisht
Last updated 2014-11-18
Replaced by draft-ietf-imapapnd-appendlimit-extension, RFC 7889
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jayantheesh-imap-appendlimit-extension-00
INTERNET-DRAFT                                           Jayantheesh S B 
Intended status: Standards Track                                 Samsung
Expires: May 2015                                   Narendra Singh Bisht
                                                                 Samsung
                                                       November 18, 2014

                      The IMAP APPENDLIMIT Extension
                draft-jayantheesh-imap-appendlimit-extension-00

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 and SELECT/EXAMINE command.

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 May, 2015.

Copyright Notice

Copyright (c) 2014 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.

Jayantheesh & Narendra       Expires May, 2015               [Page 1]
Internet-Draft               IMAP APPENDLIMIT           November 2014

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1. Conventions and Terminology . . . . . . . . . .  . . . . .   2
   2. APPENDLIMIT Extension . . . . . . . . . . . . . . . . . . . . .  2
   3. SELECT response . . . . . . . . . . . . . . . . . . . . . . . .  3
   4. APPEND response . . . . . . . . . . . . . . . . . . . . . . . .  4
   5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . .  4
   6. Security Considerations  . . . . . . . . . . . . . . . . . . . . 5
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  5
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
    8.1 Normative References . . . . . . . . . . . . . . . . . . . . . 5
    8.2 Informative References . . . . . . . . . . . . . . . . . . . . 5
   9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . .  6
   10. Author's Address . .. . . . . . . . . . . . . . . . . . . . . . 6
   

1. Introduction

Several IMAP server have limitation in 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.

2. APPENDLIMIT Extension

An IMAP server that supports APPENDLIMIT advertises this by including
the word APPENDLIMIT in its capability list.  IMAP server shall publish
the supported mail upload size as part of CAPABILITY response.  The
advertised upload limit is common across the mailboxes, but client
can still issue SELECT/EXAMINE command to get the mailbox specific

Jayantheesh & Narendra       Expires May, 2015               [Page 2]
Internet-Draft               IMAP APPENDLIMIT           November 2014

upload limit set by the IMAP server.  In this case, APPENDLIMIT value
obtained as part of SELECT/EXAMINE command takes precedence over the
value returned as part of CAPABILITY response.

The following example, demonstrates the APPENDLIMIT capability with
mailbox limit.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
S: t1 OK foo

If APPENDLIMIT value is omitted in CAPABILITY response, then client
SHOULD issue SELECT/EXAMINE command to get the mailbox specific limit
set by the server.  New response code APPENDLIMIT is added to get the
mailbox specific limit.  Refer section [5] for response code syntax.

The following example demonstrates, its usage.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT
S: t1 OK foo

C: t2 SELECT INBOX
S: * 172 EXISTS
S: * OK [APPENDLIMIT 257890] Maximum upload limit
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: t2 OK [READ-WRITE] SELECT completed

By looking at the upload size restriction set by the IMAP server, client
SHALL not try to upload mail more than advertised limit in the APPEND
command. 

3. SELECT response

IMAP server may have mailbox specific maximum upload limit.  Client can
get the limit by issuing the SELECT/EXAMINE command.  APPENDLIMIT size to
this mailbox is obtained as part of untagged OK response.

In this case, this APPENDLIMIT value will supersede the value received
as part of CAPABILITY response.

C: t2 SELECT INBOX
S: * 172 EXISTS
S: * OK [APPENDLIMIT 257890] Maximum upload limit
S: [...]
S: t2 OK [READ-WRITE] SELECT completed
Jayantheesh & Narendra       Expires May, 2015               [Page 3]
Internet-Draft               IMAP APPENDLIMIT           November 2014

In the above example, APPENDLIMIT represents the maximum upload size for
this mailbox.

OK [APPENDLIMIT <n>] Maximum upload limit for this mailbox, in bytes.
                     Refer to section [5] for more information.  If this
                     is missing, the client can always honour the
                     value received as part of CAPABILITY response.

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 NO response with maximum allowed size set by the server.

The following example demonstrates, its usage.

C: t1 APPEND "Draft" (\SEEN \DRAFT) {98994952}
S: t1 NO [APPENDLIMIT 257890] Exceeds the maximum allowed size

Client can avoid use of LITERAL+, when maximum upload size
supported by the IMAP server is unknown. 

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" and "resp-text-code".
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" ["=" nz-number]
capability /= appendlimit-cap

appendlimit-respcode = "APPENDLIMIT" SP nz-number
resp-text-code /= appendlimit-respcode

A non-zero number indicating the fixed maximum message size in bytes
that the server will accept.  The syntax of the parameter follows the
augmented BNF notation of [RFC 5234].  If this capability is
omitted, no information is conveyed about the server's fixed maximum
mail upload size.

Jayantheesh & Narendra       Expires May, 2015               [Page 4]
Internet-Draft               IMAP APPENDLIMIT           November 2014

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

[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

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

                   
Jayantheesh & Narendra       Expires May, 2015               [Page 5]
Internet-Draft               IMAP APPENDLIMIT           November 2014

9. Acknowledgement

TBD

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 May, 2015               [Page 6]