On the translation from X.400 to 822:
There's a special case
action taken when the gateway encounters an encapsulated message as a
bodypart; this recursively generates an encapsulated message as a
bodypart. If this is in turn a multipart message, you get a multipart
message type and away you go.
The ambiguous case is where you have a forwarded message with only one
part. The easy answer is just to use a multipart encapsulation that
contains only one part.
Let's say the X.400 message has one body part which is a ForwardedIPM
with two body parts, say, text and g3FAX. What does this map to? It
seems like the minimum is:
From: mumble
To: other-mumble
Content-Type: multipart; 1-S; asdfgh
--asdfgh
From: original-originator
To: original-recipients
Subject: original-subject
... other forwarding headers ...
Content-type: multipart; 1-S; qwerty
--qwerty
... text ...
--qwerty
--qwerty
Content-type: G3Fax
Content-Encoding: Base64
... fax data ...
--qwerty
--asdfgh
Is there a way to do without the outer multipart? It seems that using
the multipart mechanism (in single part mode) just to carry a message
is overkill. Of course there's "message", but that implies carrying
the forwarded message in ASN.1 rather than broken out.
Again, it seems like the culprit is that the notion of recursive
messages is tied up with the multipart mechanism.
I appreciate the elegance of Nathaniel's scheme -- that there's just
one header mechanism -- but I just don't think it works out right.
I think we're stuck with the notions of both message headers (the 822
kind) and part headers. Part headers contain the information
associated with each part of a multipart content (like Content-type and
Content-encoding).
For the case where there are multiple parts, the message Content-type
is "multi-part" and each part's Content-type identifies the data for
that part. In the case where a message has just one part, the part
headers are merged with the 822 headers. The "message" content type is
defined to mean that the data is another 822 message (which may contain
a content-type header). (The current "message" type (the ASN.1
encoding of a forwarded message) doesn't seem too useful.)
Pete