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:
<CR-LF>
+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]