idnits 2.17.00 (12 Aug 2021) /tmp/idnits13066/draft-ietf-lemonade-compress-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 310. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2006) is 5788 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 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Downref: Normative reference to an Informational RFC: RFC 1951 (ref. 'DEFLATE') Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Arnt Gulbrandsen 2 Request for Comments: DRAFT Oryx Mail Systems GmbH 3 July 2006 5 The IMAP COMPRESS=DEFLATE Extension 6 draft-ietf-lemonade-compress-02.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 27 Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society 2006. 34 Abstract 36 The COMPRESS=DEFLATE extension allows an IMAP connection to be 37 compressed using the DEFLATE algorithm, such that effective 38 compression is available even when TLS is used. 40 Table of Contents 42 1. Conventions Used in This Document . . . . . . . . . . . . . . 2 43 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 44 3. The COMPRESS Command . . . . . . . . . . . . . . . . . . . . . 3 45 4. Compression Efficiency . . . . . . . . . . . . . . . . . . . . 4 46 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 47 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 48 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 49 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 50 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 52 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 53 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 54 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 1. Conventions Used in This Document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 61 Formal syntax is defined by [ABNF] as modified by [IMAP]. 63 In the example, "C:" and "S:" indicate lines sent by the client and 64 server respectively. 66 2. Introduction and Overview 68 An IMAP server that supports this extension announces 69 "COMPRESS=DEFLATE" as one of its capabilities. 71 The goal of COMPRESS=DEFLATE is to reduce the bandwidth usage of 72 IMAP. On regular IMAP connections, the PPP or MNP compression used 73 with many low-bandwidth links compresses IMAP well. However, when 74 TLS is used, PPP/MNP compression is ineffective. TLS too may provide 75 compression, but a careful IMAP implementation can do much better. 77 In order to increase interoperation, it is desirable to have as few 78 different compression algorithms as possible, so this document 79 specifies only one. The DEFLATE algorithm is standard, widely 80 available, unencumbered by patents and fairly efficient. Hopefully 81 it will not be necessary to define additional algorithms. 83 The extension adds one new command (COMPRESS) and no new responses. 85 3. The COMPRESS Command 87 Arguments: Name of compression mechanism: "DEFLATE". 89 Responses: None 91 Result: OK The server will compress its responses and expects the 92 client to compress its commands. 93 NO The server doesn't support the requested mechanism. 94 BAD Command unknown, invalid argument, or COMPRESS already 95 active. 97 The COMPRESS command instructs the server to use the named 98 compression mechanism ("DEFLATE" is the only one defined) for all 99 commands and/or responses after COMPRESS. 101 The client MUST NOT send any commands until it has seen the result 102 of COMPRESS. 104 For DEFLATE (as for many other compression mechanisms), the 105 compressor can trade speed against quality. When decompressing 106 there isn't much of a tradeoff. Consequently, the client and server 107 are both free to pick the best reasonable rate of compression for 108 the data they send. 110 If both [STARTTLS] and COMPRESS are in use, the data should be 111 compressed before it is encrypted (and decrypted before it is 112 decompressed), independent of the order in which the client issues 113 COMPRESS, AUTHENTICATE and STARTTLS. 115 The following example illustrates how commands and responses are 116 compressed during a simple login sequence: 118 S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE] 119 C: a starttls 120 S: a OK TLS active 122 From this point on, everything is encrypted. 124 C: b compress deflate 125 S: b OK DEFLATE active 127 From this point on, everything is compressed before being 128 encrypted. 130 C: c login arnt tnra 131 S: c OK Logged in as arnt 133 4. Compression Efficiency 135 IMAP poses some unusual problems for a compression layer. 137 Upstream is fairly simple. Most IMAP clients send the same few 138 commands again and again, so any compression algorith which can 139 exploit repetition works efficiently. The APPEND command is an 140 exception; clients which send many APPEND commands may want to take 141 special care of literals, in the same way that servers do. 143 Downstream has the unusual property that several kinds of data are 144 sent, confusing all dictionary-based compression algorithms. 146 One type is IMAP responses. These are highly compressible; zlib 147 using its least CPU-intensive setting compresses typical responses 148 to 25-40% of their original size. 150 Another is email headers. These are equally compressible, and 151 benefit from using the same dictionary as the IMAP responses. 153 A third is email body text. Text is usually fairly short and 154 includes much ASCII, so the same compression dictionary will do a 155 good job here, too. When multiple messages in the same thread are 156 read at the same time, quoted lines etc. can often be compressed 157 almost to zero. 159 Finally, attachments (non-text email bodies) are transmitted, either 160 in [BINARY] form or encoded with base-64. 162 When attachments are retrieved in [BINARY] form, DEFLATE may be able 163 to compress them, but the format of the attachment is usually not 164 IMAP-like, so the dictionary built while compressing IMAP does not 165 help. The compressor has to adapt its dictionary from IMAP to the 166 attachment's format, and then back. A few file formats aren't 167 compressible at all using deflate, e.g. .gz, .zip and .jpg files. 169 When attachments are retrieved in base-64 form, the same problems 170 apply, but the base-64 encoding adds another problem. 8-bit 171 compression algorithms such as deflate work well on 8-bit file 172 formats, however base-64 turns a file into something resembling 173 6-bit bytes, hiding most of the 8-bit file format from the 174 compressor. 176 When using the zlib library (see [DEFLATE]), the functions 177 deflateInit(), deflate(), inflateInit() and inflate() suffice to 178 implement this extension. deflateParams() can be used to improve 179 compression rate and resource use. 181 A client can improve downstream compression by implementing [BINARY] 182 and using FETCH BINARY instead of FETCH BODY. In the author's 183 experience, the improvement ranges from 5% to 40% depending on the 184 attachment being downloaded. 186 A server can improve downstream compression if it hints to the 187 compressor that the data type is about to change strongly, e.g. by 188 sending a Z_FULL_FLUSH at the start and end of large non-text 189 literals (before and after '*CHAR8' in the definition of literal in 190 RFC 3501, page 86). Small literals are best left alone. 192 A server can improve the CPU efficiency both of the server and the 193 client if it adjusts the compression level (e.g. using the 194 deflateParams() function in zlib) at these points. A very simple 195 strategy is to change the level 0 to at the start of a literal 196 provided the first two bytes are either 0x1F 0x8B (as in deflate- 197 compressed files) or 0xFF 0xD8 (JPEG), and to keep it at 1-5 the 198 rest of the time. 200 Note that when using TLS, compression may actually decrease the CPU 201 usage, depending on which algorithms are used in TLS. This is 202 because fewer bytes need to be encrypted, and encryption is 203 generally more expensive than compression. 205 5. Formal Syntax 207 The following syntax specification uses the Augmented Backus-Naur 208 Form (ABNF) notation as specified in [ABNF]. Non-terminals 209 referenced but not defined below are as defined by [ABNF] (SP, CRLF) 210 or [IMAP] (all others). 212 Except as noted otherwise, all alphabetic characters are case- 213 insensitive. The use of upper or lower case characters to define 214 token strings is for editorial clarity only. Implementations MUST 215 accept these strings in a case-insensitive fashion. 217 command-any =/ compress 219 compress = "COMPRESS" SP algorithm 221 algorithm = "DEFLATE" 223 6. Security Considerations 225 As for [TLSCOMP] RFC 3749. 227 7. IANA Considerations 229 The IANA is requested to add COMPRESS=DEFLATE to the list of IMAP 230 extensions. 232 8. Acknowledgements 234 Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther, 235 Randall Gellens, Tony Hansen, Alexey Melnikov, Lyndon Nerenberg and 236 Zoltan Ordogh have all helped with this document. 238 The author would also like to thank various people in the rooms at 239 meetings, whose help is real, but not reflected in the author's 240 mailbox. 242 9. References 244 9.1. Normative References 246 [ABNF] Crocker, Overell, "Augmented BNF for Syntax 247 Specifications: ABNF", RFC 4234, Brandenburg 248 Internetworking, Demon Internet Ltd, October 2005. 250 [IMAP] Crispin, "Internet Message Access Protocol - Version 251 4rev1", RFC 3501, University of Washington, June 2003. 253 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 254 Requirement Levels", RFC 2119, Harvard University, March 255 1997. 257 [DEFLATE] Deutsch, "DEFLATE Compressed Data Format Specification 258 version 1.3", RFC 1951, Aladdin Enterprises, May 1996. 260 [STARTTLS] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC 261 2595, June 1999. 263 9.2. Informative References 265 [TLSCOMP] Hollenbeck, "Transport Layer Security Protocol 266 Compression Methods", RFC 3749, VeriSign, May 2004. 268 [BINARY] Nerenberg, "IMAP4 Binary Content Extension", Orthanc 269 Systems, April 2003. 271 10. Author's Address 273 Arnt Gulbrandsen 274 Oryx Mail Systems GmbH 275 Schweppermannstr. 8 276 D-81671 Muenchen 277 Germany 279 Fax: +49 89 4502 9758 281 Email: arnt@oryx.com 283 11. Open Issues 285 What text and numbers are needed wrt. compression levels? A bit of 286 solid information is not amiss. 288 Intellectual Property Statement 290 The IETF takes no position regarding the validity or scope of any 291 Intellectual Property Rights or other rights that might be claimed 292 to pertain to the implementation or use of the technology described 293 in this document or the extent to which any license under such 294 rights might or might not be available; nor does it represent that 295 it has made any independent effort to identify any such rights. 296 Information on the procedures with respect to rights in RFC 297 documents can be found in BCP 78 and BCP 79. 299 Copies of IPR disclosures made to the IETF Secretariat and any 300 assurances of licenses to be made available, or the result of an 301 attempt made to obtain a general license or permission for the use 302 of such proprietary rights by implementers or users of this 303 specification can be obtained from the IETF on-line IPR repository 304 at http://www.ietf.org/ipr. 306 The IETF invites any interested party to bring to its attention any 307 copyrights, patents or patent applications, or other proprietary 308 rights that may cover technology that may be required to implement 309 this standard. Please address the information to the IETF at ietf- 310 ipr@ietf.org. 312 Copyright Statement 314 Copyright (C) The Internet Society (2006). 316 This document is subject to the rights, licenses and restrictions 317 contained in BCP 78, and except as set forth therein, the authors 318 retain all their rights. 320 Disclaimer of Validity 322 This document and the information contained herein are provided on 323 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 324 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 325 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 326 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 327 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 328 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 330 Acknowledgment 332 Funding for the RFC Editor function is currently provided by the 333 Internet Society.