Chronology Current Month Current Thread Current Date
[Year List] [Month List (current year)] [Date Index] [Thread Index] [Thread Prev] [Thread Next] [Date Prev] [Date Next]

Re: e-mail formating



Date: Sat, 29 Mar 1997 02:12:54 -0600 (CST)
From: Brad Shue <jshue@comp.uark.edu>

On Fri, 28 Mar 1997, James Mclean wrote:
Prof. John P. Ertel says:
What's wrong with BinHex (with or without initial compaction)?

Correct me if I'm wrong (because I'd certainly like to know if I am), but I
think that BinHex is just a way to convert binary files to ASCII so that
they can be sent through e-mail. You still need to choose what format the
binary original will be in. Not to mention that I think BinHex is mostly a
MacIntosh thing.

James,
As far as I can tell, binhex is not compression. It is simply a
leftover from the bitnet era when mailers could not handle binary files as
attachments. It does just as you say, converts binary files to ASCII.
Thsi is not necessary anymore unless you use an archaic mailer.
[rest snipped]

No binary file can be transmitted successfully in Internet email unless it has
been encoded. MIME (what I suspect you mean by "not archaic") uses so-called
"base64" encoding. Other "standards" have been UU and XX. The problem has
always been popularity versus platform independence. UUencoding is a prime
example, in that it is not preserved by all EBCDIC<->ASCII converters, and
much (most international) email must traverse them. Neither XX nor "base 64"
suffer this problem. The desire for proprietary solutions has greatly impeded
progress in this and other areas related to interchange; cf. TCP/IP and its
reluctant support by Microsoft and Novell.
The main problem with binary attachments now is that most binaries are
platform dependent. Thus after decoding one may or may not have anything
useful. Image files are one of two exceptions.
There is one truly platform-independent compression scheme: that of the
Info-Zip project (http://quest.jpl.nasa.gov/Info-ZIP). Versions are available
for almost all platforms used since 1980 or so. Anything compressed on any
machine by its zip tool can be correctly decompressed on any machine by
its unzip tool, and special features of the environments are preserved
or translated as appropriate.
The latest-version versus older-version problem is only a minor
reflection of the whole proprietary, platform-dependent mess.
The only reason we can all exchange notes here is TCP/IP and 7-bit ASCII;
let's not be too hasty to take a giant step backward. It wasn't all that
long ago that the thought of preparing a file on one system and reading it
on another was a daydream.


---------------------------------------------
Phil Parker pparker@twsuvm.uc.twsu.edu
Random quote for this second:
You'd think that people who don't make mistakes
would get awfully tired of doing nothing.