idnits 2.17.00 (12 Aug 2021) /tmp/idnits12074/draft-ietf-lemonade-compress-04.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 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 368. ** 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 (September 2006) is 5726 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 September 2006 5 The IMAP COMPRESS Extension 6 draft-ietf-lemonade-compress-04.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 If both COMPRESS and STARTTLS and/or a [SASL] security layer are in 143 use, the data should be compressed before it is encrypted (and 144 decrypted before it is decompressed), independent of the order in 145 which the client issues COMPRESS, AUTHENTICATE and STARTTLS. 147 The following example illustrates how commands and responses are 148 compressed during a simple login sequence: 150 S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE] 151 C: a starttls 152 S: a OK TLS active 154 From this point on, everything is encrypted. 156 C: b compress deflate 157 S: b OK DEFLATE active 159 From this point on, everything is compressed before being 160 encrypted. 162 C: c login arnt tnra 163 S: c OK Logged in as arnt 165 4. Compression Efficiency 167 This section is informative, not normative. 169 IMAP poses some unusual problems for a compression layer. 171 Upstream is fairly simple. Most IMAP clients send the same few 172 commands again and again, so any compression algorith which can 173 exploit repetition works efficiently. The APPEND command is an 174 exception; clients which send many APPEND commands may want to 175 surround large literals with flushes in the same way as is 176 recommended for server below. 178 Downstream has the unusual property that several kinds of data are 179 sent, confusing all dictionary-based compression algorithms. 181 One type is IMAP responses. These are highly compressible; zlib 182 using its least CPU-intensive setting compresses typical responses 183 to 25-40% of their original size. 185 Another is email headers. These are equally compressible, and 186 benefit from using the same dictionary as the IMAP responses. 188 Internet-draft August 2006 190 A third is email body text. Text is usually fairly short and 191 includes much ASCII, so the same compression dictionary will do a 192 good job here, too. When multiple messages in the same thread are 193 read at the same time, quoted lines etc. can often be compressed 194 almost to zero. 196 Finally, attachments (non-text email bodies) are transmitted, either 197 in [BINARY] form or encoded with base-64. 199 When attachments are retrieved in [BINARY] form, DEFLATE may be able 200 to compress them, but the format of the attachment is usually not 201 IMAP-like, so the dictionary built while compressing IMAP does not 202 help. The compressor has to adapt its dictionary from IMAP to the 203 attachment's format, and then back. A few file formats aren't 204 compressible at all using deflate, e.g. .gz, .zip and .jpg files. 206 When attachments are retrieved in base-64 form, the same problems 207 apply, but the base-64 encoding adds another problem. 8-bit 208 compression algorithms such as deflate work well on 8-bit file 209 formats, however base-64 turns a file into something resembling 210 6-bit bytes, hiding most of the 8-bit file format from the 211 compressor. 213 When using the zlib library (see [DEFLATE]), the functions 214 deflateInit2(), deflate(), inflateInit2() and inflate() suffice to 215 implement this extension. The windowBits value must be in the range 216 -8 to -15, or else deflateInit2() uses the wrong format. 217 deflateParams() can be used to improve compression rate and resource 218 use. 220 A client can improve downstream compression by implementing [BINARY] 221 and using FETCH BINARY instead of FETCH BODY. In the author's 222 experience, the improvement ranges from 5% to 40% depending on the 223 attachment being downloaded. 225 A server can improve downstream compression if it hints to the 226 compressor that the data type is about to change strongly, e.g. by 227 sending a Z_FULL_FLUSH at the start and end of large non-text 228 literals (before and after '*CHAR8' in the definition of literal in 229 RFC 3501, page 86). Small literals are best left alone. 231 A server can improve the CPU efficiency both of the server and the 232 client if it adjusts the compression level (e.g. using the 233 deflateParams() function in zlib) at these points. A very simple 234 strategy is to change the level to 0 to at the start of a literal 235 provided the first two bytes are either 0x1F 0x8B (as in deflate- 236 compressed files) or 0xFF 0xD8 (JPEG), and to keep it at 1-5 the 237 rest of the time. 239 Internet-draft August 2006 241 Note that when using TLS, compression may actually decrease the CPU 242 usage, depending on which algorithms are used in TLS. This is 243 because fewer bytes need to be encrypted, and encryption is 244 generally more expensive than compression. 246 5. Formal Syntax 248 The following syntax specification uses the Augmented Backus-Naur 249 Form (ABNF) notation as specified in [ABNF]. Non-terminals 250 referenced but not defined below are as defined by [ABNF] (SP, CRLF) 251 or [IMAP] (all others). 253 Except as noted otherwise, all alphabetic characters are case- 254 insensitive. The use of upper or lower case characters to define 255 token strings is for editorial clarity only. Implementations MUST 256 accept these strings in a case-insensitive fashion. 258 command-any =/ compress 260 compress = "COMPRESS" SP algorithm 262 capability =/ "COMPRESS=" algorithm 263 ;; multiple COMPRESS capabilities allowed 265 algorithm = "DEFLATE" 267 Note that due the syntax of capability names, future algorithm names 268 must be atoms. 270 6. Security Considerations 272 As for [TLSCOMP] RFC 3749. 274 7. IANA Considerations 276 The IANA is requested to add COMPRESS=DEFLATE the list of IMAP 277 extensions. 279 Note to IANA: This RFC does not specify the creation of a registry 280 for compression mechanisms. The current feeling of the IMAP 281 community is that is is unlikely that another compression algorithm 282 will be added in the future. However, if this RFC is extended in the 283 future by another RFC, and another compression is added at that 284 time, it would then be appropriate to create a registry. 286 Internet-draft August 2006 288 8. Acknowledgements 290 Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther, 291 Randall Gellens, Tony Hansen, Alexey Melnikov, Lyndon Nerenberg and 292 Zoltan Ordogh have all helped with this document. 294 The author would also like to thank various people in the rooms at 295 meetings, whose help is real, but not reflected in the author's 296 mailbox. 298 9. References 300 9.1. Normative References 302 [ABNF] Crocker, Overell, "Augmented BNF for Syntax 303 Specifications: ABNF", RFC 4234, Brandenburg 304 Internetworking, Demon Internet Ltd, October 2005. 306 [IMAP] Crispin, "Internet Message Access Protocol - Version 307 4rev1", RFC 3501, University of Washington, June 2003. 309 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 310 Requirement Levels", RFC 2119, Harvard University, March 311 1997. 313 [DEFLATE] Deutsch, "DEFLATE Compressed Data Format Specification 314 version 1.3", RFC 1951, Aladdin Enterprises, May 1996. 316 9.2. Informative References 318 [TLSCOMP] Hollenbeck, "Transport Layer Security Protocol 319 Compression Methods", RFC 3749, VeriSign, May 2004. 321 [SASL] Melnikov, Zeilenga, "Simple Authentication and Security 322 Layer (SASL)", RFC 4422, Isode Limited, June 2006 324 [BINARY] Nerenberg, "IMAP4 Binary Content Extension", Orthanc 325 Systems, April 2003. 327 Internet-draft August 2006 329 10. Author's Address 331 Arnt Gulbrandsen 332 Oryx Mail Systems GmbH 333 Schweppermannstr. 8 334 D-81671 Muenchen 335 Germany 337 Fax: +49 89 4502 9758 339 Email: arnt@oryx.com 341 11. Open Issues 343 What text and numbers are needed wrt. compression levels? A bit of 344 solid information is not amiss. 346 Intellectual Property Statement 348 The IETF takes no position regarding the validity or scope of any 349 Intellectual Property Rights or other rights that might be claimed 350 to pertain to the implementation or use of the technology described 351 in this document or the extent to which any license under such 352 rights might or might not be available; nor does it represent that 353 it has made any independent effort to identify any such rights. 354 Information on the procedures with respect to rights in RFC 355 documents can be found in BCP 78 and BCP 79. 357 Copies of IPR disclosures made to the IETF Secretariat and any 358 assurances of licenses to be made available, or the result of an 359 attempt made to obtain a general license or permission for the use 360 of such proprietary rights by implementers or users of this 361 specification can be obtained from the IETF on-line IPR repository 362 at http://www.ietf.org/ipr. 364 The IETF invites any interested party to bring to its attention any 365 copyrights, patents or patent applications, or other proprietary 366 rights that may cover technology that may be required to implement 367 this standard. Please address the information to the IETF at ietf- 368 ipr@ietf.org. 370 Internet-draft August 2006 372 Copyright Statement 374 Copyright (C) The Internet Society (2006). 376 This document is subject to the rights, licenses and restrictions 377 contained in BCP 78, and except as set forth therein, the authors 378 retain all their rights. 380 Disclaimer of Validity 382 This document and the information contained herein are provided on 383 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 384 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 385 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 386 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 387 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 388 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 390 Acknowledgment 392 Funding for the RFC Editor function is currently provided by the 393 Internet Society.