From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7889.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc7889.txt (limited to 'doc/rfc/rfc7889.txt') 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= + + 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, + . + + [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, + . + + [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 + ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, + . + + [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) + CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April + 2006, . + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for + Returning STATUS Information in Extended LIST", RFC 5819, + DOI 10.17487/RFC5819, March 2010, + . + + [RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals", + RFC 7888, DOI 10.17487/RFC7888, May 2016, + . + +8.2. Informative References + + [RFC4549] Melnikov, A., Ed., "Synchronization Operations for + Disconnected IMAP4 Clients", RFC 4549, + DOI 10.17487/RFC4549, June 2006, + . + + + + + + + + + + +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] + -- cgit v1.2.3