Here is yet another way of looking at the MIME body part definition issue.
Let's start with a little fiction... At the beginning of the development
of MIME, all options were open, and it would have been possible to do it
in many different ways. One way that is plausible will now be described,
using RFC1521 terminology. Let's call it 'HM', Hypothetical MIME, to avoid
any confusion with real MIME.
HM short specification:
| A message is recognized as an HM message if a single header is found in
| it (I mean of course buried between the normal message headers), of
| the form HM-Version:1.0; boundary= some_boundary_value. There is nothing
| else that an HM encoder must or may add in a message header. When this
| header line is present, the message is an HM message, and its body is
| a structured object containing one or more body parts (just like a
| multipart/mixed body in RFC1521 MIME, with the expected dash-boundary /
| delimiter / close-delimiter business). Each body part in HM consists
| of a header, a blank line and a body. The header lines all are
| of the type Content-xxx:, and describe the body and its eventual
| transport encoding. A body can in turn be structured, just as in
| RFC1521 MIME. I won't elaborate much more, I hope you are getting
| the picture.
In HM, one can say that each message contains 'one or more body parts',
because an HM message is automatically multipart. By the way, that's what
InterPersonal Messages in X.400 look like.
It would have been perfectly possible to develop MIME to be HM. Yet it
has not be done. Why ?
The first reason one may think of is that is would have been more complicated
than RFC1521 MIME. Take a closer look: for the simplest message, the only
differences would have been that a dash-boundary and close-delimiter would
have been be involved, and that the Content-xxx headers would sit between
the dash-boundary and the actual 'content' body. Not much more complicated
really. In some respect, HM is simpler since the Content-xxx headers are
easier to spot than in the simplest MIME message.
Even more, the specification of HM is simpler that the MIME specification,
since in HM the 'body part' can be used in the definition of all kinds of
entities. And those body parts always consist of Content-xxx headers, a
blank line and a body, all neatly sequential. And Content-xxx can only
appear in a body part header. A real dream. And directly comparable to
X.400, too !
So complication is not the issue, since it is better for
interoperability to have a simpler specification, even if the objects
actually generated are a little bit longer.
So why MIME and not HM ? When the task was first defined, the objective
was to be able to include text in character sets other than US-ASCII in
the body of Internet messages, and perhaps other fancy contents. The
idea of structured messages came during the development. Therefore, it
was felt that the appearance of a 'simple' message needed to stay what
it was under raw 822, that is a header, and a body. So MIME was actually
made more complicated than HM, by putting Content-xxx: stuff inside the
header of MIME messages, instead of having them always well separated in
distinct body part headers.
We even lost a possibility: in HM, one can indicate that the body of a
single body message does not end with a CRLF (since we have the
close-delimiter). In MIME, we do not have that possibility, except
by explicitly making the message body 'multipart' and then putting only
a single part in it, which is explicitly allowed. (BTW: where the MIME
INT says this, it could be interesting to cite that particular reason).
So, while HM is like X.400, and can be described by saying that each
message contains one or more body parts, MIME has deliberately been made
in a different, more involved way, and must be described (as it is in
RFC1521) by saying that each message carries one or more BODIES.
Now, one can understand that, with the X.400 terminology also floating
around, one often hears in informal conversation that MIME also is a
way to have messages contain one or several body parts. It does not
really hurt, this is not the only case of informal language not being
exactly what one finds in the corresponding formal specification. But
yes, people reading the formal specification must then probably be warned
that what they perhaps feel they know beforehand may not be completely
accurate in the formal context. That is easy to do in a suitable
paragraph, strategically placed or even repeated (like numerous other
things) in the actual document.
Fortunately, the documents defining the mapping between X.400 and MIME
bodies do not fall in the trap. RFC1495, for example, acknowledges the
fundamental difference:
MHS messages are comprised of an IPMS.heading and an IPMS.body. The
IPMS.Body is a sequence of IPMS.BodyParts. An IPMS.BodyPart may be a
nested message (IPMS.MessageBodyPart).
A MIME message consists of headers and a content. For the purpose of
discussion, the content may be structured (multipart or message), or
atomic (otherwise). An element of a structured content may be a
message or a content.
And when dealing with the mapping, it does not say 'slam an IPMS body part
into a MIME body part', but it does specify different treatments for IPMS
bodies with one body part and those with several body parts.
/AF