Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site Navajo.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!Glacier!Navajo!ehl
From: ehl@Navajo.ARPA
Newsgroups: net.micro.mac
Subject: Re: New MacBinary Protocol from Compuserve
Message-ID: <140@Navajo.ARPA>
Date: Wed, 1-May-85 14:17:21 EDT
Article-I.D.: Navajo.140
Posted: Wed May  1 14:17:21 1985
Date-Received: Sat, 4-May-85 05:40:55 EDT
References: <1204@amdcad.UUCP>
Organization: Stanford University
Lines: 27

Some initial thoughts about the MacBinary protocol:

Seems to me that the folks at CompuServe have come up with something that
makes a lot of sense for CompuServe but not for Usenet or ARPA.

It makes sense in for CompuServe to have a file format that will enable file
transfers to be essentially transparent -- instead of having to binhex and
upload or download and binhex, with a compatible terminal emulator people
can simply transfer via XMODEM (MacBinary) and automatically transfer a
single file (not three like MacTerminal) that contains all the required
Macintosh information within it and is faster to transfer to boot (8-bit vs.
ASCII hex encoding).

The scheme does not make much sense for Usenet or ARPA -- ever try to get
8-bit binaries through your local mailer?  Sure, you can uuencode/uudecode
things, but that implies having a UNIX system around, which in particular is
not valid for the ARPA INFO-MAC setup.  BinHex version 5 is definitely not
helpful -- it will convert the previous BinHex formats, but will only
produce the new MacBinary .BIN files.

My feeling:  stick with BinHex version 4 and the .HQX format.

-- 
Elgin Lee

UUCP:  ..decvax!decwrl!glacier!navajo!ehl
ARPA:  ehl@su-navajo.ARPA, ehl@su-score.ARPA