Internet Draft Harish Pillay Expiration Date: March 1998 Sembawang Media Marvin Tay Information Frontiers September 1997 Extending POP Version 3 To Do Mailbox Compression draft-pillay-pop3-ext-00.txt Status of this Memo This document is an Internet-Draft. 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 made obsolete 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document suggests an extension to the Post Office Protocol version 3 (RFC 1725) that adds an extra command to selective compress the maildrop before transferring the mail to the recipient. Given the extensive and explosive growth of mobile uses of the Internet especially the numbers of people who access their e-mail via dialup modems, it does not make sense to have to transfer e-mail to the client in uncompressed form. This draft discusses a new command that will make the pop3 server to intelligently compress the maildrop into a single file and then for it to be sent to the client. The client will then process the compressed mail accordingly. Harish Pillay, Marvin Tay [Page 1] Internet Draft draft-pillay-pop3-ext-00.txt September 1997 1. Introduction The Post Office Protocol version 3 was designed and implemented at a time where the bulk of the users were connected via local area networks. This meant that it did not really matter that the mail contents retrieved were sent out in plain text with no compression of any manner. However, with the growth of the Internet and the number of people who access it via dialup modems and other mobile, non-LAN means suggests that we should extend the current POP3 protocol to enable users of the POP3 system to get their maildrop transferred over in one go, compressed, so as to reduce the cost of the connection as well as to conclude the session as soon as possible. 2. The Proposal The current POP3 protocol is defined in RFC 1725 and includes the following commands: APOP, DELE, LIST, NOOP, PASS, QUIT, RETR, RSET, STAT, TOP, UIDL, USER It is proposed that a new command be added to the list, namely, CMPR This command is valid only in the TRANSACTION state the POP3 server gets into after completing the AUTHENTICATION state. 3. The Server Operation Once the POP3 server receives the CMPR command, it will spawn a process that will compress the current USER's maildrop. The original maildrop will be left intact. The compression will only be done if there is anything to be gained from it. The compression routine will determine the efficiency that can be gained and that there is enough disk space to do the work and report accordingly. Once the client issues the CMPR command, the server would respond with one of three possibilities: +OK POP3 server ready <12345.789011238@smedia.com.sg> -ERR not efficient -ERR not enough disk space Harish Pillay, Marvin Tay [Page 2] Internet Draft draft-pillay-pop3-ext-00.txt September 1997 The +OK will mean that there are efficiencies to be gained by the compression and that there is enough space on the server for it to proceed. The client will then send a second CMPR command: CMPR <12345.789011238@smedia.com.sg> [dele] which will have the timestamp that was received at the +OK to the first CMPR. The server will then proceed with the compression and once complete, it will send the compressed maildrop to the client. The server can choose how it does the compression. It is free to compress the maildrop into a compressed file and then send that compressed maildrop file to the client. Conversely, it can pipe the maildrop into the compression code that will then output the compressed maildrop on-the-fly to the client. Servers that implement the on-the-fly compression would not have to be concerned with disk space for the compressed maildrop. Servers will append a: +OK CMPR END to the end of the compressed file transmission. If a single CR-LF combination is in the compressed file stream, a second set of CR-LF will be appended to it. The client will strip out the 2nd CR-LF UNLESS it sees a 3rd consecutive CR-LF. Servers that create a compressed maildrop will delete the compressed file upon successful transmission to the client. If the client included the [dele] optional parameter to the second CMPR command, the server can then mark for deletion all the mail in the maildrop. 4. The Client Operation Clients that implement the CMPR command will have to be able to do the uncompression of the compressed file. The resulting uncompressed file will then be placed in the client's mail folder system as defined by the client. How this exploding is to be done and subsequent processing is not relevant here. Harish Pillay, Marvin Tay [Page 3] Internet Draft draft-pillay-pop3-ext-00.txt September 1997 5. The Compression Algorithm The GNU gzip compression algorithm is to be implemented on both the client and the server. The authors, however, are open to suggestions of A compression algorithm that can give better compressions than gzip and for which there are no encumbrances or caveats. 6. Author Information Harish Pillay Sembawang Media Pte Ltd Singapore email: h.pillay@ieee.org Marvin Tay Information Frontiers Pte Ltd Singapore email: marv@infront.com.sg Harish Pillay, Marvin Tay [Page 4]