home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-pillay-pop3-ext-00.txt < prev    next >
Text File  |  1997-09-11  |  6KB  |  230 lines
  1.  
  2.  
  3.  
  4.  
  5. Internet Draft                                             Harish Pillay 
  6. Expiration Date: March 1998                              Sembawang Media 
  7.                                   Marvin Tay 
  8.                            Information Frontiers
  9.                                                           September 1997
  10.  
  11.  
  12.     Extending POP Version 3 To Do Mailbox Compression
  13.  
  14.                      draft-pillay-pop3-ext-00.txt
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.      This document is an Internet-Draft.  Internet-Drafts are working
  20.      documents of the Internet Engineering Task Force (IETF), its
  21.      areas, and its working groups.  Note that other groups may also
  22.      distribute working documents as Internet-Drafts.
  23.  
  24.      Internet-Drafts are draft documents valid for a maximum of six
  25.      months and may be updated, replaced, or made obsolete by other
  26.      documents at any time.  It is inappropriate to use Internet-
  27.      Drafts as reference material or to cite them other than as
  28.      ``work in progress.''
  29.  
  30.      To learn the current status of any Internet-Draft, please check
  31.      the ``1id-abstracts.txt'' listing contained in the Internet-
  32.      Drafts Shadow Directories on ftp.is.co.za (Africa),
  33.      nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  34.      ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  35.  
  36.  
  37. Abstract
  38.  
  39.     This document suggests an extension to the Post Office Protocol
  40.     version 3 (RFC 1725) that adds an extra command to selective
  41.     compress the maildrop before transferring the mail to the
  42.     recipient.
  43.  
  44.     Given the extensive and explosive growth of mobile uses of the
  45.     Internet especially the numbers of people who access their e-mail 
  46.     via dialup modems, it does not make sense to have to transfer
  47.     e-mail to the client in uncompressed form.
  48.  
  49.     This draft discusses a new command that will make the pop3 server
  50.     to intelligently compress the maildrop into a single file and
  51.     then for it to be sent to the client.  The client will then 
  52.     process the compressed mail accordingly.
  53.     
  54.  
  55.  
  56.  
  57.  
  58.  
  59. Harish Pillay, Marvin Tay                    [Page 1]
  60.  
  61. Internet Draft        draft-pillay-pop3-ext-00.txt        September 1997
  62.  
  63.  
  64. 1. Introduction
  65.  
  66.     The Post Office Protocol version 3 was designed and implemented 
  67.     at a time where the bulk of the users were connected via local
  68.     area networks.  This meant that it did not really matter that the
  69.     mail contents retrieved were sent out in plain text with no 
  70.     compression of any manner.
  71.  
  72.     However, with the growth of the Internet and the number of people
  73.     who access it via dialup modems and other mobile, non-LAN means
  74.     suggests that we should extend the current POP3 protocol to enable
  75.     users of the POP3 system to get their maildrop transferred over
  76.     in one go, compressed, so as to reduce the cost of the connection
  77.     as well as to conclude the session as soon as possible.
  78.         
  79. 2. The Proposal 
  80.  
  81.     The current POP3 protocol is defined in RFC 1725 and includes
  82.     the following commands:
  83.  
  84.         APOP, DELE, LIST, NOOP, PASS, QUIT, 
  85.         RETR, RSET, STAT, TOP, UIDL, USER 
  86.  
  87.     It is proposed that a new command be added to the list, namely,
  88.  
  89.         CMPR
  90.  
  91.     This command is valid only in the TRANSACTION state the POP3
  92.     server gets into after completing the AUTHENTICATION state.
  93.  
  94. 3. The Server Operation
  95.  
  96.     Once the POP3 server receives the 
  97.  
  98.             CMPR
  99.  
  100.     command, it will spawn a process that will compress the current 
  101.     USER's maildrop.  The original maildrop will be left intact.
  102.  
  103.     The compression will only be done if there is anything to be
  104.     gained from it.  The compression routine will determine the
  105.     efficiency that can be gained and that there is enough disk
  106.     space to do the work and report accordingly.  
  107.  
  108.     Once the client issues the CMPR command, the server would 
  109.     respond with one of three possibilities:
  110.  
  111.         +OK POP3 server ready <12345.789011238@smedia.com.sg> 
  112.         -ERR not efficient 
  113.         -ERR not enough disk space 
  114.  
  115.  
  116.  
  117.  
  118. Harish Pillay, Marvin Tay                    [Page 2]
  119.  
  120. Internet Draft        draft-pillay-pop3-ext-00.txt        September 1997
  121.  
  122.     The +OK will mean that there are efficiencies to be gained by
  123.     the compression and that there is enough space on the server
  124.     for it to proceed.  
  125.  
  126.     The client will then send a second CMPR command:
  127.  
  128.         CMPR <12345.789011238@smedia.com.sg> [dele]
  129.  
  130.     which will have the timestamp that was received at the +OK to 
  131.     the first CMPR.
  132.  
  133.     The server will then proceed with the compression and once 
  134.     complete, it will send the compressed maildrop to the client.
  135.  
  136.     The server can choose how it does the compression.  It is free
  137.     to compress the maildrop into a compressed file and then send
  138.     that compressed maildrop file to the client.  
  139.  
  140.     Conversely, it can pipe the maildrop into the compression code
  141.     that will then output the compressed maildrop on-the-fly to
  142.     the client.
  143.  
  144.     Servers that implement the on-the-fly compression would not have 
  145.     to be concerned with disk space for the compressed maildrop.
  146.  
  147.     Servers will append a:
  148.  
  149.         <CR-LF>
  150.         +OK CMPR END
  151.  
  152.     to the end of the compressed file transmission.  If a single
  153.     CR-LF combination is in the compressed file stream, a second 
  154.     set of CR-LF will be appended to it.  The client will strip out
  155.     the 2nd CR-LF UNLESS it sees a 3rd consecutive CR-LF. 
  156.     
  157.     Servers that create a compressed maildrop will delete the 
  158.     compressed file upon successful transmission to the client.
  159.  
  160.     If the client included the [dele] optional parameter to the
  161.     second CMPR command, the server can then mark for deletion 
  162.     all the mail in the maildrop. 
  163.  
  164.  
  165. 4. The Client Operation
  166.  
  167.     Clients that implement the CMPR command will have to be able
  168.     to do the uncompression of the compressed file.  The resulting 
  169.     uncompressed file will then be placed in the client's mail 
  170.     folder system as defined by the client.  How this exploding
  171.     is to be done and subsequent processing is not relevant here.
  172.  
  173.  
  174.  
  175.  
  176. Harish Pillay, Marvin Tay                    [Page 3]
  177.  
  178. Internet Draft        draft-pillay-pop3-ext-00.txt        September 1997
  179.  
  180. 5. The Compression Algorithm
  181.  
  182.     The GNU gzip compression algorithm is to be implemented on
  183.     both the client and the server.  The authors, however, are 
  184.     open to suggestions of A compression algorithm that can give 
  185.     better compressions than gzip and for which there are no 
  186.     encumbrances or caveats.
  187.  
  188.  
  189. 6. Author Information
  190.  
  191.  
  192.     Harish Pillay
  193.     Sembawang Media Pte Ltd
  194.     Singapore 
  195.     email: h.pillay@ieee.org 
  196.  
  197.  
  198.     Marvin Tay
  199.     Information Frontiers Pte Ltd
  200.     Singapore 
  201.     email: marv@infront.com.sg
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229. Harish Pillay, Marvin Tay                    [Page 4]
  230.