Steve (Crocker), you asked me to post a message on issues we discussed
at the Seattle meeting. I would like to address two issues in MIME:
1. Single-pass processing.
2. Originator and recipient identifiers for flexible trust models.
1. Single-Pass Processing.
The current MIME/PEM draft (March 1994) puts the cryptographic info
after the content for both signed and encrypted messages. This was to
avoid clutter at the beginning of a message. But both cases need to be
changed to allow single-pass processing. My suggestions follow PKCS #7:
Let me start by saying that I really don't have a strong opinion about this.
My purpose here is only to present the reasons why we didn't do this in the
first place.
The development of MIME has had to deal with this issue in different forms
on several occasions. Perhaps the most important case is that of
multipart/alternative, so that's the one I'll use as an example.
For those of you that are unfamiliar with MIME, a multipart/alternative object
is a container for different versions of the same information in different
formats. The idea is to send different versions alongside each other and have
MIME viewers select the version they can deal with best for their use. Only one
object in a given container is supposed to be selected and viewed.
multipart/alternative obviously has ordering considerations. There are two
obvious orderings:
(1) Simplest to most complex. This is a win for users without MIME, since the
simplest version of the object (often text) is closest to the front of
the message.
(2) Complex to simplest. This is a win for viewers, since they can now process
multipart/alternative in a single pass.
There was lots of debate about this. In the end it was decided to go with
(1) since maximum compatibility with the installed non-MIME base was seen to
be more important.
In retrospect, the idea of making design choices with the intention of
minimizing installed base impact has proved to be a big win.
The same set of tradeoffs applies to MIME-PEM. We can either order the
information so that single-pass processing is possible or we can put some stuff
up front that clutters up messages on non-MIME-non-PEM-capable viewers. We
elected to adopt the approach taken by MIME.
Now, one can argue that since the amount of information up front is pretty
small this really isn't a big deal. Others may argue that it is a very big deal
indeed. (This is a matter of religion with some folks.)
Anyway, this is why the draft reads the way it does. I'm certainly receptive to
suggestions that we should do it differently, but we really need to see a
consensus on this before adopting a different philosophical approach.
Ned