I describe
the tradeoffs
between Internet Email
and traditional Fax technology
in a situation
where
a Fax machine is used to send large amounts of data.
I enumerate
several solutions
to deficiencies of traditional fax technology,
and then focus on
Email techniques
that could be used
to replace the fax.
I discuss
the desired properties
of a general Email-based solution,
a specific
Email solution
and
a migration path
for using
new Email technologies
as they become
more widely available.
Facsimile machines and Email have been around for about two decades and originally served somewhat similar purposes. Primarily they were intended to transmit small amounts of information from one point to another. The fax machine provided connectivity corresponding to the phone system's connectivity (as long as both ends had a fax machine). It was good for normal text, handwritten messages and pictures or illustrations that could be transmitted at low resolution.
Internet Email provided the same connectivity as Internet (initially very limited, but now potentially rivaling the phone system connectivity). It was good only for text, but had the advantage that the information received could be viewed, stored, or even simply deleted before being read or printed.
Traditional faxes
have problems with large amounts of data,
traditional Email with non-textual data.
Now
both Email and fax technologies have
improved dramatically,
as have the new requirements
that users have demanded.
The specific problem addressed here is based on an issue I encountered in helping support college staff in working with their database. The College needs to send a 50 page fax to about 100 locations around the world. The data to be sent originates from inside an Oracle database, and can be printed to a postscript printer or output as a postscript file. The data processing capabilities and facilities at the 100 locations is unknown, variable and unpredicatable. For example, they cannot be expected to have an Oracle database.
The series of faxes must be sent on a semi-regular basis. Eventually they will include a picture on each postscript page. The problem is that it takes about an hour to send the data to each location, assuming nothing goes wrong.
As a result,
College staff tend to
find a lot of excuses
for not sending
the fax
to each
of the locations.
Now let us
take a step back
and compare
the strengths and weaknesses
of fax technology
with that
of some alternative solutions.
The weaknesses are in the resolution of the documents received and the speed of the transmission. Since the fax goes over traditional phone lines -- these two factors play against each other. Another factor is the cost of long distance charges accumulated by sending international faxes -- again compounded by the slowness of the transmission. A further problem is the lack of redundancy -- generally you must send from a single fax machine over a specific incoming phone line to a single destination fax machine. If anything goes "wrong" in any of these facilities, the transmission will have to be postponed until the problem is corrected. Things that might go wrong are:
Although their are a few
instances of
secure fax technology
[Pesek 93],
the fax protocol itself makes encryption more
difficult
[Kalakota 96].
As a result,
security and privacy could potentially become an issue.
Before going on to Internet-based Email solutions, it should be noted that other solutions are also available, including third party Email networks and overnight delivery companies. Federal Express priority service ranges in cost from $30 for domestic delivery to $80 for delivery to obscure foreign countries. The data could also be made available through ftp, or through a web page, although security and privacy could then become a serious problem. But none of these solutions provides a cost effective solution that is simple from the perspective of the receiving party.
As we start to discuss an Internet Email solution, a few more details of the problem become significant. The two primary methods for encoding non-textual Email are MIME (Multi-purpose Internet Mail Extensions) and uuencoding. Mail received from a system using the other type of encoding may not be readable from your mail program.
The College's Email program is Novell's GroupWise. It supports attachments of many different types of files. The Oracle data to be sent can be output as a postscript file. Unfortunately, postscript is not one of the supported attachment types for GroupWise. Also, there is really no way to convert postscript to any kind of structured data, although it is possible to convert it to bitmap formats. Programs available for converting postscript to image files (e.g. GIFs) including the Sun program "fbm".
MIME does explicitly support postscript. The Email program, Pine, (used in the PSU UML and SBA labs) supports the use of MIME encoding. Later versions of Pine use the MAILCAP configuration technique for specifying external programs for dealing with attachments. [Pine Technical Notes 96]. Thus, Pine automates the process of viewing or printing external formats, much the same way Netscape does. So, if Pine were more common commercially, it might be an attractive choice for sending the Oracle data. New portable document formats like Adobe Acrobat and Novell's Envoy may eventually provide some relief from this problem.
So in the best scenario, we would have the ablility to send several alternative Email attachments to each destination, and then the mail client software at the destination, using the MAILCAP or some other mechanism, would automatically bring up the appropriate software to view and/or print the particular attachment it understands. We also would like the Email to be sent securely, using, public key cryptography to provide address authentication, data integrity and confidentiality.
Unfortunately,
given the fact that the MIME standard has
not been widely adopted yet
[NERC 96],
we have to settle for a less than perfect solution.
I propose to use the GroupWise mail program to send both the original postscript as a text attachment, and an image file (say, GIF) converted directly from postscript. The recipient of the mail could then manually chose between the two formats, based on the software and printers available on his network. According to Novell documentation, several image formats, including GIF, are transportable through GroupWise [Novell 96]. Finally, I recommend maintaining the FAX solution as a backup/last resort solution.
Since all three of the major mail programs, Novell GroupWise, Lotus CC:Mail and Microsoft Mail uuencode binary data, they each can read each others encoded files [JHU 95]. Thus the GIF attachment should be recoverable if the Email recipient has any of these three programs and he has any software that can view/print or import GIF files. If the Email recipient has a postscript printer, he or she should be able to send the postscript file to that printer.
The advantage of this solution over the fax-based solution, is in speed and cost, and potentially in the resolution of the transferred graphics. Further, the system is much more robust, in that it does not rely on a single fax machine or telephone line for the transmission. Email's store and forward mechanism translates into the convenience of sending and receiving the data at each user's (sender and receiver) convenience.
The disadvantages
are that some
human manipulation
is required
at both ends.
Also,
the security relies on there being a secure Email mechanism.
Finally, most Email systems do not provide positive
acknowledgement that the message got through,
only a negative acknowledgement that it didn't.
Based on our ongoing discussion, the College has proposed to print the Oracle data on a postscript printer, scan it into an image for each of the 50 pages, and send the images as an Email attachment. Although this is an improvement over the fax-based solution, it still involves extra steps which take human time and effectively reduce the visual clarity of the information at the destinations. It also assumes that the receiving destination is able and willing to take the steps necessary to print the image.
Our interim proposal to send both postscript and an image created directly from postscript, tries to address these issues. Also, research should be done to see if the data can be mailed directly from Oracle (if the College has or could purchase Oracle office which includes an Email capability).
Finally, as a future migration path, the use of the MIME standard (e.g. through the Novell SMTP NLM [Ouellete 96], which has just been introduced), could eventually make this whole process at lot easier. Either using S/MIME [Wingfield 95], [Timmins 95], or some other standard encryption software will also be important to maintain the privacy of the data.