Re: MIME based remailing commands

Nathaniel Borenstein <nsb@nsb.fv.com> writes:

>Excerpts from junk.interesting: 7-Feb-95 Re: MIME based remailing co..
>"Perry E. Metzger"@imsi. (2553)

>> > > It is being remailed via a MIME-based structure where two new content types
>> > > are defined: multipart/remail and application/remail-commands.  The
>> > > multipart/remail type is supposed to be composed of two parts, the
>> > > application/remail-commands part which has remailer commands, and the
>> > > other part which is the "payload" to be remailed.

>Perhaps you might consider writing up an informational RFC to define
>these types?  I think that would be very useful. -- Nathaniel

Well, that was just an example; I was making those names up off the top
of my head in order to concretize what I understood Perry was suggesting.

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.  But really people
aren't supposed to just make up new fields like that.  I think the
"name space" of these fields is protected somewhat more than many other
aspects of communication protocols on the net.  Is there precedent for
adding service-by-mail functionality in this way?  I am not completely
comfortable with it.  And as we think of new functionality and new
commands they all have to get added at this top level, the same
visibility and name space as "Subject", "From", and "To".

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

If we did use a separate message part we'd have our own little name space
to use, with no fears of conflicting with someone else.  (Maybe "Latency"
might be used in a future extension of RFC822 for some other meaning than
what we are using it for.)  I am not sure what has to be done to get an
RFC approved but I suspect that adding mail header fields would be much
more likely to hit opposition than adding yet another MIME type.

What does Mixmaster use for its commands?  Does it use "::" followed by
Anon-Send-To: and such?  Or some other format?  Maybe it should be made
MIME compliant from the beginning.  This way we are moving with the
current, the flow of the net, rather than across it.

Hal

Date: Wed, 8 Feb 1995 12:37:54 -0800
    From: Hal <hfinney@shell.portal.com>
    
    Nathaniel Borenstein <nsb@nsb.fv.com> writes:

    Right now we are basically having the remailing commands be mail
    header fields.  But really people aren't supposed to just make up
    new fields like that.  I think the "name space" of these fields is
    protected somewhat more than many other aspects of communication
    protocols on the net.

If you start your header name with X-, then you are conforming that
gross, ugly atrocity that is MIME.  And yet, by using headers rather
than TGUATIM, you help to preserve sanity and avoid that vast majority
of MIME slime.

Note that I'm not suggesting that MIME has no place.  When you truly
need to mix data types and you *want* the different parts to be easily
processed by all, it makes perfect sense.

Given the privacy goals of a remailing, MIME has only disadvantages.

    Is there precedent for adding service-by-mail functionality in
    this way?  I am not completely comfortable with it.  And as we
    think of new functionality and new commands they all have to get
    added at this top level, the same visibility and name space as
    "Subject", "From", and "To".

So, do what you have to in C and C++-sans-namespaces, use a prefix.
X-RM- could prefix the Remailer namespace.  It's ugly, but compared to
the alternative it is pure beauty.
    
--
Rick Busdiecker <rfb@lehman.com>      Please do not send electronic junk mail!
  Lehman Brothers Inc.
  3 World Financial Center  "The more laws and order are made prominent, the
  New York, NY  10285-1100   more thieves and robbers there will be." --Lao Tzu

From: Hal <hfinney@shell.portal.com>

   Is there precedent for
   adding service-by-mail functionality in this way?  

You mean, like MIME?

   (Maybe "Latency"
   might be used in a future extension of RFC822 for some other meaning than
   what we are using it for.)

The command should be Add-Delay: if you want to acheive the result of
some latency.  (Those who don't recognize the double-edged nature of
this remark are welcome to make fools of themselves in public.)

Eric