Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!lll-lcc!lll-tis!ames!amdcad!sun!dbercel
From: dbercel@sun.uucp (Danielle Bercel, MIS Systems Programming)
Newsgroups: comp.sys.ibm.pc
Subject: PKARC 3.5 -g option
Message-ID: <23599@sun.uucp>
Date: Wed, 15-Jul-87 23:47:24 EDT
Article-I.D.: sun.23599
Posted: Wed Jul 15 23:47:24 1987
Date-Received: Sat, 18-Jul-87 05:48:03 EDT
Reply-To: dbercel@sun.UUCP (Danielle Bercel, MIS Systems Programming)
Distribution: na
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 37

Since we are all talking about compatibility between
PKARC and ARC, I just recalled another area of slight
incompatibility. The encryption option.

PKARC version 3.5 has implemented ARC's -g option to
encrypt a compressed file. I use this function for
my personal correspondence. Just as a small measure of
security. 

When PKARC added this feature I tried it against one of 
the ARC encoded files and found that it did not decrypt
it properly. After that small test I decided
against further testing since this was in the minority of
uses I put PKARC to.

In light of our current conversation, I just thought I'd
mention it. And, one other thing.

There have been a few messages about how horrible it
is for a new method to be introduced that is not
compatible with existing compression methods. I would
like to point out that when ARC was first introduced
it replaced a number of existing programs (nusq, usq, lupc,
etc.), and was incompatible with them.

Since PKARC seems to be gainning ground as the standard for
many BBSes, it would appear the the original ARC will
have to catch up or see their product go the way of
the products that they originally surmounted.

danielle

-- 
UUCP:  {hplabs,decvax,}!sun!toto!{danielle,dbercel}                        
/-------------------------------------\
| Toto, I don't think this is Kansas. | -- Danielle Bercel
\-------------------------------------/    Sun Microsystems, Inc.