1995-11-17 - Re: NSA, ITAR, NCSA and plug-in hooks.

Header Data

From: Simon Spero <ses@tipper.oit.unc.edu>
To: Scott Brickner <sjb@universe.digex.net>
Message Hash: f3c50656291ca5f8f77cef319c5a747517c680e0eb5364d29c6e5496e8b04936
Message ID: <Pine.SOL.3.91.951116161656.19526G-100000@chivalry>
Reply To: <199511162113.QAA08492@universe.digex.net>
UTC Datetime: 1995-11-17 02:23:54 UTC
Raw Date: Fri, 17 Nov 1995 10:23:54 +0800

Raw message

From: Simon Spero <ses@tipper.oit.unc.edu>
Date: Fri, 17 Nov 1995 10:23:54 +0800
To: Scott Brickner <sjb@universe.digex.net>
Subject: Re: NSA, ITAR, NCSA and plug-in hooks.
In-Reply-To: <199511162113.QAA08492@universe.digex.net>
Message-ID: <Pine.SOL.3.91.951116161656.19526G-100000@chivalry>
MIME-Version: 1.0
Content-Type: text/plain


On Thu, 16 Nov 1995, Scott Brickner wrote:
> 
> You'd need a program which not only *accepted* the additional parameter,
> but also *needed* the second parameter.  I confess I have some difficulty
> thinking of one.

It's not too hard to think of a compression scheme that needs extra 
information to be passed from client to server; the obvious example is 
some sort of dictionary compression with external dictionaries (can be 
very effective for short messages where LZW etc never get a chance to get 
going). 

Another, more likely case, is where the object could have been compressed 
by several schemes, and a scheme ID is needed to determine which 
alogorithm to use. 

The real issue would appear to be intent, though. If it's obvious that 
the real intention for the hook is to allow encryption to be added, 
the State department can jump on it. 





Thread