idnits 2.17.00 (12 Aug 2021) /tmp/idnits13573/draft-ietf-lemonade-compress-07.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 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 407. ** 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 (January 2007) is 5604 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) ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 January 2007 5 The IMAP COMPRESS Extension 6 draft-ietf-lemonade-compress-07.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 2007. 34 Abstract 36 The COMPRESS extension allows an IMAP connection to be effectively 37 and efficiently compressed. 39 Internet-draft January 2007 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 . . . . . . . . . . . . . . . . . . . . 5 47 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 48 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 49 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 50 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 51 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 52 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 53 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 54 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 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 [RFC2119]. 62 Formal syntax is defined by [RFC4234] as modified by [RFC3501]. 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 compression (see [RFC1962]) and modem-based 76 compression (see [MNP] and [V42BIS]), COMPRESS offers much better 77 compression efficiency. COMPRESS can be used together with TLS 78 [RFC4346], SASL encryption, VPNs etc. Compared to TLS compression 79 [RFC3749], COMPRESS has the following (dis)advantages: 81 - COMPRESS can be implemented easily by IMAP servers and clients. 82 At present, TLS compression is not widely implemented. In the 83 LEMONADE WG, the general consensus is that libraries implementing 84 TLS compression will not be available soon enough for LEMONADE. 86 Internet-draft January 2007 88 - IMAP COMPRESS benefits from an intimate knowledge of the IMAP 89 protocol's state machine, allowing for dynamic and aggressive 90 optimization of the underlying compression algorithm's parameters. 92 - When the TLS layer implements compression, any protocol using that 93 layer can transparently benefit from that compression (e.g. SMTP 94 and IMAP). COMPRESS is specific to IMAP. 96 In order to increase interoperation, it is desirable to have as few 97 different compression algorithms as possible, so this document 98 specifies only one. The DEFLATE algorithm (defined in [RFC1951]) is 99 standard, widely available, unencumbered by patents and fairly 100 efficient, so it is the only algorithm defined by this document. 102 The extension adds one new command (COMPRESS) and no new responses. 104 3. The COMPRESS Command 106 Arguments: Name of compression mechanism: "DEFLATE". 108 Responses: None 110 Result: OK The server will compress its responses and expects the 111 client to compress its commands. 112 NO Compression is already active via another layer. 113 BAD Command unknown, invalid or unknown argument, or COMPRESS 114 already active. 116 The COMPRESS command instructs the server to use the named 117 compression mechanism ("DEFLATE" is the only one defined) for all 118 commands and/or responses after COMPRESS. 120 The client MUST NOT send any further commands until it has seen the 121 result of COMPRESS. If the response was OK, the client MUST compress 122 starting with the first command after COMPRESS. If the server 123 response was BAD or NO, the client MUST NOT turn on compression. 125 If the server responds NO because it knows that the same mechanism 126 is active already (e.g. because TLS has negotiated the same 127 mechanism), it MUST send COMPRESSIONACTIVE as resp-text-code (see 128 [RFC3501] section 7.1), and the resp-text SHOULD say which layer 129 compresses. 131 If the server issues an OK response, the server MUST compress 132 starting immediately after the CRLF which ends the tagged OK 133 response. (Responses issued by the server before the OK response 135 Internet-draft January 2007 137 will, of course, still be uncompressed.) If the server issues a BAD 138 or NO respnose, the server MUST NOT turn on compression. 140 For DEFLATE (as for many other compression mechanisms), the 141 compressor can trade speed against quality. When decompressing 142 there isn't much of a tradeoff. Consequently, the client and server 143 are both free to pick the best reasonable rate of compression for 144 the data they send. 146 When COMPRESS is combined with TLS (see [RFC4346]) or SASL (see 147 [RFC4422]) security layers, the sending order of the three 148 extensions MUST be first COMPRESS, then SASL, and finally TLS. That 149 is, before data is transmitted it is first compressed. Second, if a 150 SASL security layer has been negotiated, the compressed data is then 151 signed and/or encrypted accordingly. Third, if a TLS security layer 152 has been negotiated, the data from the previous step is signed 153 and/or encrypted accordingly. When receiving data, the processing 154 order MUST be reversed. This ensures that before sending, data is 155 compressed before it is encrypted, independent of the order in which 156 the client issues COMPRESS, AUTHENTICATE, and STARTTLS. 158 The following example illustrates how commands and responses are 159 compressed during a simple login sequence: 161 S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE] 162 C: a starttls 163 S: a OK TLS active 165 From this point on, everything is encrypted. 167 C: b compress deflate 168 S: b OK DEFLATE active 170 From this point on, everything is compressed before being 171 encrypted. 173 C: c login arnt tnra 174 S: c OK Logged in as arnt 176 Internet-draft January 2007 178 The following example demonstrates how a server may refuse to 179 compress twice: 181 S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE] 182 C: a starttls 183 S: a OK TLS active 185 From this point on, everything is encrypted, and we assume 186 that TLS negotiation has also enabled TLS compression (see 187 [RFC3749]). 189 C: b compress deflate 190 S: b NO [COMPRESSIONACTIVE] DEFLATE active via TLS 192 4. Compression Efficiency 194 This section is informative, not normative. 196 IMAP poses some unusual problems for a compression layer. 198 Upstream is fairly simple. Most IMAP clients send the same few 199 commands again and again, so any compression algorithm which can 200 exploit repetition works efficiently. The APPEND command is an 201 exception; clients which send many APPEND commands may want to 202 surround large literals with flushes in the same way as is 203 recommended for servers later in this section. 205 Downstream has the unusual property that several kinds of data are 206 sent, confusing all dictionary-based compression algorithms. 208 One type is IMAP responses. These are highly compressible; zlib 209 using its least CPU-intensive setting compresses typical responses 210 to 25-40% of their original size. 212 Another is email headers. These are equally compressible, and 213 benefit from using the same dictionary as the IMAP responses. 215 A third is email body text. Text is usually fairly short and 216 includes much ASCII, so the same compression dictionary will do a 217 good job here, too. When multiple messages in the same thread are 218 read at the same time, quoted lines etc. can often be compressed 219 almost to zero. 221 Finally, attachments (non-text email bodies) are transmitted, either 222 in binary form or encoded with base-64. 224 Internet-draft January 2007 226 When attachments are retrieved in binary form, DEFLATE may be able 227 to compress them, but the format of the attachment is usually not 228 IMAP-like, so the dictionary built while compressing IMAP does not 229 help. The compressor has to adapt its dictionary from IMAP to the 230 attachment's format, and then back. A few file formats aren't 231 compressible at all using deflate, e.g. .gz, .zip and .jpg files. 233 When attachments are retrieved in base-64 form, the same problems 234 apply, but the base-64 encoding adds another problem. 8-bit 235 compression algorithms such as deflate work well on 8-bit file 236 formats, however base-64 turns a file into something resembling 237 6-bit bytes, hiding most of the 8-bit file format from the 238 compressor. 240 When using the zlib library (see [RFC1951]), the functions 241 deflateInit2(), deflate(), inflateInit2() and inflate() suffice to 242 implement this extension. The windowBits value must be in the range 243 -8 to -15, or else deflateInit2() uses the wrong format. 244 deflateParams() can be used to improve compression rate and resource 245 use. 247 A client can improve downstream compression by implementing BINARY 248 (defined in [RFC3516]) and using FETCH BINARY instead of FETCH BODY. 249 In the author's experience, the improvement ranges from 5% to 40% 250 depending on the attachment being downloaded. 252 A server can improve downstream compression if it hints to the 253 compressor that the data type is about to change strongly, e.g. by 254 sending a Z_FULL_FLUSH at the start and end of large non-text 255 literals (before and after '*CHAR8' in the definition of literal in 256 RFC 3501, page 86). Small literals are best left alone. 258 A server can improve the CPU efficiency both of the server and the 259 client if it adjusts the compression level (e.g. using the 260 deflateParams() function in zlib) at these points. A very simple 261 strategy is to change the level to 0 to at the start of a literal 262 provided the first two bytes are either 0x1F 0x8B (as in deflate- 263 compressed files) or 0xFF 0xD8 (JPEG), and to keep it at 1-5 the 264 rest of the time. 266 Note that when using TLS, compression may actually decrease the CPU 267 usage, depending on which algorithms are used in TLS. This is 268 because fewer bytes need to be encrypted, and encryption is 269 generally more expensive than compression. 271 Internet-draft January 2007 273 5. Formal Syntax 275 The following syntax specification uses the Augmented Backus-Naur 276 Form (ABNF) notation as specified in [RFC4234]. This syntax augments 277 the grammar specified in [RFC3501]. [RFC4234] defines SP and 278 [RFC3501] defines command-auth, capability and resp-text-code. 280 Except as noted otherwise, all alphabetic characters are case- 281 insensitive. The use of upper or lower case characters to define 282 token strings is for editorial clarity only. Implementations MUST 283 accept these strings in a case-insensitive fashion. 285 command-auth =/ compress 287 compress = "COMPRESS" SP algorithm 289 capability =/ "COMPRESS=" algorithm 290 ;; multiple COMPRESS capabilities allowed 292 algorithm = "DEFLATE" 294 resp-text-code =/ "COMPRESSIONACTIVE" 296 Note that due the syntax of capability names, future algorithm names 297 must be atoms. 299 6. Security Considerations 301 As for TLS compression [RFC3749]. 303 7. IANA Considerations 305 The IANA is requested to add COMPRESS=DEFLATE the list of IMAP 306 extensions, http://www.iana.org/assignments/imap4-capabilities. 308 Note to IANA: This RFC does not specify the creation of a registry 309 for compression mechanisms. The current feeling of the IMAP 310 community is that is is unlikely that another compression mechanism 311 will be added in the future. However, if this RFC is extended in the 312 future by another RFC, and another compression mechanism is added at 313 that time, it would then be appropriate to create a registry. 315 Internet-draft January 2007 317 8. Acknowledgements 319 Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther, 320 Randall Gellens, Tony Hansen, Stephane Maes, Alexey Melnikov, Lyndon 321 Nerenberg and Zoltan Ordogh have all helped with this document. 323 The author would also like to thank various people in the rooms at 324 meetings, whose help is real, but not reflected in the author's 325 mailbox. 327 9. References 329 9.1. Normative References 331 [RFC1951] Deutsch, "DEFLATE Compressed Data Format Specification 332 version 1.3", RFC 1951, Aladdin Enterprises, May 1996. 334 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 335 Requirement Levels", RFC 2119, Harvard University, March 336 1997. 338 [RFC3501] Crispin, "Internet Message Access Protocol - Version 339 4rev1", RFC 3501, University of Washington, June 2003. 341 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 342 Specifications: ABNF", RFC 4234, Brandenburg 343 Internetworking, Demon Internet Ltd, October 2005. 345 9.2. Informative References 347 [RFC1962] Rand, "The PPP Compression Control Protocol (CCP)", RFC 348 1962, June 1996. 350 [RFC3516] Nerenberg, "IMAP4 Binary Content Extension", RFC 3516, 351 Orthanc Systems, April 2003. 353 [RFC3749] Hollenbeck, "Transport Layer Security Protocol 354 Compression Methods", RFC 3749, VeriSign, May 2004. 356 [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS) 357 Protocol, Version 1.1", RFC 4346, April 2006. 359 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 360 Layer (SASL)", RFC 4422, Isode Limited, June 2006. 362 Internet-draft January 2007 364 [V42BIS] ITU, "V.42bis: Data compression procedures for data 365 circuit-terminating equipment (DCE) using error 366 correction procedures", http://www.itu.int/rec/T-REC- 367 V.42bis, January 1990. 369 [MNP] Gilbert Held, "The Complete Modem Reference", Second 370 Edition, Wiley Professional Computing, ISBN 371 0-471-00852-4, May 1994. 373 10. Author's Address 375 Arnt Gulbrandsen 376 Oryx Mail Systems GmbH 377 Schweppermannstr. 8 378 D-81671 Muenchen 379 Germany 381 Fax: +49 89 4502 9758 383 Email: arnt@oryx.com 385 Intellectual Property Statement 387 The IETF takes no position regarding the validity or scope of any 388 Intellectual Property Rights or other rights that might be claimed 389 to pertain to the implementation or use of the technology described 390 in this document or the extent to which any license under such 391 rights might or might not be available; nor does it represent that 392 it has made any independent effort to identify any such rights. 393 Information on the procedures with respect to rights in RFC 394 documents can be found in BCP 78 and BCP 79. 396 Copies of IPR disclosures made to the IETF Secretariat and any 397 assurances of licenses to be made available, or the result of an 398 attempt made to obtain a general license or permission for the use 399 of such proprietary rights by implementers or users of this 400 specification can be obtained from the IETF on-line IPR repository 401 at http://www.ietf.org/ipr. 403 The IETF invites any interested party to bring to its attention any 404 copyrights, patents or patent applications, or other proprietary 405 rights that may cover technology that may be required to implement 406 this standard. Please address the information to the IETF at ietf- 407 ipr@ietf.org. 409 Internet-draft January 2007 411 Copyright Statement 413 Copyright (C) The Internet Society (2007). 415 This document is subject to the rights, licenses and restrictions 416 contained in BCP 78, and except as set forth therein, the authors 417 retain all their rights. 419 Disclaimer of Validity 421 This document and the information contained herein are provided on 422 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 423 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 424 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 425 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 426 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 427 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 429 Acknowledgment 431 Funding for the RFC Editor function is currently provided by the 432 Internet Society.