idnits 2.17.1 draft-maes-lemonade-lzip-02.txt: -(128): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(164): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(179): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(202): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 449. ** 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? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- 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 13 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC3501]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (September 2005) is 6790 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) -- 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: 12 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 September 2005 3 Lemonade 4 Internet Draft: LZIP S. H. Maes 5 Document: draft-maes-lemonade-lzip-02 R. Cromwell 6 (Editors) 8 Expires: March 2006 September 2005 10 LZIP 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware have 16 been or will be disclosed, and any of which he or she becomes aware 17 will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Push Extensions to the IMAP protocol (P-IMAP) defines extensions to 38 the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile 39 setting, aimed at delivering extended functionality for mobile 40 devices with limited resources. LZIP provides an extension to allow 41 compression of the exchanged messages to and from the mobile client. 43 Conventions used in this document 44 September 2005 46 In examples, "C:" and "S:" indicate lines sent by the client and 47 server respectively. 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 An implementation is not compliant if it fails to satisfy one or more 54 of the MUST or REQUIRED level requirements for the protocol(s) it 55 implements. An implementation that satisfies all the MUST or REQUIRED 56 level and all the SHOULD level requirements for a protocol is said to 57 be "unconditionally compliant" to that protocol; one that satisfies 58 all the MUST level requirements but not all the SHOULD level 59 requirements is said to be "conditionally compliant." When 60 describing the general syntax, some definitions are omitted as they 61 are defined in [RFC3501]. 63 Table of Contents 65 Status of this Memo...............................................1 66 Abstract..........................................................1 67 Conventions used in this document.................................1 68 Table of Contents.................................................2 69 1. Introduction...................................................2 70 2. Relation with other specifications.............................3 71 3. The CAPABILITY Command.........................................3 72 4. LZIP Command...................................................4 73 Security Considerations...........................................5 74 References........................................................6 75 Future Work.......................................................6 76 Version History...................................................6 77 Acknowledgments...................................................7 78 Authors Addresses.................................................7 79 Intellectual Property Statement...................................9 80 Full Copyright Statement..........................................9 82 1. Introduction 84 The Push-IMAP protocol (P-IMAP) is based on IMAPv4 Rev1 [RFC3501], 85 but contains additional enhancements for optimization in a mobile 86 setting. LZIP provides an extension to allow compression of the 87 exchanged messages to and from the mobile client. 89 While it could be argued that transport could provide generic 90 compression of the data (e.g. TLS with NULL Cipher), application 91 level compression presents the advantage to be better tunable to the 92 type of data. 94 September 2005 96 Compression performances depend on the actual types of e-mail that 97 are received. They change between text bodies and different types of 98 attachments. In general, LZIP present a significant gain over 99 uncompressed or network compressed only approached at very little 100 extra cost for the implementer. 102 LZIP allows for compression of responses to a command. Practical 103 testing results shows significant performance improvement when the 104 responses to FETCH FLAGS or header information, body parts and 105 attachments are compressed. 107 Bandwidth optimization are are important features required in 108 particular to support mobile email use cases [MEMAIL][OMA-ME-RD] 110 2. Relation with other specifications 112 LZIP can be seen as an command that allows optimization of IMAP for 113 mobile clients. 115 The Lemonade Profile [LEMONADEPROFILE] specifies the Lemonade Pull 116 Model that governs the exchanges among mail servers or between 117 desktop mail client and mail servers. Lemonade investigates adding 118 mobile optimizations for the next version of the profile. 120 LZIP should be seen as a way to address the issues of bandwidth 121 optimization and an input to the Lemonade Profile work. 123 This document assumes that clients MUST be compliant to LZIP, if they 124 decide to use LZIP. The server that advertises support for LZIP via 125 CAPABILITY MUST be compliant to LZIP for its exchanges with the 126 mobile client. 128 LZIP adopts the �literal8� format of the IMAP BINARY specification 129 [RFC3516] for its response. 131 LZIP relies on the DEFLATE compression algorithm and format specified 132 in [RFC1951]. 134 3. The CAPABILITY Command 136 The CAPABILITY command is defined in RFC3501, section 6.1.1. The 137 client sends a CAPABILITY command so it can query the server to find 138 out what commands it supports. In RFC3501, the IMAP server is 139 allowed to specify additional capabilities not included in that 140 specification. A server that supports LZIP conforms to that 141 requirement, and must list that it supports LZIP. 143 September 2005 145 A server can also enumerate individually the other commands that it 146 supports. 148 capability_cmd = tag SP "CAPABILITY" 149 Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT 150 Responses: REQUIRED untagged response: CAPABILITY 151 Result: OK - capability completed 152 BAD - command unknown or arguments invalid 154 Example: A P-IMAP server that implements LZIP. 155 C: a001 CAPABILITY 156 S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LZIP 157 S: a001 OK CAPABILITY completed 159 4. LZIP Command 161 The LZIP command is used for zipping the response (and optionally the 162 request) of a command and can be used while the server is in any 163 state. In either case, the data is compressed according to [RFC1951] 164 and transmitted according to the �literal8� rule of [RFC3516]. The 165 LZIP command takes in a complete second command (including a tag for 166 that command). In an untagged response to LZIP, the server gives a 167 �literal8� response including the number of bytes in the zipped 168 response to the enclosed command, as well as the response to that 169 command in ZIP format. 171 LZIP can also compress the command request, although this is most 172 useful when the command request is large. Short command strings may 173 still benefit from compression, but most likely, the overhead of the 174 LZIP syntax itself, which adds about 20 characters to the command 175 request, will wipe out any gains. 177 The format for LZIP is 179 lzip_cmd = tag SP "LZIP" SP [INLINE �{� length �}�] (command or 180 zipped-compressed command) 181 Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT 182 Responses: "{" num "}" zipped-response-to-command 183 Result: OK - the command given was g-zipped correctly and sent 184 BAD - invalid arguments, i.e. command given is in the wrong 185 format. 187 Example: Zipping the response to a FETCH command. 188 C: A001 LZIP A002 FETCH 1:* ALL 189 S: * LZIP ~{10933843723} 190 S: ...[zipped response to FETCH command]... CRLF 191 S: A001 OK LZIP completed 192 September 2005 194 When the client unzips the body of the response to the FETCH command 195 it gets: 196 * 1 FETCH ... 197 ... 198 A002 OK FETCH completed 200 Example: command request compression using FETCH 202 C: A001 LZIP INLINE {1234} (zip-compressed string �a002 FETCH ...�) 203 S: * LZIP ~{4567} 204 S: ... [zipped response to FETCH command] . . .CRLF 205 S: A001 OK LZIP completed 207 The client can then unzip the body of the response as above. 209 Because the server will not know the size of the compressed response 210 until after it has compressed the stream, and in order to enable the 211 server to reduce the amount of resources it must dedicate to handling 212 each request, a server is permitted to break up the zipped stream 213 into blocks and return multiple LZIP responses for a single request. 215 Example: zipping the response of a large message fetch 216 C: A001 LZIP A002 FETCH 1 RFC822 217 S: * LZIP ~{821} 218 S: � CRLF 219 S: * LZIP ~{954} 220 S: � CRLF 221 S: * LZIP ~{987} 222 S: � CRLF 223 S: * LZIP ~{123} 224 S: � CRLF 225 S: A001 OK LZIP Completed 227 In this case, the server broke up the 3500 byte response into chunks 228 of size 1024 bytes of less, compressed them, and the results of the 4 229 compressed blocks were of length 821, 954, 987, and 123. The server 230 MUST return the LZIP dictionary/compression state between blocks. 232 The client MUST uncompress the blocks and concatenate them in the 233 order sent from the server. 235 Security Considerations 237 LZIP does not introduce additional security consideration with 238 respect to IMAPv4Rev1. 240 September 2005 242 References 244 [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", 245 draft-ietf-lemonade-profile-XX.txt, (work in progress). 247 [MEMAIL] Maes, S.H., �Lemonade and Mobile e-mail", draft-maes- 248 lemonade-mobile-email-xx.txt, (work in progress). 250 [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, 251 (Work in progress). http://www.openmobilealliance.org/ 253 [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and 254 Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn 255 S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP 256 Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in 257 progress). 259 [RFC1951] Deutsch, P. �DEFLATE Compressed Data Format Specification 260 version 1.3�, RFC1951, May 1996. 261 http://www.ietf.org/rfc/rfc1951 263 [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate 264 Requirement Levels", RFC 2119, March 1997. 265 http://www.ietf.org/rfc/rfc2119 267 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 268 Version 4 rev1", RFC 3501, March 2003. 269 http://www.ietf.org/rfc/rfc3501 271 [RFC3516] Nerenberg, L. �IMAP4 Binary Content Extension�, RFC3516, 272 April 2003. 273 http://www.ietf.org/rfc/rfc3516 275 Future Work 277 TBD 279 Version History 281 Release 00 282 Initial release published in June 2005 283 Release 01 284 Shortened list of editors. Authors pushed to acknowledgements 285 Section 2: Addition of exact compression algorithm 286 references 287 Section 4: 288 Addition of exact compression algorithm references 289 Considerations on command compression added 290 Correction and updates of examples 291 September 2005 293 References: 294 Additional references on compression algorithms and IMAP4 295 Binary. 297 Release 03 298 Added support for block encryption. 300 Acknowledgments 302 The authors want to thank all who have contributed key insight and 303 extensively reviewed and discussed the concepts of LDELIVER and its 304 early introduction as XDELIVER in P-IMAP [P-IMAP]. 306 The following contributed to the authoring of LZIP. 308 Authors Addresses 310 Stephane H. Maes 311 Oracle Corporation 312 500 Oracle Parkway 313 M/S 4op634 314 Redwood Shores, CA 94065 315 USA 316 Phone: +1-650-607-6296 317 Email: stephane.maes@oracle.com 319 Rafiul Ahad 320 Oracle Corporation 321 500 Oracle Parkway 322 Redwood Shores, CA 94065 323 USA 325 Eugene Chiu 326 Oracle Corporation 327 500 Oracle Parkway 328 Redwood Shores, CA 94065 329 USA 331 Ray Cromwell 332 Oracle Corporation 333 500 Oracle Parkway 334 Redwood Shores, CA 94065 335 USA 337 Jia-der Day 338 Oracle Corporation 339 500 Oracle Parkway 340 Redwood Shores, CA 94065 341 September 2005 343 USA 345 Wook-Hyun Jeong 346 Samsung Electronics,CO., LTD 347 416, Maetan-3dong, Yeongtong-gu, 348 Suwon-city, Gyeonggi-do, 349 Korea 442-600 350 Tel: +82-31-279-8289 351 E-mail: wh75.jeong@samsung.com 353 Chang Kuang 354 Oracle Corporation 355 500 Oracle Parkway 356 Redwood Shores, CA 94065 357 USA 359 Rodrigo Lima 360 Oracle Corporation 361 500 Oracle Parkway 362 Redwood Shores, CA 94065 363 USA 365 Gustaf Rosell 366 Sony Ericsson 367 P.O. Box 64 368 SE-164 94 Kista, 369 Sweden 370 Tel: +46 8 508 780 00 372 Jean Sini 373 6480 Via Del Oro 374 San Jose, CA 95119 375 USA 377 Sung-Mu Son 378 LG Electronics 379 Mobile Communication Technology Research Lab. 380 Tel: +82-31-450-1910 381 E-Mail: sungmus@lge.com 383 Fan Xiaohui 384 Product Development Division 385 R&D CENTER 386 CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC) 387 ADD: 53A, Xibianmennei Ave.,Xuanwu District, 388 Beijing,100053 389 China 390 TEL:+86 10 66006688 EXT 3137 391 September 2005 393 Zhao Lijun 394 CMCC R&D 395 ADD: 53A, Xibianmennei Ave.,Xuanwu District, 396 Beijing,100053 397 China 398 TEL:.8610.66006688.3041 400 Dwayne Bennett 401 Consilient 402 P.O. Box 2172 403 St. John's, NL A1C 6E6 404 Canada 405 Tel: +1 709 576 1706 406 E-mail: bennett@consilient.com 408 Intellectual Property Statement 410 The IETF takes no position regarding the validity or scope of any 411 intellectual property or other rights that might be claimed to 412 pertain to the implementation or use of the technology described in 413 this document or the extent to which any license under such rights 414 might or might not be available; neither does it represent that it 415 has made any effort to identify any such rights. Information on the 416 IETF's procedures with respect to rights in standards-track and 417 standards-related documentation can be found in BCP-11. Copies of 418 claims of rights made available for publication and any assurances of 419 licenses to be made available, or the result of an attempt made to 420 obtain a general license or permission for the use of such 421 proprietary rights by implementers or users of this specification can 422 be obtained from the IETF Secretariat. 424 The IETF invites any interested party to bring to its attention any 425 copyrights, patents or patent applications, or other proprietary 426 rights, which may cover technology that may be required to practice 427 this standard. Please address the information to the IETF Executive 428 Director. 430 Acknowledgement 432 Funding for the RFC Editor function is currently provided by the 433 Internet Society. 435 Full Copyright Statement 437 Copyright (C) The Internet Society (2005). This document is subject 438 to the rights, licenses and restrictions contained in BCP 78, and 439 except as set forth therein, the authors retain all their rights. 441 September 2005 443 This document and the information contained herein are provided on an 444 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 445 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 446 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 447 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 448 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 449 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 451 This document and translations of it may be copied and furnished to 452 others, and derivative works that comment on or otherwise explain it 453 or assist in its implementation may be prepared, copied, published 454 and distributed, in whole or in part, without restriction of any 455 kind, provided that the above copyright notice and this paragraph are 456 included on all such copies and derivative works. However, this 457 document itself may not be modified in any way, such as by removing 458 the copyright notice or references to the Internet Society or other 459 Internet organizations, except as needed for the purpose of 460 developing Internet standards in which case the procedures for 461 copyrights defined in the Internet Standards process must be 462 followed, or as required to translate it into languages other than 463 English. 465 The limited permissions granted above are perpetual and will not be 466 revoked by the Internet Society or its successors or assigns.