doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc7889.txt b/doc/rfc/rfc7889.txt
new file mode 100644
index 0000000..0b2d447
--- /dev/null
+++ b/doc/rfc/rfc7889.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)    J. SrimushnamBoovaraghamoorthy
+Request for Comments: 7889                                      N. Bisht
+Category: Standards Track                    Samsung Electronics America
+ISSN: 2070-1721                                                 May 2016
+
+
+                     The IMAP APPENDLIMIT Extension
+
+Abstract
+
+   This document defines an extension to the IMAP service whereby a
+   server can inform the client about maximum message upload sizes,
+   allowing the client to avoid sending APPEND commands that will fail
+   because the messages are too large.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7889.
+
+Copyright Notice
+
+   Copyright (c) 2016 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 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.
+
+
+
+
+
+
+
+
+SrimushnamB. & Bisht         Standards Track                    [Page 1]
+
+RFC 7889             The IMAP APPENDLIMIT Extension             May 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  APPENDLIMIT Extension . . . . . . . . . . . . . . . . . . . .   3
+   3.  Mailbox-Specific APPENDLIMIT  . . . . . . . . . . . . . . . .   3
+     3.1.  STATUS Response to the STATUS Command . . . . . . . . . .   4
+     3.2.  STATUS Response to the LIST Command . . . . . . . . . . .   4
+     3.3.  APPENDLIMIT Behavior  . . . . . . . . . . . . . . . . . .   4
+   4.  APPEND Response . . . . . . . . . . . . . . . . . . . . . . .   4
+   5.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   5
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7
+
+1.  Introduction
+
+   Some IMAP servers have limits for message upload size, and those
+   limits are not published to the email client.  When the email client
+   APPENDs a message with huge attachments, using non-synchronizing
+   literals, the APPEND fails because of the upload limit, but the
+   client has already sent the message data anyway.  This results in
+   unnecessary resource usage.  Especially in the mobile device
+   environment, appending a message with huge attachments consumes
+   device resources like device battery power and mobile data.
+
+   The IMAP APPENDLIMIT extension provides the ability to advertise a
+   maximum upload size allowed by the IMAP server, so that the email
+   client knows the size limitation beforehand.  By implementing this
+   extension, IMAP server-side processing of huge attachments above the
+   maximum upload size can be avoided.
+
+1.1.  Conventions
+
+   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 [RFC2119].
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server, respectively.  If a single "C:" or "S:" label applies to
+   multiple lines, then the line breaks between those lines are for
+   editorial clarity only and are not part of the actual protocol
+   exchange.
+
+
+
+
+SrimushnamB. & Bisht         Standards Track                    [Page 2]
+
+RFC 7889             The IMAP APPENDLIMIT Extension             May 2016
+
+
+2.  APPENDLIMIT Extension
+
+   An IMAP server that supports the APPENDLIMIT extension advertises
+   this by including the name APPENDLIMIT in its capability list in the
+   authenticated state.  The server may also advertise this extension
+   before the user has logged in.  If this capability is omitted, no
+   information is conveyed about the server's fixed maximum size for
+   mail uploads.  An IMAP server can publish the APPENDLIMIT capability
+   in two formats.
+
+   (a) APPENDLIMIT=<number>
+
+   This indicates that the IMAP server has the same upload limit for all
+   mailboxes.  The following example demonstrates the APPENDLIMIT
+   capability with the same upload limit for all mailboxes.
+
+   C: t1 CAPABILITY
+   S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
+   S: t1 OK foo
+
+   (b) APPENDLIMIT
+
+   The APPENDLIMIT capability without any value indicates that the IMAP
+   server supports this extension, and that the client will need to
+   discover upload limits for each mailbox, as they might differ from
+   mailbox to mailbox.  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 can get an APPENDLIMIT value by either
+   issuing a STATUS or a LIST command.
+
+   An IMAP client implementing this extension should be able to parse
+   both mailbox-specific and global APPENDLIMIT responses.  By looking
+   at the upload size advertised by the IMAP server, a client can avoid
+   trying to APPEND mail more than the advertised limit.
+
+3.  Mailbox-Specific APPENDLIMIT
+
+   An IMAP server can have mailbox-specific APPENDLIMIT values that will
+   not be advertised as part of the CAPABILITY response.  The IMAP
+   server can publish specific values for each mailbox, and it can
+   publish "NIL" for a mailbox to convey that there is no APPENDLIMIT
+   for that mailbox.  The following subsections describe the changes to
+   the STATUS and LIST commands in support of this situation.
+
+
+
+SrimushnamB. & Bisht         Standards Track                    [Page 3]
+
+RFC 7889             The IMAP APPENDLIMIT Extension             May 2016
+
+
+3.1.  STATUS Response to the STATUS Command
+
+   A new attribute APPENDLIMIT is added to get the limit set by the
+   server for a mailbox as part of a STATUS command.  An IMAP client
+   should issue a STATUS command with an APPENDLIMIT item to get the
+   mailbox-specific upload value.  The following example demonstrates
+   its usage.
+
+   C: t1 STATUS INBOX (APPENDLIMIT)
+   S: * STATUS INBOX (APPENDLIMIT 257890)
+   S: t1 OK STATUS completed
+
+   In the above example, APPENDLIMIT represents the maximum upload size
+   for INBOX.
+
+3.2.  STATUS Response to the LIST Command
+
+   If the server advertises the LIST-STATUS capability [RFC5819], the
+   client can issue a LIST command in combination with the STATUS return
+   option to get the mailbox-specific upload value.  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.
+
+   The IMAP server MUST recognize the APPENDLIMIT attribute and include
+   an appropriate STATUS response for each matching mailbox.  Refer to
+   Section 5 for the syntax.
+
+   If the server does not support the STATUS return option on the LIST
+   command, then the client should use the STATUS command instead.
+
+3.3.  APPENDLIMIT Behavior
+
+   Computing the APPENDLIMIT should be fast and should not take Access
+   Control Lists (ACLs), quotas, or other such information into account.
+   The APPENDLIMIT specifies one part of the policy, but an APPEND
+   command can still fail due to issues related to ACLs and quotas, even
+   if the message being appended is smaller than the APPENDLIMIT.
+
+4.  APPEND Response
+
+   If a client uploads a message that exceeds the maximum upload size
+   set for that mailbox, then the server SHALL reject the APPEND command
+   with a tagged TOOBIG response code.  Refer to Section 4 of [RFC4469]
+   for various APPEND response codes and their handling.
+
+
+
+SrimushnamB. & Bisht         Standards Track                    [Page 4]
+
+RFC 7889             The IMAP APPENDLIMIT Extension             May 2016
+
+
+   A client SHOULD avoid use of non-synchronizing literals [RFC7888]
+   when the maximum upload size supported by the IMAP server is unknown.
+   Refer to Section 4.2.2.3 of [RFC4549] for usage of non-synchronizing
+   literals and its risk for disconnected IMAP clients.
+
+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 of that document.  [RFC3501] defines the non-
+   terminals "capability" and "status-att", and [RFC4466] defines
+   "status-att-val".
+
+   All alphabetic characters are case insensitive.  The use of uppercase
+   or lowercase characters to define token strings is for editorial
+   clarity only.  Implementations MUST accept these strings in a case-
+   insensitive fashion.
+
+   capability =/ "APPENDLIMIT" ["=" number]
+               ;; capability is defined in RFC 3501
+
+   status-att =/ "APPENDLIMIT"
+               ;; status-att is defined in RFC 3501
+
+   status-att-val =/ "APPENDLIMIT" SP (number / nil)
+                   ;; status-att-val is defined in RFC 4466
+
+
+   The number indicates the fixed maximum message size in octets that
+   the server will accept.  An APPENDLIMIT number of 0 indicates the
+   server will not accept any APPEND commands at all for the affected
+   mailboxes.
+
+6.  Security Considerations
+
+   This extension provides additional information that cooperative
+   clients can use as an optimization and does not introduce new
+   security concerns.  This extension does not address abusive clients
+   that intend to consume server resources, and servers will still have
+   to take action to disconnect and/or restrict access to clients that
+   exhibit abusive behavior.
+
+7.  IANA Considerations
+
+   IANA has added "APPENDLIMIT" to the "IMAP Capabilities" registry,
+   using this document as its reference.
+
+
+
+
+
+SrimushnamB. & Bisht         Standards Track                    [Page 5]
+
+RFC 7889             The IMAP APPENDLIMIT Extension             May 2016
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
+              <http://www.rfc-editor.org/info/rfc3501>.
+
+   [RFC4466]  Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
+              ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,
+              <http://www.rfc-editor.org/info/rfc4466>.
+
+   [RFC4469]  Resnick, P., "Internet Message Access Protocol (IMAP)
+              CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April
+              2006, <http://www.rfc-editor.org/info/rfc4469>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5819]  Melnikov, A. and T. Sirainen, "IMAP4 Extension for
+              Returning STATUS Information in Extended LIST", RFC 5819,
+              DOI 10.17487/RFC5819, March 2010,
+              <http://www.rfc-editor.org/info/rfc5819>.
+
+   [RFC7888]  Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals",
+              RFC 7888, DOI 10.17487/RFC7888, May 2016,
+              <http://www.rfc-editor.org/info/rfc7888>.
+
+8.2.  Informative References
+
+   [RFC4549]  Melnikov, A., Ed., "Synchronization Operations for
+              Disconnected IMAP4 Clients", RFC 4549,
+              DOI 10.17487/RFC4549, June 2006,
+              <http://www.rfc-editor.org/info/rfc4549>.
+
+
+
+
+
+
+
+
+
+
+SrimushnamB. & Bisht         Standards Track                    [Page 6]
+
+RFC 7889             The IMAP APPENDLIMIT Extension             May 2016
+
+
+Acknowledgements
+
+   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.
+
+Authors' Addresses
+
+   Jayantheesh SrimushnamBoovaraghamoorthy
+   Samsung Electronics America
+   685 US Highway 202/206
+   Bridgewater, NJ  08807
+   United States
+
+   Email: jayantheesh.sb@gmail.com
+
+
+   Narendra Singh Bisht
+   Samsung Electronics America
+   685 US Highway 202/206
+   Bridgewater, NJ  08807
+   United States
+
+   Email: narendrasingh.bisht@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+SrimushnamB. & Bisht         Standards Track                    [Page 7]
+