idnits 2.17.00 (12 Aug 2021) /tmp/idnits14931/draft-ietf-lemonade-compress-05.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 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 374. ** 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 (October 2006) is 5696 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 October 2006 5 The IMAP COMPRESS Extension 6 draft-ietf-lemonade-compress-05.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 extension allows an IMAP connection to be effectively 37 and efficiently compressed. 39 Internet-draft August 2006 41 Table of Contents 43 1. Conventions Used in This Document . . . . . . . . . . . . . . 2 44 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 45 3. The COMPRESS Command . . . . . . . . . . . . . . . . . . . . . 3 46 4. Compression Efficiency . . . . . . . . . . . . . . . . . . . . 4 47 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 48 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 49 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 50 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 51 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 52 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 53 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 54 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 55 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 1. Conventions Used in This Document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 62 Formal syntax is defined by [ABNF] as modified by [IMAP]. 64 In the example, "C:" and "S:" indicate lines sent by the client and 65 server respectively. 67 2. Introduction and Overview 69 A server which supports the COMPRESS extension indicates this with 70 one or more capability names consisting of "COMPRESS=" followed by a 71 supported compression algorithm name as described in this document. 73 The goal of COMPRESS is to reduce the bandwidth usage of IMAP. 75 Compared to PPP/MNP compression, COMPRESS offers much better 76 compression efficiency, and can be used together with TLS, SASL 77 encryption, VPNs etc. Compared to TLS compression [TLSCOMP], 78 COMPRESS has the following (dis)advantages: 80 - COMPRESS can be implemented easily by IMAP servers and clients. 81 At present, TLS compression is not widely implemented. In the 82 LEMONADE WG, the general consent is that libraries implementing 83 TLS compression will not be available soon enough for LEMONADE. 85 - IMAP compression efficiency benefits from an API that permits 86 flushing the compressor's dictionary at the right point. This is 88 Internet-draft August 2006 90 practical for COMPRESS, whereas typical TLS libraries don't 91 currently allow that. 93 - When a TLS librarly implements compression, all protocols that use 94 TLS automatically are compressed (in LEMONADE's case, SMTP, IMAP, 95 and some notification protocol), whereas COMPRESS is specific to 96 IMAP. 98 In order to increase interoperation, it is desirable to have as few 99 different compression algorithms as possible, so this document 100 specifies only one. The [DEFLATE] algorithm is standard, widely 101 available, unencumbered by patents and fairly efficient, so it is 102 the only algorithm defined by this document. 104 The extension adds one new command (COMPRESS) and no new responses. 106 3. The COMPRESS Command 108 Arguments: Name of compression mechanism: "DEFLATE". 110 Responses: None 112 Result: OK The server will compress its responses and expects the 113 client to compress its commands. 114 NO The server doesn't support the requested mechanism. 115 BAD Command unknown, invalid argument, or COMPRESS already 116 active. 118 The COMPRESS command instructs the server to use the named 119 compression mechanism ("DEFLATE" is the only one defined) for all 120 commands and/or responses after COMPRESS. 122 The client MUST NOT send any further commands until it has seen the 123 result of COMPRESS. If the response was OK, the client MUST compress 124 starting with the first command after COMPRESS. If the server 125 response was BAD or NO, the client MUST NOT turn on compression. 127 If the server issues an OK response, the server MUST compress 128 starting with the first response after the CRLF ending the OK 129 response. (Responses issued by the server before the OK response 130 will, of course, still be uncompressed.) If the server issues a BAD 131 or NO respnose, the server MUST NOT turn on compression. 133 For DEFLATE (as for many other compression mechanisms), the 134 compressor can trade speed against quality. When decompressing 135 there isn't much of a tradeoff. Consequently, the client and server 136 are both free to pick the best reasonable rate of compression for 138 Internet-draft August 2006 140 the data they send. 142 When COMPRESS is combined with TLS or [SASL] layers, the order of 143 processing data to be sent SHALL be to first COMPRESS, then SASL, 144 and finally TLS. When receiving data, the processing order MUST be 145 reversed. This ensures that data is compressed before it is 146 encrypted, independent of the order in which the client issues 147 COMPRESS, AUTHENTICATE, and STARTTLS. 149 The following example illustrates how commands and responses are 150 compressed during a simple login sequence: 152 S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE] 153 C: a starttls 154 S: a OK TLS active 156 From this point on, everything is encrypted. 158 C: b compress deflate 159 S: b OK DEFLATE active 161 From this point on, everything is compressed before being 162 encrypted. 164 C: c login arnt tnra 165 S: c OK Logged in as arnt 167 4. Compression Efficiency 169 This section is informative, not normative. 171 IMAP poses some unusual problems for a compression layer. 173 Upstream is fairly simple. Most IMAP clients send the same few 174 commands again and again, so any compression algorith which can 175 exploit repetition works efficiently. The APPEND command is an 176 exception; clients which send many APPEND commands may want to 177 surround large literals with flushes in the same way as is 178 recommended for servers later in this section. 180 Downstream has the unusual property that several kinds of data are 181 sent, confusing all dictionary-based compression algorithms. 183 One type is IMAP responses. These are highly compressible; zlib 184 using its least CPU-intensive setting compresses typical responses 185 to 25-40% of their original size. 187 Internet-draft August 2006 189 Another is email headers. These are equally compressible, and 190 benefit from using the same dictionary as the IMAP responses. 192 A third is email body text. Text is usually fairly short and 193 includes much ASCII, so the same compression dictionary will do a 194 good job here, too. When multiple messages in the same thread are 195 read at the same time, quoted lines etc. can often be compressed 196 almost to zero. 198 Finally, attachments (non-text email bodies) are transmitted, either 199 in [BINARY] form or encoded with base-64. 201 When attachments are retrieved in [BINARY] form, DEFLATE may be able 202 to compress them, but the format of the attachment is usually not 203 IMAP-like, so the dictionary built while compressing IMAP does not 204 help. The compressor has to adapt its dictionary from IMAP to the 205 attachment's format, and then back. A few file formats aren't 206 compressible at all using deflate, e.g. .gz, .zip and .jpg files. 208 When attachments are retrieved in base-64 form, the same problems 209 apply, but the base-64 encoding adds another problem. 8-bit 210 compression algorithms such as deflate work well on 8-bit file 211 formats, however base-64 turns a file into something resembling 212 6-bit bytes, hiding most of the 8-bit file format from the 213 compressor. 215 When using the zlib library (see [DEFLATE]), the functions 216 deflateInit2(), deflate(), inflateInit2() and inflate() suffice to 217 implement this extension. The windowBits value must be in the range 218 -8 to -15, or else deflateInit2() uses the wrong format. 219 deflateParams() can be used to improve compression rate and resource 220 use. 222 A client can improve downstream compression by implementing [BINARY] 223 and using FETCH BINARY instead of FETCH BODY. In the author's 224 experience, the improvement ranges from 5% to 40% depending on the 225 attachment being downloaded. 227 A server can improve downstream compression if it hints to the 228 compressor that the data type is about to change strongly, e.g. by 229 sending a Z_FULL_FLUSH at the start and end of large non-text 230 literals (before and after '*CHAR8' in the definition of literal in 231 RFC 3501, page 86). Small literals are best left alone. 233 A server can improve the CPU efficiency both of the server and the 234 client if it adjusts the compression level (e.g. using the 235 deflateParams() function in zlib) at these points. A very simple 236 strategy is to change the level to 0 to at the start of a literal 238 Internet-draft August 2006 240 provided the first two bytes are either 0x1F 0x8B (as in deflate- 241 compressed files) or 0xFF 0xD8 (JPEG), and to keep it at 1-5 the 242 rest of the time. 244 Note that when using TLS, compression may actually decrease the CPU 245 usage, depending on which algorithms are used in TLS. This is 246 because fewer bytes need to be encrypted, and encryption is 247 generally more expensive than compression. 249 5. Formal Syntax 251 The following syntax specification uses the Augmented Backus-Naur 252 Form (ABNF) notation as specified in [ABNF]. Non-terminals 253 referenced but not defined below are as defined by [ABNF] (SP, CRLF) 254 or [IMAP] (all others). 256 Except as noted otherwise, all alphabetic characters are case- 257 insensitive. The use of upper or lower case characters to define 258 token strings is for editorial clarity only. Implementations MUST 259 accept these strings in a case-insensitive fashion. 261 command-any =/ compress 263 compress = "COMPRESS" SP algorithm 265 capability =/ "COMPRESS=" algorithm 266 ;; multiple COMPRESS capabilities allowed 268 algorithm = "DEFLATE" 270 Note that due the syntax of capability names, future algorithm names 271 must be atoms. 273 6. Security Considerations 275 As for [TLSCOMP] RFC 3749. 277 7. IANA Considerations 279 The IANA is requested to add COMPRESS=DEFLATE the list of IMAP 280 extensions. 282 Note to IANA: This RFC does not specify the creation of a registry 283 for compression mechanisms. The current feeling of the IMAP 284 community is that is is unlikely that another compression mechanism 286 Internet-draft August 2006 288 algorithm will be added in the future. However, if this RFC is 289 extended in the future by another RFC, and another compression is 290 added at that time, it would then be appropriate to create a 291 registry. 293 8. Acknowledgements 295 Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther, 296 Randall Gellens, Tony Hansen, Stephane Maes, Alexey Melnikov, Lyndon 297 Nerenberg and Zoltan Ordogh have all helped with this document. 299 The author would also like to thank various people in the rooms at 300 meetings, whose help is real, but not reflected in the author's 301 mailbox. 303 9. References 305 9.1. Normative References 307 [ABNF] Crocker, Overell, "Augmented BNF for Syntax 308 Specifications: ABNF", RFC 4234, Brandenburg 309 Internetworking, Demon Internet Ltd, October 2005. 311 [IMAP] Crispin, "Internet Message Access Protocol - Version 312 4rev1", RFC 3501, University of Washington, June 2003. 314 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 315 Requirement Levels", RFC 2119, Harvard University, March 316 1997. 318 [DEFLATE] Deutsch, "DEFLATE Compressed Data Format Specification 319 version 1.3", RFC 1951, Aladdin Enterprises, May 1996. 321 9.2. Informative References 323 [TLSCOMP] Hollenbeck, "Transport Layer Security Protocol 324 Compression Methods", RFC 3749, VeriSign, May 2004. 326 [SASL] Melnikov, Zeilenga, "Simple Authentication and Security 327 Layer (SASL)", RFC 4422, Isode Limited, June 2006 329 [BINARY] Nerenberg, "IMAP4 Binary Content Extension", Orthanc 331 Internet-draft August 2006 333 Systems, April 2003. 335 10. Author's Address 337 Arnt Gulbrandsen 338 Oryx Mail Systems GmbH 339 Schweppermannstr. 8 340 D-81671 Muenchen 341 Germany 343 Fax: +49 89 4502 9758 345 Email: arnt@oryx.com 347 11. Open Issues 349 What text and numbers are needed wrt. compression levels? A bit of 350 solid information is not amiss. 352 Intellectual Property Statement 354 The IETF takes no position regarding the validity or scope of any 355 Intellectual Property Rights or other rights that might be claimed 356 to pertain to the implementation or use of the technology described 357 in this document or the extent to which any license under such 358 rights might or might not be available; nor does it represent that 359 it has made any independent effort to identify any such rights. 360 Information on the procedures with respect to rights in RFC 361 documents can be found in BCP 78 and BCP 79. 363 Copies of IPR disclosures made to the IETF Secretariat and any 364 assurances of licenses to be made available, or the result of an 365 attempt made to obtain a general license or permission for the use 366 of such proprietary rights by implementers or users of this 367 specification can be obtained from the IETF on-line IPR repository 368 at http://www.ietf.org/ipr. 370 The IETF invites any interested party to bring to its attention any 371 copyrights, patents or patent applications, or other proprietary 372 rights that may cover technology that may be required to implement 373 this standard. Please address the information to the IETF at ietf- 374 ipr@ietf.org. 376 Internet-draft August 2006 378 Copyright Statement 380 Copyright (C) The Internet Society (2006). 382 This document is subject to the rights, licenses and restrictions 383 contained in BCP 78, and except as set forth therein, the authors 384 retain all their rights. 386 Disclaimer of Validity 388 This document and the information contained herein are provided on 389 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 390 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 391 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 392 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 393 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 394 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 396 Acknowledgment 398 Funding for the RFC Editor function is currently provided by the 399 Internet Society.