idnits 2.17.1 draft-gulbrandsen-imap-deflate-02.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 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 217. ** 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 : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 6 characters in excess of 72. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 2006) is 6644 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) == Unused Reference: 'STARTTLS' is defined on line 175, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Downref: Normative reference to an Informational RFC: RFC 1951 (ref. 'DEFLATE') Summary: 8 errors (**), 0 flaws (~~), 4 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 draft-gulbrandsen-imap-deflate-02.txt February 2006 5 The IMAP COMPRESS=DEFLATE extension 7 Status of this Memo 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware 11 have been or will be disclosed, and any of which he or she becomes 12 aware will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 26 Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society 2006. 33 Abstract 35 The COMPRESS=DEFLATE extension allows an IMAP connection to be 36 compressed using the DEFLATE algorithm, such that effective 37 compression is available even when TLS is used. 39 Conventions Used in This Document 41 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 42 NOT", and "MAY" in this document are to be interpreted as described 43 in "Key words for use in RFCs to Indicate Requirement Levels" 45 Internet-draft February 2006 47 [KEYWORDS]. Formal syntax is defined by [ABNF] as modified by 48 [IMAP]. 50 In the example, "C:" and "S:" indicate lines sent by the client and 51 server respectively. 53 Introduction and Overview 55 An IMAP server that supports this extension announces 56 "COMPRESS=DEFLATE" as one of its capabilities. 58 The goal of COMPRESS=DEFLATE is to reduce the bandwidth usage of 59 IMAP. On regular IMAP connections, the PPP or MNP compression used 60 with many low-bandwidth links compresses IMAP well. However, when 61 TLS is used, PPP/MNP compression is ineffective. TLS too may provide 62 compression, but few or no implementations do so in practice 63 (perhaps for patent reasons). 65 In order to increase interoperation, it is desirable to have as few 66 different compression algorithms as possible, so this document 67 specifies only one. The DEFLATE algorithm is standard, widely 68 available, unencumbered by patents and fairly efficient. Hopefully 69 it will not be necessary to define additional algorithms. 71 The extension adds one new command (COMPRESS) and no new responses. 73 The COMPRESS Command 75 Arguments: Name of compression mechanism: "DEFLATE". 77 Responses: None 79 Result: OK The server will compress its responses and expects the 80 client to compress its commands. 81 NO The connection already is compressed, or the server doesn't 82 support the requested mechanism. 83 BAD Command unknown or invalid argument. 85 The COMPRESS command instructs the server to use the named 86 compression mechanism ("DEFLATE" is the only one defined) for future 87 commands and responses. 89 For DEFLATE (as for many other compression mechanisms), the 90 compressor can trade speed against quality. When decompressing 91 there isn't much of a tradeoff. Consequently, the client and server 92 are both free to pick the best reasonable rate of compression for 94 Internet-draft February 2006 96 the data they send. 98 The client MUST NOT send additional commands until it has seen the 99 result of COMPRESS. 101 If both TLS and COMPRESS are in use, the data should be compressed 102 before it is encrypted (and decrypted before it is decompressed). 104 Example 106 This example shows a simple login sequence. The client uses TLS for 107 privacy and [DEFLATE] for compression. 109 S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE] 110 C: a starttls 111 S: a OK 112 C: b compress deflate 113 S: b OK 114 C: c login arnt tnra 115 S: c OK 117 Implementation Notes 119 When using the zlib library (see [DEFLATE]), the functions 120 deflateInit(), deflate(), inflateInit() and inflate() suffice to 121 implement this extension. 123 Note that when using TLS, compression may actually decrease the CPU 124 usage, depending on which algorithms are used in TLS. This is 125 because fewer bytes need to be encrypted, and encryption is 126 generally more expensive than compression. 128 Formal Syntax 130 The following syntax specification uses the Augmented Backus-Naur 131 Form (ABNF) notation as specified in [ABNF]. Non-terminals 132 referenced but not defined below are as defined by [ABNF] (SP, CRLF) 133 or [IMAP] (all others). 135 Except as noted otherwise, all alphabetic characters are case- 136 insensitive. The use of upper or lower case characters to define 137 token strings is for editorial clarity only. Implementations MUST 138 accept these strings in a case-insensitive fashion. 140 command-any =/ compress 142 Internet-draft February 2006 144 compress = "COMPRESS" SP astring 146 Security considerations 148 (As for [TLSCOMP] RFC 3749.) 150 IANA considerations 152 The IANA is requested to add COMPRESS=DEFLATE to the list of IMAP 153 extensions. 155 Credits 157 (Your name here :) 159 Normative References 161 [ABNF] Crocker, Overell, "Augmented BNF for Syntax 162 Specifications: ABNF", RFC 2234, Internet Mail 163 Consortium, Demon Internet Ltd, November 1997. 165 [IMAP] Crispin, "Internet Message Access Protocol - Version 166 4rev1", RFC 3501, University of Washington, June 2003. 168 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 169 Requirement Levels", RFC 2119, Harvard University, March 170 1997. 172 [DEFLATE] Deutsch, "DEFLATE Compressed Data Format Specification 173 version 1.3", RFC 1951, Aladdin Enterprises, May 1996. 175 [STARTTLS] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC 176 2595, June 1999. 178 Informative References 180 [TLSCOMP] Hollenbeck, "Transport Layer Security Protocol 181 Compression Methods", RFC 3749, VeriSign, May 2004. 183 Internet-draft February 2006 185 Author's Address 187 Arnt Gulbrandsen 188 Oryx Mail Systems GmbH 189 Schweppermannstr. 8 190 D-81671 Muenchen 191 Germany 193 Fax: +49 89 4502 9758 195 Email: arnt@oryx.com 197 Intellectual Property Statement 199 The IETF takes no position regarding the validity or scope of any 200 Intellectual Property Rights or other rights that might be claimed to 201 pertain to the implementation or use of the technology described in this 202 document or the extent to which any license under such rights might or 203 might not be available; nor does it represent that it has made any 204 independent effort to identify any such rights. Information on the 205 procedures with respect to rights in RFC documents can be found in BCP 78 206 and BCP 79. 208 Copies of IPR disclosures made to the IETF Secretariat and any assurances 209 of licenses to be made available, or the result of an attempt made to 210 obtain a general license or permission for the use of such proprietary 211 rights by implementers or users of this specification can be obtained from 212 the IETF on-line IPR repository at http://www.ietf.org/ipr. 214 The IETF invites any interested party to bring to its attention any 215 copyrights, patents or patent applications, or other proprietary rights 216 that may cover technology that may be required to implement this standard. 217 Please address the information to the IETF at ietf-ipr@ietf.org. 219 Copyright Statement 221 Copyright (C) The Internet Society (2006). 223 This document is subject to the rights, licenses and restrictions 224 contained in BCP 78, and except as set forth therein, the authors retain 225 all their rights. 227 Internet-draft February 2006 229 Disclaimer of Validity 231 This document and the information contained herein are provided on an "AS 232 IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS 233 SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 234 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 235 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 236 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 237 FITNESS FOR A PARTICULAR PURPOSE. 239 Acknowledgment 241 Funding for the RFC Editor function is currently provided by the Internet 242 Society.