Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!ll-xn!husc6!panda!teddy!jpn
From: jpn@teddy.UUCP (John P. Nelson)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Source ARCs are inappropriate!
Message-ID: <5164@teddy.UUCP>
Date: 28 Oct 88 14:52:51 GMT
References: <7119@dasys1.UUCP> <4457@bsu-cs.UUCP> <7194@dasys1.UUCP> <5665@ecsvax.uncecs.edu> <4160@tekgvs.GVS.TEK.COM> <2547@silver.bacs.indiana.edu>
Reply-To: jpn@teddy.UUCP (John P. Nelson)
Distribution: na
Organization: GenRad, Inc., Concord, Mass.
Lines: 34

In article <2547@silver.bacs.indiana.edu> burleigh@silver.UUCP (frank burleigh) writes:
>Those who want to send clear text over USENET and who wouldn't gag
>on a SEA product could use ARC's S suffix to store the text in an
>archive without compressing it.  The archive is still binary, but 
>that would only be file headers.  All else seems to be clear text.
>of course PKPAK hasn't such a suffix...

Uh, I think you missed the point.  The reason that posting ARC's of
text files is a problem is because you must "uuencode" them before
posting.  ARC (with or without the S suffix) generate a file which
must be uuencoded because USENET can only tolerate ASCII files.

It is the

   ASCII   ->   BINARY  (ARC)   ->  ASCII (uuencode)

sequence that is the real problem with ARC's on usenet.  It is much
more efficient to skip BOTH the ARC and uuencode steps, and post the
ASCII text directly.  However, it HAS been established that:

   BINARY  ->   ARC   ->  UUENCODE

is no worse than

   BINARY  ->   UUENCODE

in terms of transmission efficiency, and it is more convenient for
the end-users as well.

-- 
     john nelson

UUCP:	{decvax,mit-eddie}!genrad!teddy!jpn
smail:	jpn@teddy.genrad.com