[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

                                <LZIP>                  September 2005


Lemonade
Internet Draft: LZIP                                         S. H. Maes
Document: draft-maes-lemonade-lzip-02                       R. Cromwell
                                                              (Editors)




Expires: March 2006                                      September 2005


                                   LZIP

Status of this Memo


   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 becomes aware
   will be disclosed, in accordance with Section 6 of BCP 79.

   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
   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




Maes                     Expires û March 2006                 [Page 1]


                                <LZIP>                  September 2005


   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..........................................................1
   Conventions used in this document.................................1
   Table of Contents.................................................2
   1. Introduction...................................................2
   2. Relation with other specifications.............................3
   3. The CAPABILITY Command.........................................3
   4. LZIP Command...................................................4
   Security Considerations...........................................5
   References........................................................6
   Future Work.......................................................6
   Version History...................................................6
   Acknowledgments...................................................7
   Authors Addresses.................................................7
   Intellectual Property Statement...................................9
   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.


Maes                     Expires û March 2006                 [Page 2]


                                <LZIP>                  September 2005



   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 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
   CAPABILITY MUST be compliant to LZIP for its exchanges with the
   mobile client.

   LZIP adopts the æliteral8Æ format of the IMAP BINARY specification
   [RFC3516] for its response.

   LZIP relies on the DEFLATE compression algorithm and format specified
   in [RFC1951].

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.




Maes                     Expires û March 2006                 [Page 3]


                                <LZIP>                  September 2005


   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.  In either case, the data is compressed according to [RFC1951]
   and transmitted according to the æliteral8Æ rule of [RFC3516]. The
   LZIP command takes in a complete second command (including a tag for
   that command).  In an untagged response to LZIP, the server gives a
   æliteral8Æ response including the number of bytes in the zipped
   response to the enclosed command, as well as the response to that
   command in ZIP format.

   LZIP can also compress the command request, although this is most
   useful when the command request is large. Short command strings may
   still benefit from compression, but most likely, the overhead of the
   LZIP syntax itself, which adds about 20 characters to the command
   request, will wipe out any gains.

   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.

   Example: Zipping the response to a FETCH command.
      C: A001 LZIP A002 FETCH 1:* ALL
      S: * LZIP ~{10933843723}
      S: ...[zipped response to FETCH command]... CRLF
      S: A001 OK LZIP completed




Maes                     Expires û March 2006                 [Page 4]


                                <LZIP>                  September 2005


   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 FETCH

   C: A001 LZIP INLINE {1234} (zip-compressed string æa002 FETCH ...Æ)
   S: * LZIP ~{4567}
   S: ... [zipped response to FETCH command] . . .CRLF
   S: A001 OK LZIP completed

   The client can then unzip the body of the response as above.

   Because the server will not know the size of the compressed response
   until after it has compressed the stream, and in order to enable the
   server to reduce the amount of resources it must dedicate to handling
   each request, a server is permitted to break up the zipped stream
   into blocks and return multiple LZIP responses for a single request.

   Example: zipping the response of a large message fetch
   C: A001 LZIP A002 FETCH 1 RFC822
   S: * LZIP ~{821}
   S: à CRLF
   S: * LZIP ~{954}
   S: à CRLF
   S: * LZIP ~{987}
   S: à CRLF
   S: * LZIP ~{123}
   S: à CRLF
   S: A001 OK LZIP Completed

   In this case, the server broke up the 3500 byte response into chunks
   of size 1024 bytes of less, compressed them, and the results of the 4
   compressed blocks were of length 821, 954, 987, and 123. The server
   MUST return the LZIP dictionary/compression state between blocks.

   The client MUST uncompress the blocks and concatenate them in the
   order sent from the server.


Security Considerations

   LZIP does not introduce additional security consideration with
   respect to IMAPv4Rev1.





Maes                     Expires û March 2006                 [Page 5]


                                <LZIP>                  September 2005


References

   [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
      Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in
      progress).

   [RFC1951] Deutsch, P. ôDEFLATE Compressed Data Format Specification
      version 1.3ö, RFC1951, May 1996.
      http://www.ietf.org/rfc/rfc1951

   [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

   [RFC3516] Nerenberg, L. ôIMAP4 Binary Content Extensionö, RFC3516,
      April 2003.
      http://www.ietf.org/rfc/rfc3516

Future Work

   TBD

Version History

   Release 00
      Initial release published in June 2005
   Release 01
         Shortened list of editors. Authors pushed to acknowledgements
            Section 2: Addition of exact compression algorithm
   references
            Section 4:
               Addition of exact compression algorithm references
               Considerations on command compression added
               Correction and updates of examples


Maes                     Expires û March 2006                 [Page 6]


                                <LZIP>                  September 2005


            References:
               Additional references on compression algorithms and IMAP4
   Binary.

   Release 03
         Added support for block encryption.


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].

   The following contributed to the authoring of LZIP.

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

   Ray Cromwell
   Oracle Corporation
   500 Oracle Parkway
   Redwood Shores, CA 94065
   USA

   Jia-der Day
   Oracle Corporation
   500 Oracle Parkway
   Redwood Shores, CA 94065


Maes                     Expires û March 2006                 [Page 7]


                                <LZIP>                  September 2005


   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
   6480 Via Del Oro
   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



Maes                     Expires û March 2006                 [Page 8]


                                <LZIP>                  September 2005


   Zhao Lijun
   CMCC R&D
   ADD: 53A, Xibianmennei Ave.,Xuanwu District,
   Beijing,100053
   China
   TEL:.8610.66006688.3041

   Dwayne Bennett
   Consilient
   P.O. Box 2172
   St. John's, NL A1C 6E6
   Canada
   Tel: +1 709 576 1706
   E-mail: bennett@consilient.com

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

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Full Copyright Statement

   Copyright (C) The Internet Society (2005). 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.




Maes                     Expires û March 2006                 [Page 9]


                                <LZIP>                  September 2005


   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 û March 2006                [Page 10]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/