idnits 2.17.00 (12 Aug 2021) /tmp/idnits30966/draft-ietf-imapapnd-rfc2088bis-04.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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 6, 2016) is 2260 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) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) == Outdated reference: draft-ietf-imapapnd-appendlimit-extension has been published as RFC 7889 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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) March 6, 2016 5 Intended status: Standards Track 6 Expires: September 7, 2016 8 IMAP4 non-synchronizing literals 9 draft-ietf-imapapnd-rfc2088bis-04.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 that does not require this network round 19 trip. 21 This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. 22 LITERAL+ allows the alternate form of literals in all IMAP commands. 23 LITERAL- is the same as LITERAL+, but disallows the alternate form of 24 literals unless they are 4096 bytes or less. 26 This document obsoletes RFC 2088. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 7, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 76 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 77 4. Considerations on when to use and not to use synchronizing 78 literals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 5. LITERAL- capability . . . . . . . . . . . . . . . . . . . . . 5 80 6. Interaction with BINARY extension . . . . . . . . . . . . . . 6 81 7. Interaction with MULTIAPPEND extension . . . . . . . . . . . 6 82 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 85 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 88 12.2. Informative References . . . . . . . . . . . . . . . . . 8 89 Appendix A. Changes since RFC 2088 . . . . . . . . . . . . . . . 8 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 92 1. Introduction 94 The Internet Message Access Protocol [RFC3501] contains the "literal" 95 syntactic construct for communicating strings. When sending a 96 literal from client to server, IMAP requires the client to wait for 97 the server to send a command continuation request between sending the 98 octet count and the string data. This document specifies an 99 alternate form of literal that does not require this network round 100 trip. 102 This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. 103 LITERAL+ allows the alternate form of literals (called "non- 104 synchronized literals" below) in all IMAP commands. LITERAL- is the 105 same as LITERAL+, but disallows the alternate form of literals unless 106 they are 4096 bytes or less. 108 2. Requirements Notation 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 In examples, "C:" and "S:" indicate lines sent by the client and 115 server respectively. If a single "C:" or "S:" label applies to 116 multiple lines, then the line breaks between those lines are for 117 editorial clarity only and are not part of the actual protocol 118 exchange. 120 3. Specification 122 The non-synchronizing literal is added as an alternate form of 123 literal, and may appear in communication from client to server 124 instead of the IMAP [RFC3501] form of literal. The IMAP form of 125 literal, used in communication from client to server, is referred to 126 as a synchronizing literal. The non-synchronizing literal form MUST 127 NOT be sent from server to client. 129 Non-synchronizing literals may be used with any IMAP server 130 implementation that returns "LITERAL+" or "LITERAL-" as one of the 131 supported capabilities to the CAPABILITY command. If the server does 132 not advertise either of the above capabilities, the client can only 133 use synchronizing literals. The difference between "LITERAL+" and 134 "LITERAL-" extensions is explained in Section 5. 136 The non-synchronizing literal is distinguished from the original 137 synchronizing literal by having a plus ('+') between the octet count 138 and the closing brace ('}'). The server does not generate a command 139 continuation request in response to a non-synchronizing literal, and 140 clients are not required to wait before sending the octets of a non- 141 synchronizing literal. 143 The protocol receiver of an IMAP server MUST check the end of every 144 received line (a sequence of octets that ends with a CRLF) for an 145 open brace ('{') followed by an octet count, a plus ('+'), and a 146 close brace ('}') immediately preceeding the CRLF. If it finds this 147 sequence, it is the octet count of a non-synchronizing literal and 148 the server MUST treat the specified number of following octets and 149 the the following line ([RFC3501]) as part of the same command. 151 It's important to note that the literal is not delimited by CRLF. It 152 ends after the number of bytes specified by the octet count, and the 153 current command continues from there. There might be a CRLF 154 immediately after, which ends the command. Or there might be more 155 octets, specifying other command parameters, before the CRLF. If a 156 SP (space) character is needed between parameters, it's important 157 that the SP appear after the literal, in its appropriate place. 159 A server MAY still process commands and reject errors on a line-by- 160 line basis, as long as it checks for non-synchronizing literals at 161 the end of each line. 163 Example: 165 C: A001 LOGIN {11+} 166 C: FRED FOOBAR {7+} 167 C: fat man 168 S: A001 OK LOGIN completed 170 This is semantically equivalent to this version that uses quoted 171 strings instead of literals: 173 C: A001 LOGIN "FRED FOOBAR" "fat man" 174 S: A001 OK LOGIN completed 176 Note that the space after FOOBAR in the first version corresponds 177 to the space between the two quoted strings in the second. 179 4. Considerations on when to use and not to use synchronizing literals 181 This section is important to understand for both client and server 182 developers of this IMAP extension. 184 While non-synchronizing literals have clear advantages for clients, 185 such as simplicity of use, they might be more difficult to handle on 186 the server side. When a client uses a non-synchronizing literal that 187 is too big for the server to accept, a compliant LITERAL+ server 188 implementation has to make a choice between couple non-optimal 189 choices: 191 1. Read the number of bytes specified in the non-synchronizing 192 literal and reject the command that included the literal anyway. 193 (The server is allowed to send the tagged BAD/NO response before 194 reading the whole non-synchronizing literal.) This is quite 195 wasteful on bandwidth if the literal is large. 197 2. Send an untagged BYE response explaining the reason for rejecting 198 the literal (possibly accompanied by an ALERT response code in 199 another response) and close the connection. This will force the 200 client to reconnect or report the error to the user. In the 201 latter case the error is unlikely to be understandable to the 202 user. Additionally, some naive clients are known to blindly 203 reconnect in this case and repeat the operation that caused the 204 problem, introducing an infinite loop. 206 The problem described above is most common when using the APPEND 207 command, because most commands don't need to send lots of data from 208 the client to the server. Some server implementations impose limits 209 on literals (both synchronizing and non-synchronizing) accepted from 210 clients in order to defend against denial-of-service attacks. 211 Implementations can generally impose much lower limits on literal 212 sizes for all commands other than APPEND. In order to address 213 literal size issue in APPEND, this document introduces a new 214 extension "LITERAL-", described in Section 5. 216 The situation can also be improved by implementing support for the 217 APPENDLIMIT extension [APPENDLIMIT], which allows a server to 218 advertise its APPEND limit, so that well behaved clients can check it 219 and avoid uploading big messages in the first place. 221 5. LITERAL- capability 223 The "LITERAL-" extension is almost identical to "LITERAL+", with one 224 exception: when "LITERAL-" is advertised, non-synchronizing literals 225 used in any command MUST NOT be larger than 4096 bytes. Any literal 226 larger than 4096 bytes MUST be sent as an RFC 3501 synchronizing 227 literal. A "LITERAL-" compliant server that encounters a non- 228 synchronizing literal larger than 4096 bytes proceeds as described in 229 Section 4. If responding to an APPEND command, the tagged BAD 230 response MUST contains the TOOBIG response code [RFC4469]. If 231 responding with untagged BYE response, it SHOULD include the TOOBIG 232 response code. Note that the form of the non-synchronizing literal 233 does not change: it still uses the "+" in the literal itself, even if 234 the applicable extension is "LITERAL-". 236 Because "LITERAL-" is a more restricted version of "LITERAL+", IMAP 237 servers MUST NOT advertise both of these capabilities at the same 238 time. (A server implementation can choose to have a configuration 239 option to pick which one to advertise.) 241 6. Interaction with BINARY extension 243 RFC 4466 [RFC4466] updated the non-terminal "literal8" defined in 244 [RFC3516] to allow for non-synchronizing literals if both [RFC3516] 245 and "LITERAL+" extensions are supported by the server. 247 This document also allows use of this extended "literal8" syntax when 248 both [RFC3516] and "LITERAL-" extensions are supported by the server. 250 7. Interaction with MULTIAPPEND extension 252 RFC 3502 [RFC3502] describes MULTIAPPEND extension and how it can be 253 used with LITERAL+. The LITERAL- extension can be used with the 254 MULTIAPPEND extension in the same way. 256 8. Formal Syntax 258 The following syntax specification uses the Augmented Backus-Naur 259 Form (ABNF) notation as specified in [ABNF]. 261 Non-terminals referenced but not defined below are as defined by 262 [RFC3501]. 264 literal = "{" number ["+"] "}" CRLF *CHAR8 265 ; Number represents the number of CHAR8 octets 267 CHAR8 = 269 literal8 = 271 9. Security Considerations 273 Use of non-synchronizing literals can consume extra resources (e.g. 274 memory) on IMAP servers and can be used for denial-of-service 275 attacks. The "LITERAL-" extension partially improved this situation. 277 This document doesn't raise any other security concerns not already 278 raised by [RFC3501]. 280 10. IANA Considerations 282 IMAP4 capabilities are registered by publishing a standards track or 283 IESG approved experimental RFC. The registry is currently located 284 at: 286 http://www.iana.org/assignments/imap-capabilities 288 This document requests that IANA update the above registry replace 289 the reference for LITERAL+ to point to this document. 291 This document also requests that IANA add "LITERAL-" capability 292 pointing to this document to the above registry. 294 11. Acknowledgments 296 John G. Myers edited the original LITERAL+ extension. 298 Valuable comments, both in agreement and in dissent, were received 299 from Dave Cridland, Michael M Slusarz, Arnt Gulbrandsen, Jayantheesh 300 S B., Jamie Nicolson, Barry Leiba and SM. 302 12. References 304 12.1. Normative References 306 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 307 Specifications: ABNF", STD 68, RFC 5234, January 2008. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, 311 DOI 10.17487/RFC2119, March 1997, 312 . 314 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 315 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 316 . 318 [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, 319 DOI 10.17487/RFC3516, April 2003, 320 . 322 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 323 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, 324 . 326 [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) 327 CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April 328 2006, . 330 12.2. Informative References 332 [APPENDLIMIT] 333 SrimushnamBoovaraghamoorthy, J. and N. Bisht, "The IMAP 334 APPENDLIMIT Extension", draft-ietf-imapapnd-appendlimit- 335 extension-10 (work in progress), January 2016. 337 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - 338 MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502, 339 March 2003, . 341 Appendix A. Changes since RFC 2088 343 Added IANA registration. 345 Updated references. Also updated considerations about interactions 346 of IMAP extensions. 348 Additional implementation considerations based on the IMAP mailing 349 list discussions. 351 Added description of a new capability: LITERAL- . 353 Author's Address 355 Alexey Melnikov (editor) 356 Isode Ltd 357 14 Castle Mews 358 Hampton, Middlesex TW12 2NP 359 UK 361 Email: Alexey.Melnikov@isode.com