idnits 2.17.00 (12 Aug 2021) /tmp/idnits11356/draft-ietf-lemonade-compress-06.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 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 397. ** 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 (November 2006) is 5665 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 November 2006 5 The IMAP COMPRESS Extension 6 draft-ietf-lemonade-compress-06.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 November 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 . . . . . . . . . . . . . . . . . . . . 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/MNP compression, COMPRESS offers much better 76 compression efficiency, and can be used together with TLS [RFC4346], 77 SASL encryption, VPNs etc. Compared to TLS compression [RFC3749], 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 November 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 (defined in [RFC1951]) is 101 standard, widely available, unencumbered by patents and fairly 102 efficient, so it is 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, or 115 the mechanism is already active, 116 BAD Command unknown, invalid argument, or COMPRESS already 117 active. 119 The COMPRESS command instructs the server to use the named 120 compression mechanism ("DEFLATE" is the only one defined) for all 121 commands and/or responses after COMPRESS. 123 The client MUST NOT send any further commands until it has seen the 124 result of COMPRESS. If the response was OK, the client MUST compress 125 starting with the first command after COMPRESS. If the server 126 response was BAD or NO, the client MUST NOT turn on compression. 128 If the server responds NO because it knows that the same mechanism 129 is active already (e.g. because TLS has negotiated the same 130 mechanism), it MUST send COMPRESSIONACTIVE as resp-text-code (see 131 [RFC3501] section 7.1), and the resp-text SHOULD say which layer 132 compresses. 134 If the server issues an OK response, the server MUST compress 135 starting with the first response after the CRLF ending the OK 136 response. (Responses issued by the server before the OK response 138 Internet-draft November 2006 140 will, of course, still be uncompressed.) If the server issues a BAD 141 or NO respnose, the server MUST NOT turn on compression. 143 For DEFLATE (as for many other compression mechanisms), the 144 compressor can trade speed against quality. When decompressing 145 there isn't much of a tradeoff. Consequently, the client and server 146 are both free to pick the best reasonable rate of compression for 147 the data they send. 149 When COMPRESS is combined with TLS (see [RFC4346]) or SASL (see 150 [RFC4422]) security layers, the sending order of the three 151 extensions MUST be first COMPRESS, then SASL, and finally TLS. That 152 is, before data is transmitted it is first compressed. Second, if a 153 SASL security layer has been negotiated, the compressed data is then 154 signed and/or encrypted accordingly. Third, if a TLS security layer 155 has been negotiated, the data from the previous step is signed 156 and/or encrypted accordingly. When receiving data, the processing 157 order MUST be reversed. This ensures that before sending, data is 158 compressed before it is encrypted, independent of the order in which 159 the client issues COMPRESS, AUTHENTICATE, and STARTTLS. 161 The following example illustrates how commands and responses are 162 compressed during a simple login sequence: 164 S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE] 165 C: a starttls 166 S: a OK TLS active 168 From this point on, everything is encrypted. 170 C: b compress deflate 171 S: b OK DEFLATE active 173 From this point on, everything is compressed before being 174 encrypted. 176 C: c login arnt tnra 177 S: c OK Logged in as arnt 179 Internet-draft November 2006 181 The following example demonstrates how a server may refuse to 182 compress twice: 184 S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE] 185 C: a starttls 186 S: a OK TLS active 188 From this point on, everything is encrypted, and we assume 189 that TLS negotiation has also enabled TLS compression (see 190 [RFC3749]). 192 C: b compress deflate 193 S: b NO [COMPRESSIONACTIVE] DEFLATE active via TLS 195 4. Compression Efficiency 197 This section is informative, not normative. 199 IMAP poses some unusual problems for a compression layer. 201 Upstream is fairly simple. Most IMAP clients send the same few 202 commands again and again, so any compression algorith which can 203 exploit repetition works efficiently. The APPEND command is an 204 exception; clients which send many APPEND commands may want to 205 surround large literals with flushes in the same way as is 206 recommended for servers later in this section. 208 Downstream has the unusual property that several kinds of data are 209 sent, confusing all dictionary-based compression algorithms. 211 One type is IMAP responses. These are highly compressible; zlib 212 using its least CPU-intensive setting compresses typical responses 213 to 25-40% of their original size. 215 Another is email headers. These are equally compressible, and 216 benefit from using the same dictionary as the IMAP responses. 218 A third is email body text. Text is usually fairly short and 219 includes much ASCII, so the same compression dictionary will do a 220 good job here, too. When multiple messages in the same thread are 221 read at the same time, quoted lines etc. can often be compressed 222 almost to zero. 224 Finally, attachments (non-text email bodies) are transmitted, either 225 in binary form or encoded with base-64. 227 Internet-draft November 2006 229 When attachments are retrieved in binary form, DEFLATE may be able 230 to compress them, but the format of the attachment is usually not 231 IMAP-like, so the dictionary built while compressing IMAP does not 232 help. The compressor has to adapt its dictionary from IMAP to the 233 attachment's format, and then back. A few file formats aren't 234 compressible at all using deflate, e.g. .gz, .zip and .jpg files. 236 When attachments are retrieved in base-64 form, the same problems 237 apply, but the base-64 encoding adds another problem. 8-bit 238 compression algorithms such as deflate work well on 8-bit file 239 formats, however base-64 turns a file into something resembling 240 6-bit bytes, hiding most of the 8-bit file format from the 241 compressor. 243 When using the zlib library (see [RFC1951]), the functions 244 deflateInit2(), deflate(), inflateInit2() and inflate() suffice to 245 implement this extension. The windowBits value must be in the range 246 -8 to -15, or else deflateInit2() uses the wrong format. 247 deflateParams() can be used to improve compression rate and resource 248 use. 250 A client can improve downstream compression by implementing BINARY 251 (defined in [RFC3516]) and using FETCH BINARY instead of FETCH BODY. 252 In the author's experience, the improvement ranges from 5% to 40% 253 depending on the attachment being downloaded. 255 A server can improve downstream compression if it hints to the 256 compressor that the data type is about to change strongly, e.g. by 257 sending a Z_FULL_FLUSH at the start and end of large non-text 258 literals (before and after '*CHAR8' in the definition of literal in 259 RFC 3501, page 86). Small literals are best left alone. 261 A server can improve the CPU efficiency both of the server and the 262 client if it adjusts the compression level (e.g. using the 263 deflateParams() function in zlib) at these points. A very simple 264 strategy is to change the level to 0 to at the start of a literal 265 provided the first two bytes are either 0x1F 0x8B (as in deflate- 266 compressed files) or 0xFF 0xD8 (JPEG), and to keep it at 1-5 the 267 rest of the time. 269 Note that when using TLS, compression may actually decrease the CPU 270 usage, depending on which algorithms are used in TLS. This is 271 because fewer bytes need to be encrypted, and encryption is 272 generally more expensive than compression. 274 Internet-draft November 2006 276 5. Formal Syntax 278 The following syntax specification uses the Augmented Backus-Naur 279 Form (ABNF) notation as specified in [RFC4234]. [RFC4234] defines SP 280 and [RFC3501] defines command-any, capability and resp-text-code. 282 Except as noted otherwise, all alphabetic characters are case- 283 insensitive. The use of upper or lower case characters to define 284 token strings is for editorial clarity only. Implementations MUST 285 accept these strings in a case-insensitive fashion. 287 command-any =/ compress 289 compress = "COMPRESS" SP algorithm 291 capability =/ "COMPRESS=" algorithm 292 ;; multiple COMPRESS capabilities allowed 294 algorithm = "DEFLATE" 296 resp-text-code =/ "COMPRESSIONACTIVE" 298 Note that due the syntax of capability names, future algorithm names 299 must be atoms. 301 6. Security Considerations 303 As for TLS compression [RFC3749]. 305 7. IANA Considerations 307 The IANA is requested to add COMPRESS=DEFLATE the list of IMAP 308 extensions. 310 Note to IANA: This RFC does not specify the creation of a registry 311 for compression mechanisms. The current feeling of the IMAP 312 community is that is is unlikely that another compression mechanism 313 will be added in the future. However, if this RFC is extended in the 314 future by another RFC, and another compression mechanism is added at 315 that time, it would then be appropriate to create a registry. 317 Internet-draft November 2006 319 8. Acknowledgements 321 Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther, 322 Randall Gellens, Tony Hansen, Stephane Maes, Alexey Melnikov, Lyndon 323 Nerenberg and Zoltan Ordogh have all helped with this document. 325 The author would also like to thank various people in the rooms at 326 meetings, whose help is real, but not reflected in the author's 327 mailbox. 329 9. References 331 9.1. Normative References 333 [RFC1951] Deutsch, "DEFLATE Compressed Data Format Specification 334 version 1.3", RFC 1951, Aladdin Enterprises, May 1996. 336 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 337 Requirement Levels", RFC 2119, Harvard University, March 338 1997. 340 [RFC3501] Crispin, "Internet Message Access Protocol - Version 341 4rev1", RFC 3501, University of Washington, June 2003. 343 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 344 Specifications: ABNF", RFC 4234, Brandenburg 345 Internetworking, Demon Internet Ltd, October 2005. 347 9.2. Informative References 349 [RFC3516] Nerenberg, "IMAP4 Binary Content Extension", RFC 3516, 350 Orthanc Systems, April 2003. 352 [RFC3749] Hollenbeck, "Transport Layer Security Protocol 353 Compression Methods", RFC 3749, VeriSign, May 2004. 355 [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS) 356 Protocol, Version 1.1", RFC 4346, April 2006. 358 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 359 Layer (SASL)", RFC 4422, Isode Limited, June 2006 361 Internet-draft November 2006 363 10. Author's Address 365 Arnt Gulbrandsen 366 Oryx Mail Systems GmbH 367 Schweppermannstr. 8 368 D-81671 Muenchen 369 Germany 371 Fax: +49 89 4502 9758 373 Email: arnt@oryx.com 375 Intellectual Property Statement 377 The IETF takes no position regarding the validity or scope of any 378 Intellectual Property Rights or other rights that might be claimed 379 to pertain to the implementation or use of the technology described 380 in this document or the extent to which any license under such 381 rights might or might not be available; nor does it represent that 382 it has made any independent effort to identify any such rights. 383 Information on the procedures with respect to rights in RFC 384 documents can be found in BCP 78 and BCP 79. 386 Copies of IPR disclosures made to the IETF Secretariat and any 387 assurances of licenses to be made available, or the result of an 388 attempt made to obtain a general license or permission for the use 389 of such proprietary rights by implementers or users of this 390 specification can be obtained from the IETF on-line IPR repository 391 at http://www.ietf.org/ipr. 393 The IETF invites any interested party to bring to its attention any 394 copyrights, patents or patent applications, or other proprietary 395 rights that may cover technology that may be required to implement 396 this standard. Please address the information to the IETF at ietf- 397 ipr@ietf.org. 399 Copyright Statement 401 Copyright (C) The Internet Society (2006). 403 This document is subject to the rights, licenses and restrictions 404 contained in BCP 78, and except as set forth therein, the authors 405 retain all their rights. 407 Internet-draft November 2006 409 Disclaimer of Validity 411 This document and the information contained herein are provided on 412 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 413 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 414 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 415 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 416 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 417 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 419 Acknowledgment 421 Funding for the RFC Editor function is currently provided by the 422 Internet Society.