On Tue, 2 Feb 1993 17:10:17 -0500, Robert W. Shirey wrote:
Your message was iteresting. I am curious why PEM is totally useless to
you. Don't you send any plain ascii mail messages? Please explain, but
spare the flame.
Yes, I send plain ASCII messages, but I am also committed to MIME and *all* my
outgoing messages are in MIME format. The great majority of them are, of
course, single-segment messages of type TEXT/PLAIN (not all are in US-ASCII
charset though).
So, interaction with MIME is a requirement for me. I can't have two parallel
efforts, one supporting PEM, the other MIME. One or the other has to give
way. For a number of reasons, MIME won.
Also, there seems to be some indifference on the part of PEM to distributed
processing of mail. The suggestions I've heard for MIMEifying PEM tend to be
of the form of putting a PEM wrapper over a MIME message. This, to me, seems
to be backwards. I see a message as a collection of objects, each of which
may have its own authentication/privacy status, bundled together under the
auspices of MIME. If any message-wide authentication/privacy is done, it
should be of the MIME bundle and not of the data within the bundles.
Let me explain the reason why. Suppose you are using a remote server e-mail
architecture; I'm thinking especially of IMAP but these arguments are equally
valid for DMSP, NNTP, and to a lesser extent POP. In the brave new world of
MIME you can have relatively large messages with many attachments;
additionally, some of the attachments may be external to the message.
MIME is a lot of great things, but one thing it isn't is easy to parse on
machines with limited resources such as PC's. I have written MIME parsing
code for a PC, but it is quite slow compared to the parsing code that can run
on a Unix machine with adequate memory.
Here's what ties these two strings together: suppose the remote server took on
part of the overhead. Specifically, suppose it parsed the MIME structure so
that the client already had a parse tree of the message, without actually
having received any part of the message itself. Now, add to this supposition
a capability retrieve specific MIME segments of the message, using the parse
tree as guidance, without necessarily having to retrieve any other part of the
message.
The attractiveness of this for small machines such as PC's or Mac's is
obvious. Less obvious, but still important, is the attractiveness of this for
machines which sit behind relatively low bandwidth links (e.g. V.32b/V42b SLIP
links). This isn't just pie-in-the-sky dreaming. It's existing, deployed
technology.
The indifference of the present form of PEM to MIME takes a serious toll here.
If a MIMEgram must be encapsulated within PEM in its entirety, a distributed
system engineer is faced with the choice of doing the de-PEM step in the
server -- thus subjecting the plaintext to interception or alteration -- or of
downloading the whole thing to the client and forcing it to do both the de-PEM
and de-MIME steps. Note that we've established that de-MIMEing may be
unacceptably expensive for a small machine; yet now we're adding an extra
burden.
I'm afraid that until there is some better attention on the part of PEM to
MIME -- and to the needs of distributed architecture -- PEM isn't going to be
useful in my community. PEM would have been great back in 1989. The problem
is, PEM has been delayed for a long time and the e-mail community has moved
beyond the infrastructure that PEM covers.
I understand and sympathize greatly with the desire to get any version of PEM
out rather than have it drag on forever. PEM has suffered enough with charges
of being vapor (albeit from sources we can ignore). However, I don't see how
this version helps.
As an implementor, I see this version of PEM as being offered in direct
competition to MIME, to the detriment of both. Yet I'm sympathetic to both.
If I contrive to acquire this viewpoint, it does not take a PhD in psychology
to envision what other, less sympathetic, implementors will think. If a
``MIME vs PEM'' fight develops, I would have to lobby on behalf of MIME and
against PEM as a matter of self-preservation.
Please consider the strong negative impact that a non-MIME version of PEM may
have on the e-mail community in general, and on the large and growing MIME
community in particular. MIME has become a fundamental part of e-mail for
this community; it is not ``just'' a multi-media mail format.
What I would like to see is a fully integrated PEM as a layer on top of MIME.
Although ``MESSAGE/PEM'' as a content type is an attractive kludge, it does
not deal with the distributed processing problem I've outlined above. I would
like to continue to distribute processing as before, but without compromising
any PEM integrity or putting a burdensome processing load on clients that are
inadequate to the task. That is, I would like to see PEM encoding of a MIME
structure tree. This requires quite a bit more intelligence in PEM than
merely treating a message as plain ASCII.
These are not new viewpoints; I've stated them before. The more time passes,
the more alarmed I'm becoming at the prospect that we're seeing PEM become a
solution for the previous decade's problems. Please consider these points. I
hope it wasn't too inflammatory.
Regards,
Mark Crispin