idnits 2.17.00 (12 Aug 2021) /tmp/idnits14304/draft-ietf-lemonade-compress-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 301. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 18 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 5938 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) == Missing Reference: 'ABNF' is mentioned on line 159, but not defined == Missing Reference: 'ABNFEXTEND' is mentioned on line 162, but not defined == Unused Reference: 'LEMONADEPROFILE' is defined on line 177, but no explicit reference was found in the text == Unused Reference: 'RFC1951' is defined on line 192, but no explicit reference was found in the text -- No information found for draft-ietf-lemonade-profile-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LEMONADEPROFILE' -- No information found for draft-maes-lemonade-mobile-email-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MEMAIL' -- Possible downref: Non-RFC (?) normative reference: ref. 'OMA-ME-RD' -- No information found for draft-maes-lemonade-p-imap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'P-IMAP' ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 February 2006 3 Lemonade 4 Internet Draft: LZIP S. H. Maes 5 Document: draft-ietf-lemonade-compress-00 R. Cromwell 6 (Editors) 8 Expires: August 2006 February 2006 10 COMPRESSION 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Lemonade investigates adding mobile optimizations for the next 41 version of the Lemonade Profile. LZIP addresses this task and 42 provides an extension to allow compression of the exchanged text and 43 binary literals, typically message body parts. 45 Conventions used in this document 46 February 2006 48 In examples, "C:" and "S:" indicate lines sent by the client and 49 server respectively. 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC2119]. 55 An implementation is not compliant if it fails to satisfy one or more 56 of the MUST or REQUIRED level requirements for the protocol(s) it 57 implements. An implementation that satisfies all the MUST or REQUIRED 58 level and all the SHOULD level requirements for a protocol is said to 59 be "unconditionally compliant" to that protocol; one that satisfies 60 all the MUST level requirements but not all the SHOULD level 61 requirements is said to be "conditionally compliant." When 62 describing the general syntax, some definitions are omitted as they 63 are defined in [RFC3501]. 65 Table of Contents 67 Status of this Memo ........................................ 1 68 Copyright Notice............................................ 1 69 Abstract.................................................... 1 70 Conventions used in this document........................... 1 71 Table of Contents........................................... 2 72 1. Introduction............................................. 2 73 2. The CAPABILITY Command................................... 3 74 3. LZIP Commands............................................ 3 75 4. LZIP Response............................................ 3 76 5. Formal Syntax............................................ 4 77 Security Considerations..................................... 4 78 References.................................................. 4 79 Future Work................................................. 5 80 Version History............................................. 5 81 Acknowledgments............................................. 5 82 Authors Addresses........................................... 6 83 Intellectual Property Statement............................. 6 84 Disclaimer of Validity...................................... 7 85 Copyright Statement ........................................ 7 87 1. 88 Introduction 90 LZIP provides an extension to allow compression of text and binary 91 literals. 93 While it could be argued that transport could provide generic 94 compression of the data (e.g. TLS with NULL Cipher), application 95 level compression presents the advantage to be better tunable to the 96 February 2006 98 type of data being requested, for example, to avoid compression of 99 already compressed data. 101 Compression performances depend on the actual types of e-mail that 102 are received. They change between text bodies and different types of 103 attachments. In general, LZIP presents a worthwhile gain over 104 uncompressed or network compressed only approached at very little 105 extra cost for the implementer. 107 Bandwidth optimization are important features required in particular 108 to support mobile email use cases [MEMAIL][OMA-ME-RD] 110 2. 111 The CAPABILITY Command 113 Servers which support LZIP MUST return ‘LZIP’ in the response list to 114 a capability command. 116 Example: A LEMONADE server that implements LZIP. 117 C: a001 CAPABILITY 118 S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LZIP 119 S: a001 OK CAPABILITY completed 121 3. 122 LZIP Commands 124 The LZIP command is an extension of [RFC3516] IMAP BINARY, which 125 introduces three new commands “LZIP”, “LZIP.PEEK”, “LZIP.SIZE” that 126 parallel the syntax and semantics of “BINARY”, “BINARY.PEEK”, and 127 “BINARY.SIZE” in [RFC3516]. In general, LZIP inherits all of the 128 requirements and semantics of [RFC3516]’s “BINARY” and “BINARY.PEEK”, 129 except that the content transfer encoding being requested is 130 understood to be the result of what would be returned from BINARY 131 decoding, followed by the application of the DEFLATE algorithm. 133 Example: Zipping a body part fetch 134 C: A1 FETCH 123 LZIP.PEEK[1.2] 135 S: * LZIP[1.2]~{1234} 136 S: ….binary decoded and deflated data…. 137 S: A1 OK FETCH completed 139 As mentioned in RFC3516, LZIP.SIZE is a potentially expensive 140 operation, as in LZIP, so clients should be aware that making 141 successive requests for the same part may be expensive. 143 4. 144 LZIP Response 146 As the result of processing an LZIP command, two new responses, LZIP 147 and LZIP.SIZE which parallel that responses of [RFC3516] are 148 February 2006 150 introduced. They are identical in syntax and semantics of the BINARY 151 responses in [RFC3516] in everyway, except that the resulting binary 152 literal is understood to be in DEFLATE format. 154 5. 155 Formal Syntax 157 The following syntax specification uses the Augmented Backus-Naur 158 Form (ABNF) notation. Elements not defined here can be found in 159 the formal syntax of the [ABNF], [RFC3501], and [ABNFEXTEND]. 161 The create ABNF grammar in [RFC3501] is hereby modified to the 162 grammar defined in [ABNFEXTEND] 164 fetch-att =/ "LZIP" [".PEEK"] section-binary [partial] 165 / "LZIP.SIZE" section-binary 167 msg-att-static =/ "LZIP" section-binary SP (nstring / literal8) 168 / "LZIP.SIZE" section-binary SP number 170 Security Considerations 172 LZIP does not introduce additional security consideration with 173 respect to IMAPv4Rev1. 175 References 177 [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", 178 draft-ietf-lemonade-profile-XX.txt, (work in progress). 180 [MEMAIL] Maes, S.H., “Lemonade and Mobile e-mail", draft-maes- 181 lemonade-mobile-email-xx.txt, (work in progress). 183 [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, 184 (Work in progress). http://www.openmobilealliance.org/ 186 [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and 187 Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn 188 S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP 189 Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in 190 progress). 192 [RFC1951] Deutsch, P. “DEFLATE Compressed Data Format Specification 193 version 1.3”, RFC1951, May 1996. 194 http://www.ietf.org/rfc/rfc1951 195 February 2006 197 [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate 198 Requirement Levels", RFC 2119, March 1997. 199 http://www.ietf.org/rfc/rfc2119 201 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 202 Version 4 rev1", RFC 3501, March 2003. 203 http://www.ietf.org/rfc/rfc3501 205 [RFC3516] Nerenberg, L. “IMAP4 Binary Content Extension”, RFC3516, 206 April 2003. 207 http://www.ietf.org/rfc/rfc3516 209 Future Work 211 Should a new “compressed literal” be considered paralleling the 212 binary literal8 syntax? For example, %~{nz-number}? Potential 213 applications could be its usage in APPEND/CATENATE. 215 Version History 217 Release 00 of draft-maes-lemonadel-lzip 218 Initial release published in June 2005 219 Release 01 of draft-maes-lemonadel-lzip 220 Shortened list of editors. Authors pushed to acknowledgements 221 Section 2: Addition of exact compression algorithm 222 references 223 Section 4: 224 Addition of exact compression algorithm references 225 Considerations on command compression added 226 Correction and updates of examples 227 References: 228 Additional references on compression algorithms and IMAP4 229 Binary. 230 Release 02 of draft-maes-lemonadel-lzip 231 Reworked to model IMAP BINARY 232 Release 00 of IETF draft 233 Re-cast LZIP to focus on compression of text and binary 234 literals. 236 Acknowledgments 238 The authors want to thank all who have contributed key insight and 239 extensively reviewed and discussed the concepts of LPSEARCH and its 240 early introduction P-IMAP [P-IMAP]. In particular, this includes the 241 authors of the P-IMAP draft: Rafiul Ahad – Oracle Corporation, Eugene 242 Chiu – Oracle Corporation, Ray Cromwell – Oracle Corporation, Jia-der 243 Day – Oracle Corporation, Vi Ha – Oracle Corporation, Wook-Hyun Jeong 244 – Samsung Electronics Co. LTF, Chang Kuang – Oracle Corporation, 245 Rodrigo Lima – Oracle Corporation, Stephane H. Maes – Oracle 246 February 2006 248 Corporation, Gustaf Rosell - Sony Ericsson, Jean Sini – Symbol 249 Technologies, Sung-Mu Son – LG Electronics, Fan Xiaohui - CHINA 250 MOBILE COMMUNICATIONS CORPORATION (CMCC), Zhao Lijun - CHINA MOBILE 251 COMMUNICATIONS CORPORATION (CMCC). We also want to give a special 252 thanks to A. Melnikov for his review and suggestions. 254 Authors Addresses 256 Stephane H. Maes 257 Oracle Corporation 258 500 Oracle Parkway 259 M/S 4op634 260 Redwood Shores, CA 94065 261 USA 262 Phone: +1-650-607-6296 263 Email: stephane.maes@oracle.com 265 Ray Cromwell 266 Oracle Corporation 267 500 Oracle Parkway 268 Redwood Shores, CA 94065 269 USA 271 Anil Srivastava 272 Sun Microsystems 273 4150 Network Circle SCA15/201 274 Santa Clara, CA 94065 275 anil.srivastava@sun.com 277 Intellectual Property Statement 279 The IETF takes no position regarding the validity or scope of any 280 Intellectual Property Rights or other rights that might be claimed to 281 pertain to the implementation or use of the technology described in 282 this document or the extent to which any license under such rights 283 might or might not be available; nor does it represent that it has 284 made any independent effort to identify any such rights. Information 285 on the procedures with respect to rights in RFC documents can be 286 found in BCP 7878 and BCP 79. 288 Copies of IPR disclosures made to the IETF Secretariat and any 289 assurances of licenses to be made available, or the result of an 290 attempt made to obtain a general license or permission for the use of 291 such proprietary rights by implementers or users of this 292 specification can be obtained from the IETF on-line IPR repository at 293 http://www.ietf.org/ipr. 295 February 2006 297 The IETF invites any interested party to bring to its attention any 298 copyrights, patents or patent applications, or other proprietary 299 rights that may cover technology that may be required to implement 300 this standard. Please address the information to the IETF at ietf- 301 ipr@ietf.org. 303 Disclaimer of Validity 304 This document and the information contained herein are provided on an 305 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 306 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 307 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 308 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 309 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 310 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 312 Copyright Statement 314 Copyright (C) The Internet Society (2006). This document is subject 315 to the rights, licenses and restrictions contained in BCP 78, and 316 except as set forth therein, the authors retain all their rights. 318 Acknowledgement 320 Funding for the RFC Editor function is currently provided by the 321 Internet Society.