July 2005 Lemonade Internet Draft: LZIP S. H. Maes Document: draft-maes-lemonade-lzip-00 C. Kuang R. Lima R. Cromwell V. Ha E. Chiu J. Day R. Ahad Oracle Corporation Wook-Hyun Jeong Samsung Electronics Co., LTD Gustaf Rosell Sony Ericsson J. Sini Symbol Technologies Sung-Mu Son LGE Fan Xiaohui Zhao Lijun China Mobile Expires: January 2006 July 2005 LZIP Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Maes Expires – January 2006 [Page 1] July 2005 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Push Extensions to the IMAP protocol (P-IMAP) defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at delivering extended functionality for mobile devices with limited resources. LZIP provides an extension to allow compression of the exchanged messages to and from the mobile client. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocol(s) it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for a protocol is said to be "unconditionally compliant" to that protocol; one that satisfies all the MUST level requirements but not all the SHOULD level requirements is said to be "conditionally compliant." When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. Table of Contents Status of this Memo ........................................ 1 Abstract.................................................... 2 Conventions used in this document........................... 2 Table of Contents........................................... 2 1. Introduction............................................. 3 2. Relation with other E-mail specifications................ 3 3. The CAPABILITY Command................................... 4 4. LZIP Command............................................. 4 Security Considerations..................................... 5 References.................................................. 5 Maes Expires – January 2006 [Page 2] July 2005 Future Work................................................. 6 Version History............................................. 6 Acknowledgments............................................. 6 Authors Addresses........................................... 6 Intellectual Property Statement............................. 8 Full Copyright Statement.................................... 9 1. Introduction The Push-IMAP protocol (P-IMAP) is based on IMAPv4 Rev1 [RFC3501], but contains additional enhancements for optimization in a mobile setting. LZIP provides an extension to allow compression of the exchanged messages to and from the mobile client. While it could be argued that transport could provide generic compression of the data (e.g. TLS with NULL Cipher), application level compression presents the advantage to be better tunable to the type of data. Compression performances depend on the actual types of e-mail that are received. They change between text bodies and different types of attachments. In general, LZIP present a significant gain over uncompressed or network compressed only approached at very little extra cost for the implementer. LZIP allows for compression of responses to a command. Practical testing results shows significant performance improvement when the responses to FETCH FLAGS or header information, body parts and attachments are compressed. Bandwidth optimization are are important features required in particular to support mobile email use cases [MEMAIL][OMA-ME-RD] 2. Relation with other E-mail specifications LZIP can be seen as an command that allows optimization of IMAP for mobile clients. The Lemonade Profile [LEMONADEPROFILE] specifies the Lemonade Pull Model that governs the exchanges among mail servers or between desktop mail client and mail servers. Lemonade investigates adding mobile optimizations for the next version of the profile. LZIP should be seen as a way to address the issues of bandwidth optimization and an input to the Lemonade Profile work. This document assumes that clients MUST be compliant to LZIP, if they decide to use LZIP. The server that advertises support for LZIP via Maes Expires – January 2006 [Page 3] July 2005 CAPABILITY MUST be compliant to LZIP for its exchanges with the mobile client. 3. The CAPABILITY Command The CAPABILITY command is defined in RFC3501, section 6.1.1. The client sends a CAPABILITY command so it can query the server to find out what commands it supports. In RFC3501, the IMAP server is allowed to specify additional capabilities not included in that specification. A server that supports LZIP conforms to that requirement, and must list that it supports LZIP. A server can also enumerate individually the other commands that it supports. capability_cmd = tag SP "CAPABILITY" Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT Responses: REQUIRED untagged response: CAPABILITY Result: OK - capability completed BAD - command unknown or arguments invalid Example: A P-IMAP server that implements LZIP. C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LZIP S: a001 OK CAPABILITY completed 4. LZIP Command The LZIP command is used for zipping the response (and optionally the request) of a command and can be used while the server is in any state. The LZIP command takes in a complete second command (including a tag for that command). In an untagged response to LZIP, the server gives the number of bytes in the zipped response to the second command, as well as the response to that command in g-zip format. LZIP can also compress the command request, although this is normally not useful, except in the case of transmitting a message via LDELIVER [LDELIVER]. The format for LZIP is lzip_cmd = tag SP "LZIP" SP [INLINE ‘{‘ length ‘}’] (command or zipped-compressed command) Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT Responses: "{" num "}" zipped-response-to-command Result: OK - the command given was g-zipped correctly and sent BAD - invalid arguments, i.e. command given is in the wrong format. Maes Expires – January 2006 [Page 4] July 2005 Example: Zipping the response to a FETCH command. C: A001 XZIP A002 FETCH 1:* ALL S: * {10933843723} S: ...[zipped response to FETCH command]... CRLF S: A001 OK LZIP completed When the client unzips the body of the response to the FETCH command it gets: * 1 FETCH ... ... A002 OK FETCH completed Example: command request compression using LDELIVER C: A001 LZIP INLINE {1234} (zip-compressed string ‘a002 LDELIVER …msg contents…’) S: * {4567} S: … [zipped response to LDELIVER command] . . .CRLF S: A001 OK LZIP completed The client can then unzip the body of the response as above. Security Considerations LZIP does not introduce additional security consideration with respect to IMAPv4Rev1. References [LDELIVER] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn S-M., Xiaohui F. and Lijun Z., "LDELIVER", draft-maes-lemonade- ldeliver-xx.txt, (work in progress). [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", draft-ietf-lemonade-profile-XX.txt, (work in progress). [MEMAIL] Maes, S.H., “Lemonade and Mobile e-mail", draft-maes- lemonade-mobile-email-xx.txt, (work in progress). [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, (Work in progress). http://www.openmobilealliance.org/ [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP Maes Expires – January 2006 [Page 5] July 2005 Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in progress). [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 Future Work TBD Version History Release 00 Initial release published in June 2005 Acknowledgments The authors want to thank all who have contributed key insight and extensively reviewed and discussed the concepts of LDELIVER and its early introduction as XDELIVER in P-IMAP [P-IMAP]. Authors Addresses Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA Phone: +1-650-607-6296 Email: stephane.maes@oracle.com Rafiul Ahad Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Eugene Chiu Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Maes Expires – January 2006 [Page 6] July 2005 Ray Cromwell Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Jia-der Day Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Vida Ha Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Wook-Hyun Jeong Samsung Electronics,CO., LTD 416, Maetan-3dong, Yeongtong-gu, Suwon-city, Gyeonggi-do, Korea 442-600 Tel: +82-31-279-8289 E-mail: wh75.jeong@samsung.com Chang Kuang Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Rodrigo Lima Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Gustaf Rosell Sony Ericsson P.O. Box 64 SE-164 94 Kista, Sweden Tel: +46 8 508 780 00 Jean Sini Symbol Technologies 6480 Via Del Oro Maes Expires – January 2006 [Page 7] July 2005 San Jose, CA 95119 USA Sung-Mu Son LG Electronics Mobile Communication Technology Research Lab. Tel: +82-31-450-1910 E-Mail: sungmus@lge.com Fan Xiaohui Product Development Division R&D CENTER CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC) ADD: 53A, Xibianmennei Ave.,Xuanwu District, Beijing,100053 China TEL:+86 10 66006688 EXT 3137 Zhao Lijun CMCC R&D ADD: 53A, Xibianmennei Ave.,Xuanwu District, Beijing,100053 China TEL:.8610.66006688.3041 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights, which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Acknowledgement Maes Expires – January 2006 [Page 8] July 2005 Funding for the RFC Editor function is currently provided by the Internet Society. Full Copyright Statement Copyright (C) The Internet Society 2004. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Maes Expires – January 2006 [Page 9]