idnits 2.17.1 draft-ietf-imapapnd-rfc2088bis-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. -- The draft header indicates that this document obsoletes RFC2088, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 5, 2016) is 3002 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) == Unused Reference: 'RFC3502' is defined on line 294, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov, Ed. 3 Internet-Draft Isode Ltd 4 Obsoletes: 2088 (if approved) February 5, 2016 5 Intended status: Standards Track 6 Expires: August 8, 2016 8 IMAP4 non-synchronizing literals 9 draft-ietf-imapapnd-rfc2088bis-02.txt 11 Abstract 13 The Internet Message Access Protocol (RFC 3501) contains the 14 "literal" syntactic construct for communicating strings. When 15 sending a literal from client to server, IMAP requires the client to 16 wait for the server to send a command continuation request between 17 sending the octet count and the string data. This document specifies 18 an alternate form of literal which does not require this network 19 round trip. 21 This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. 22 The former allows the alternate form of literals in all IMAP command. 23 The latter is the same as LITERAL+, but disallow the alternate form 24 of literals unless they are 4096 bytes or less. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 8, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Specification . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 74 3. Considerations on when to use and not to use synchronizing 75 literals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4. LITERAL- capability . . . . . . . . . . . . . . . . . . . . . 4 77 5. Interaction with BINARY extension . . . . . . . . . . . . . . 5 78 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 81 9. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 85 11.2. Informative References . . . . . . . . . . . . . . . . . 7 86 Appendix A. Changes since RFC 2088 . . . . . . . . . . . . . . . 7 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 89 1. Specification 91 The non-synchronizing literal is added an alternate form of literal, 92 and may appear in communication from client to server instead of the 93 IMAP [RFC3501] form of literal. The IMAP form of literal, used in 94 communication from client to server, is referred to as a 95 synchronizing literal. The non-synchronizing literal form MUST NOT 96 be sent from server to client. 98 Non-synchronizing literals may be used with any IMAP server 99 implementation which returns "LITERAL+" or "LITERAL-" as one of the 100 supported capabilities to the CAPABILITY command. If the server does 101 not advertise either of the above capabilities, the client must use 102 synchronizing literals instead. The difference between "LITERAL+" 103 and "LITERAL-" extensions is explained in Section 4. 105 The non-synchronizing literal is distinguished from the original 106 synchronizing literal by having a plus ('+') between the octet count 107 and the closing brace ('}'). The server does not generate a command 108 continuation request in response to a non-synchronizing literal, and 109 clients are not required to wait before sending the octets of a non- 110 synchronizing literal. 112 The protocol receiver of an IMAP server must check the end of every 113 received line (a sequence of octets that end with a CRLF) for an open 114 brace ('{') followed by an octet count, a plus ('+'), and a close 115 brace ('}') immediately preceeding the CRLF. If it finds this 116 sequence, it is the octet count of a non- synchronizing literal and 117 the server MUST treat the specified number of following octets and 118 the following line as part of the same command. A server MAY still 119 process commands and reject errors on a line-by-line basis, as long 120 as it checks for non-synchronizing literals at the end of each line. 122 Example: 124 C: A001 LOGIN {11+} 125 C: FRED FOOBAR {7+} 126 C: fat man 127 S: A001 OK LOGIN completed 129 2. Requirements Notation 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 In examples, "C:" and "S:" indicate lines sent by the client and 136 server respectively. If a single "C:" or "S:" label applies to 137 multiple lines, then the line breaks between those lines are for 138 editorial clarity only and are not part of the actual protocol 139 exchange. 141 3. Considerations on when to use and not to use synchronizing literals 143 This section is important to understand for both client and server 144 developers of this IMAP extension. 146 While non-synchronizing literals have clear advantages for clients, 147 such as simplicity of use, they might be more difficilt to handle on 148 the server side. When a non synchronizing literal is used by a 149 client which is too big for the server to accept, a compliant 150 LITERAL+ server implementation has to make a choice between several 151 non optimal choices: 153 1. Read the number of bytes specified in the non synchronizing 154 literal and reject the command that included the literal anyway. 155 (The server is allowed to send the tagged BAD/NO response before 156 reading the whole non synchronizing literal.) This is quite 157 wasteful on bandwidth if the literal size is big. 159 2. Send the untagged BYE response explaining the reason for 160 rejecting the literal (possibly accompanied by an ALERT response 161 code in another response) and close the connection. This will 162 force the client to reconnect or report the error to the user. 163 In the latter case the error is unlikely to be understandable to 164 the user. Additionally, some naive clients are known to blindly 165 reconnect in this case and repeat the operation that caused the 166 problem, introducing an infinite loop. 168 The problem described above is most common when using the APPEND 169 command, because most of commands don't need to send lots of data 170 from the client to the server. Some server implementations impose 171 limits on literal (both synchronizing and non synchronizing) accepted 172 from clients in order to protect from Denial Of Service attacks. 173 Implementations can generally impose much lower limits on literal 174 sizes for all commands other than APPEND. In order to address 175 literal size issue in APPEND, this document introduces a new 176 extension "LITERAL-", described in Section 4. 178 The situation can also be improved by implementing support for the 179 APPENDLIMIT extension [APPENDLIMIT], which allows a server to 180 advertise its APPEND limit, so that well behaved clients can check it 181 and avoid uploading big messages in the first place. 183 4. LITERAL- capability 185 "LITERAL-" extension is almost identical to "LITERAL+", with one 186 exception: when "LITERAL-" is advertised, non synchronizing literals 187 used in any command MUST NOT be larger than 4096 bytes. When any 188 literal is larger than 4096, RFC 3501 synchronizing literals MUST be 189 used instead. A "LITERAL-" compliant server which encounters a non 190 synchronizing literal in APPEND larger than 4096 bytes MUST reject 191 such APPEND command with a tagged BAD response that contains TOOBIG 192 response code [RFC4469]. It then MAY proceed as described in 193 Section 3. 195 Because "LITERAL-" is a more restricted version of "LITERAL+", IMAP 196 servers MUST NOT advertise both of these capabilities at the same 197 time. (A server implementation can choose to have a configuration 198 option to pick which one to advertise.) 200 5. Interaction with BINARY extension 202 RFC 4466 [RFC4466] updated the non-terminal "literal8" defined in 203 [RFC3516] to allow for non-synchronizing literals if both [RFC3516] 204 and "LITERAL+" extensions are supported by the server. 206 This document also allows use of this extended "literal8" syntax when 207 both [RFC3516] and "LITERAL-" extensions are supported by the server. 209 6. Formal Syntax 211 The following syntax specification uses the Augmented Backus-Naur 212 Form (ABNF) notation as specified in [ABNF]. 214 Non-terminals referenced but not defined below are as defined by 215 [RFC3501]. 217 literal = "{" number ["+"] "}" CRLF *CHAR8 218 ; Number represents the number of CHAR8 octets 220 CHAR8 = 222 literal8 = 224 7. Security Considerations 226 Use of non synchronizing literals can consume extra resources (e.g. 227 memory) on IMAP servers and can be used for Denial-of-Service 228 attacks. Section 3 motivates creation of "LITERAL-" extension that 229 partially improves the situation. 231 This document doesn't raise any other security concerns not already 232 raised by [RFC3501]. 234 8. IANA Considerations 236 IMAP4 capabilities are registered by publishing a standards track or 237 IESG approved experimental RFC. The registry is currently located 238 at: 240 http://www.iana.org/assignments/imap-capabilities 242 This document requests that IANA updated the above registry to 243 include the entry for LITERAL+ capability pointing to this document. 245 This document also requests that IANA adds "LITERAL-" capability 246 pointing to this document to the above registry. 248 9. To Do 250 Exact semantics of LITERAL- is still in flux. 252 10. Acknowledgments 254 John G. Myers edited the original LITERAL+ extension. 256 Valuable comments, both in agreement and in dissent, were received 257 from Dave Cridland, Michael M Slusarz and Arnt Gulbrandsen. 259 11. References 261 11.1. Normative References 263 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 264 Specifications: ABNF", STD 68, RFC 5234, January 2008. 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, 268 DOI 10.17487/RFC2119, March 1997, 269 . 271 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 272 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 273 . 275 [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, 276 DOI 10.17487/RFC3516, April 2003, 277 . 279 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 280 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, 281 . 283 [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) 284 CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April 285 2006, . 287 11.2. Informative References 289 [APPENDLIMIT] 290 SrimushnamBoovaraghamoorthy, J. and N. Bisht, "The IMAP 291 APPENDLIMIT Extension", draft-ietf-imapapnd-appendlimit- 292 extension-10 (work in progress), January 2016. 294 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - 295 MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502, 296 March 2003, . 298 Appendix A. Changes since RFC 2088 300 Added IANA registration. 302 Updated references. Also updated considerations about interactions 303 of IMAP extensions. 305 Additional implementation considerations based on the IMAP mailing 306 list discussions. 308 Added description of a new capability: LITERAL- . 310 Author's Address 312 Alexey Melnikov (editor) 313 Isode Ltd 314 5 Castle Business Village 315 36 Station Road 316 Hampton, Middlesex TW12 2BX 317 UK 319 Email: Alexey.Melnikov@isode.com