1995-02-08 - Re: MIME based remailing commands

Header Data

From: xpat@vm1.spcs.umn.edu
To: cypherpunks@toad.com
Message Hash: 2c2046a266ad3ec6632909c5130a2b4a18f7b32a99b5f35d0801ddf9b58406ee
Message ID: <9502082251.AA03118@toad.com>
Reply To: N/A
UTC Datetime: 1995-02-08 22:52:06 UTC
Raw Date: Wed, 8 Feb 95 14:52:06 PST

Raw message

From: xpat@vm1.spcs.umn.edu
Date: Wed, 8 Feb 95 14:52:06 PST
To: cypherpunks@toad.com
Subject: Re: MIME based remailing commands
Message-ID: <9502082251.AA03118@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Hal writes:

>I can see that putting remailer commands into a specific part of a MIME
>multipart message has some advantages.  Right now we are basically
>having the remailing commands be mail header fields.

>OTOH it does have the advantage that it is easy to do, at least with th
>"::" pasting token idea (which perhaps would need to be documented in is
>own right).

IMHO, an ideal message would have the ability to handle nested objects
of varying types, MIME is only a start. To construct a unique format
for remail_messages is reasonable, perhaps even preferable. But of
course, MIME *could* be a start, in a brown'n'serve roll sort of way.

However, with a proprietary approach,
what to use for delimiters, or quasi-parentheses (in the case of n
layers of nesting, encrypted or unencrypted) needs extensive and
careful consideration. This is the same dilemma many developers face
with document-centric interfaces and their plethora of odd-bird formats.

I say take the remail stuff out of the header altogether,
MIME or not.

----------------------------------------------------------------
P M Dierking |





Thread