Excerpts from mail: 25-Apr-91 Re: Comments on Draft RFC Neil
Katin(_at_)Eng(_dot_)Sun(_dot_)COM (1315)
I think of body parts in the X.400 sense -- a body part is *not*
just a message, it is an entirely different data-type. The set
of headers that are "legal" in a message is much broader than
in a body part. In fact, "body part headers" is just a typographical
convenience to encode information; they really come from a different
name space and are interpreted on their own.
Well, that's certainly not the way we've defined it up to now.
Everything that has been said about the parts in a multipart message has
been, in effect, that it is an 822 message in miniature. I see no
problem with this.
I will freely admit that, if we were starting with a clean sheet of
paper we could define body parts in either way, but since X.400
interoperability is (should be?) a major goal, it makes sense to
define the architecture of the message structure to be compatible
with X.400 body parts.
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?