Date: Fri, 26 Apr 1991 09:42:14 -0400 (EDT)
From: Nathaniel Borenstein <nsb(_at_)thumper(_dot_)bellcore(_dot_)com>
Subject: Re: Comments on Draft RFC
Excerpts from mail: 25-Apr-91 Re: Comments on Draft RFC Neil
Katin(_at_)Eng(_dot_)Sun(_dot_)COM (1315)
Does anyone actively want to do something that is not compatible with
X.400 in this area? Are the gains worth it?
Absolutely. The power that comes from recursive encapsulation is, in my
estimation, enormous. If X.400 can't support nested encapsulated
messages, then the world needs something better than X.400. My
understanding, however, is that X.400 could indeed support nested
encapsulation, in which case a translator should be possible. Am I
wrong?
Yes, I believe you are wrong, because arbitrarily picking a different
body part heirarchy will needlessly complicate making an X.400 gateway.
I have to admit, much of the fault in this discussion is mine; Vincent's
original proposal to ietf-smtp had body parts defined differently than
yours, and I never read your proposal closely enough to pick this up.
So, what is the difference between the rfc-xxxx proposal and X.400 with
respect to body parts? Rfc-xxxx is missing a hierarchical level.
In rfc-xxxx, the "part" in multipart refers to an encapsulated message.
The headers in this encapsulation are the normal message headers.
The "type hierarchy" is a multipart message consists of an array
of messages, each of which in turn can be a multipart message.
How does X.400 do this? You have a message, which has message
specific attributes. You then have an array of "body parts", which
in turn have their own (and different) attributes. One of the
valid body part types is "encapsulated-message", which is in
turn an entire message, with all the message headers.
I *strongly* suggest we adopt the X.400 style of representing
body parts. Is it better? Not really, but it is not particularly
worse either -- it is just different.
But, I strongly believe that adopting a compatible message architecture
will make building a gateway much easier. And gateways are already
too hard to make work right.
Neil (after listening to pleas from our X.400 gateway people)