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
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.
Return to November 1995
Return to “Simon Spero <ses@tipper.oit.unc.edu>”