idnits 2.17.00 (12 Aug 2021) /tmp/idnits15261/draft-ietf-lemonade-compress-03.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 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 377. ** 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 Extension 6 draft-ietf-lemonade-compress-03.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 Table of Contents 41 1. Conventions Used in This Document . . . . . . . . . . . . . . 2 42 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 43 3. The COMPRESS Command . . . . . . . . . . . . . . . . . . . . . 3 45 Internet-draft August 2006 47 4. Compression Efficiency . . . . . . . . . . . . . . . . . . . . 4 48 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 49 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 50 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 51 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 52 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 54 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 55 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 56 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 1. Conventions Used in This Document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 63 Formal syntax is defined by [ABNF] as modified by [IMAP]. 65 In the example, "C:" and "S:" indicate lines sent by the client and 66 server respectively. 68 2. Introduction and Overview 70 A server which supports the COMPRESS extension indicates this with 71 one or more capability names consisting of "COMPRESS=" followed by a 72 supported compression algorithm name as described in this document. 74 The goal of COMPRESS is to reduce the bandwidth usage of IMAP. 76 Compared to PPP/MNP compression, COMPRESS offers much better 77 compression efficiency, and can be used together with TLS, SASL 78 encryption, VPNs etc. Compared to TLS compression [TLSCOMP], 79 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 consent is that libraries implementing 84 TLS compression will not be available soon enough for LEMONADE. 86 - IMAP compression efficiency benefits from an API that permits 87 flushing the compressor's dictionary at the right point. This is 88 practical for COMPRESS, whereas typical TLS libraries don't 89 currently allow that. 91 Internet-draft August 2006 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. 103 The extension adds one new command (COMPRESS) and no new responses. 105 3. The COMPRESS Command 107 Arguments: Name of compression mechanism: "DEFLATE". 109 Responses: None 111 Result: OK The server will compress its responses and expects the 112 client to compress its commands. 113 NO The server doesn't support the requested mechanism. 114 BAD Command unknown, invalid argument, or COMPRESS already 115 active. 117 The COMPRESS command instructs the server to use the named 118 compression mechanism ("DEFLATE" is the only one defined) for all 119 commands and/or responses after COMPRESS. 121 The client MUST NOT send any commands until it has seen the result 122 of COMPRESS. If the response was OK, the client MUST compress 123 starting with the first command after COMPRESS, and the server MUST 124 compress starting with the first response after the OK. 126 For DEFLATE (as for many other compression mechanisms), the 127 compressor can trade speed against quality. When decompressing 128 there isn't much of a tradeoff. Consequently, the client and server 129 are both free to pick the best reasonable rate of compression for 130 the data they send. 132 If both COMPRESS and STARTTLS and/or a [SASL] security layer are in 133 use, the data should be compressed before it is encrypted (and 134 decrypted before it is decompressed), independent of the order in 135 which the client issues COMPRESS, AUTHENTICATE and STARTTLS. 137 The following example illustrates how commands and responses are 138 compressed during a simple login sequence: 140 Internet-draft August 2006 142 S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE] 143 C: a starttls 144 S: a OK TLS active 146 From this point on, everything is encrypted. 148 C: b compress deflate 149 S: b OK DEFLATE active 151 From this point on, everything is compressed before being 152 encrypted. 154 C: c login arnt tnra 155 S: c OK Logged in as arnt 157 4. Compression Efficiency 159 This section is informative, not normative. 161 IMAP poses some unusual problems for a compression layer. 163 Upstream is fairly simple. Most IMAP clients send the same few 164 commands again and again, so any compression algorith which can 165 exploit repetition works efficiently. The APPEND command is an 166 exception; clients which send many APPEND commands may want to send 167 flushes in the same way that servers do. 169 Downstream has the unusual property that several kinds of data are 170 sent, confusing all dictionary-based compression algorithms. 172 One type is IMAP responses. These are highly compressible; zlib 173 using its least CPU-intensive setting compresses typical responses 174 to 25-40% of their original size. 176 Another is email headers. These are equally compressible, and 177 benefit from using the same dictionary as the IMAP responses. 179 A third is email body text. Text is usually fairly short and 180 includes much ASCII, so the same compression dictionary will do a 181 good job here, too. When multiple messages in the same thread are 182 read at the same time, quoted lines etc. can often be compressed 183 almost to zero. 185 Finally, attachments (non-text email bodies) are transmitted, either 186 in [BINARY] form or encoded with base-64. 188 Internet-draft August 2006 190 When attachments are retrieved in [BINARY] form, DEFLATE may be able 191 to compress them, but the format of the attachment is usually not 192 IMAP-like, so the dictionary built while compressing IMAP does not 193 help. The compressor has to adapt its dictionary from IMAP to the 194 attachment's format, and then back. A few file formats aren't 195 compressible at all using deflate, e.g. .gz, .zip and .jpg files. 197 When attachments are retrieved in base-64 form, the same problems 198 apply, but the base-64 encoding adds another problem. 8-bit 199 compression algorithms such as deflate work well on 8-bit file 200 formats, however base-64 turns a file into something resembling 201 6-bit bytes, hiding most of the 8-bit file format from the 202 compressor. 204 When using the zlib library (see [DEFLATE]), the functions 205 deflateInit2(), deflate(), inflateInit2() and inflate() suffice to 206 implement this extension. deflateParams() can be used to improve 207 compression rate and resource use. 209 A client can improve downstream compression by implementing [BINARY] 210 and using FETCH BINARY instead of FETCH BODY. In the author's 211 experience, the improvement ranges from 5% to 40% depending on the 212 attachment being downloaded. 214 A server can improve downstream compression if it hints to the 215 compressor that the data type is about to change strongly, e.g. by 216 sending a Z_FULL_FLUSH at the start and end of large non-text 217 literals (before and after '*CHAR8' in the definition of literal in 218 RFC 3501, page 86). Small literals are best left alone. 220 A server can improve the CPU efficiency both of the server and the 221 client if it adjusts the compression level (e.g. using the 222 deflateParams() function in zlib) at these points. A very simple 223 strategy is to change the level to 0 to at the start of a literal 224 provided the first two bytes are either 0x1F 0x8B (as in deflate- 225 compressed files) or 0xFF 0xD8 (JPEG), and to keep it at 1-5 the 226 rest of the time. 228 Note that when using TLS, compression may actually decrease the CPU 229 usage, depending on which algorithms are used in TLS. This is 230 because fewer bytes need to be encrypted, and encryption is 231 generally more expensive than compression. 233 5. Formal Syntax 235 The following syntax specification uses the Augmented Backus-Naur 236 Form (ABNF) notation as specified in [ABNF]. Non-terminals 238 Internet-draft August 2006 240 referenced but not defined below are as defined by [ABNF] (SP, CRLF) 241 or [IMAP] (all others). 243 Except as noted otherwise, all alphabetic characters are case- 244 insensitive. The use of upper or lower case characters to define 245 token strings is for editorial clarity only. Implementations MUST 246 accept these strings in a case-insensitive fashion. 248 command-any =/ compress 250 compress = "COMPRESS" SP algorithm 252 capability =/ "COMPRESS=" algorithm 253 ;; multiple COMPRESS capabilities allowed 255 algorithm = "DEFLATE" 257 Note that due the syntax of capability means, future algorithm names 258 must be atoms. 260 6. Security Considerations 262 As for [TLSCOMP] RFC 3749. 264 7. IANA Considerations 266 The IANA is requested to add COMPRESS=... to the list of IMAP 267 extensions. 269 The IANA is requested to maintain one new registry: IMAP Compression 270 Algorithms. The registry's purpose is to register compression 271 algorithms that may be used with this extension. New IMAP 272 algorithms MUST be defined in a standards track or IESG approved 273 experimental RFC. New IMAP compression algorithms MUST include the 274 following information as part of their definition: 276 algorithm identifier 277 standard commands affected 278 specification reference 279 discussion 281 This registry is available at URL [RFC-EDITOR NOTE: please insert 282 URL of registry] 284 One IMAP compression algorithm is defined in this document, with the 285 following registration definition: 287 Internet-draft August 2006 289 algorithm identifier: DEFLATE 290 standard commands affected: none 291 specification reference: RFC 1951 and XXXX 292 discussion: see RFC XXXX 294 [RFC-EDITOR NOTE: change XXXX to this RFC number] 296 8. Acknowledgements 298 Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther, 299 Randall Gellens, Tony Hansen, Alexey Melnikov, Lyndon Nerenberg and 300 Zoltan Ordogh have all helped with this document. 302 The author would also like to thank various people in the rooms at 303 meetings, whose help is real, but not reflected in the author's 304 mailbox. 306 9. References 308 9.1. Normative References 310 [ABNF] Crocker, Overell, "Augmented BNF for Syntax 311 Specifications: ABNF", RFC 4234, Brandenburg 312 Internetworking, Demon Internet Ltd, October 2005. 314 [IMAP] Crispin, "Internet Message Access Protocol - Version 315 4rev1", RFC 3501, University of Washington, June 2003. 317 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 318 Requirement Levels", RFC 2119, Harvard University, March 319 1997. 321 [DEFLATE] Deutsch, "DEFLATE Compressed Data Format Specification 322 version 1.3", RFC 1951, Aladdin Enterprises, May 1996. 324 9.2. Informative References 326 [TLSCOMP] Hollenbeck, "Transport Layer Security Protocol 327 Compression Methods", RFC 3749, VeriSign, May 2004. 329 [SASL] A. Melnikov, K. Zeilenga, "Simple Authentication and 330 Security Layer (SASL)", RFC 4422, Isode Limited, June 331 2006 333 Internet-draft August 2006 335 [BINARY] Nerenberg, "IMAP4 Binary Content Extension", Orthanc 336 Systems, April 2003. 338 10. Author's Address 340 Arnt Gulbrandsen 341 Oryx Mail Systems GmbH 342 Schweppermannstr. 8 343 D-81671 Muenchen 344 Germany 346 Fax: +49 89 4502 9758 348 Email: arnt@oryx.com 350 11. Open Issues 352 What text and numbers are needed wrt. compression levels? A bit of 353 solid information is not amiss. 355 Intellectual Property Statement 357 The IETF takes no position regarding the validity or scope of any 358 Intellectual Property Rights or other rights that might be claimed 359 to pertain to the implementation or use of the technology described 360 in this document or the extent to which any license under such 361 rights might or might not be available; nor does it represent that 362 it has made any independent effort to identify any such rights. 363 Information on the procedures with respect to rights in RFC 364 documents can be found in BCP 78 and BCP 79. 366 Copies of IPR disclosures made to the IETF Secretariat and any 367 assurances of licenses to be made available, or the result of an 368 attempt made to obtain a general license or permission for the use 369 of such proprietary rights by implementers or users of this 370 specification can be obtained from the IETF on-line IPR repository 371 at http://www.ietf.org/ipr. 373 The IETF invites any interested party to bring to its attention any 374 copyrights, patents or patent applications, or other proprietary 375 rights that may cover technology that may be required to implement 376 this standard. Please address the information to the IETF at ietf- 377 ipr@ietf.org. 379 Internet-draft August 2006 381 Copyright Statement 383 Copyright (C) The Internet Society (2006). 385 This document is subject to the rights, licenses and restrictions 386 contained in BCP 78, and except as set forth therein, the authors 387 retain all their rights. 389 Disclaimer of Validity 391 This document and the information contained herein are provided on 392 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 393 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 394 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 395 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 396 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 397 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 399 Acknowledgment 401 Funding for the RFC Editor function is currently provided by the 402 Internet Society.