[TUHS] attachments: MIME and uuencode

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Dan Cross

    > why did you consider it such a step forward? I'm really curious about
    > the reasoning from folks involved with such things at the time.

This was N layers up from my zone of responsibility when I was on the IESG
(which was the internetwork layer), and I don't recall any discussion about it
on the IESG (although if you really care, there might be minutes - I don't
recall when IESG minutes started, though, perhaps this was before that). That
lack of any memory may be nothing more than a sign of my fading memory, but it
could mean it wasn't a very contentious topic.

FWIW, here's my current analysis of the issues; I doubt my analysis then
would have been substantially different.


The fundamental thing that email does is send something - originally a
section of text - from party A to party B in a way that requires no previous
setup or interaction: party B can be anyone in the entire universe of
entities which support that service. MIME is an extension of this model to
carry other types of data: images, etc.

There is a very good analogy to the pre-existing real-world mail system: that
too allows one to send things to anyone without prior special arrangement, and
it supports not only transferring text, but also sending more than that -
physical objects. This pre-existing system argues that this model of operation
is i) useful, and ii) issues raised by it have probably mostly been worked
through.

So the extension of email to carry more than just text seems like a very
plausible extension.

For the 'average' user, the ability to include images in email is a huge
improvement over any alternative. Any kind of 'pull' model (in which the
receiver has to do something to retrieve the data later from some sort of
server) requires access to such a server on the part of the sender; use of a
'push' model (in which data is sent in the same way as text, as part of a
single transfer) is clearly better.


Security issues raised by sending binary data through email are a separate
question, but I note that those issues will mostly still exist no matter how
the binary data is transferred. (E.g. the binary might contain a virus no
matter whether it's transferred via SMTP or FTP.) The ability of email to send
to anyone does raise issues in this context, but this margin is not big enough
to fully explore them.

I also do get a little uncomfortable when email is used instead of a file
transfer system, for very large files, etc, etc. The thing is that the email
system was not designed to transfer really huge objects (although the size
allowed has been going up over time). The store-and-forward model of the
email system is not really ideal for huge objects, etc, etc.


But having said all that, the extension of the email model to send content
other than pure text - images, etc - still seems like a good idea to me.

	Noel