Since I have a fully operational bidirectional X.400 gateway that's based
on an earlier draft of the RFC, I cannot buy into your argument that the
structure is different enough to make gatewaying a problem. I had no trouble
with doing it.
An X.400 message with one bodypart is converted into a single part message,
with an appropriate message-type header (as I said, based on an earlier draft).
If the X.400 message has multiple parts, a multipart message is generated,
and the individual X.400 bodyparts are mapped into the various parts of that
message. 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. This eliminates the ambiguity completely. However, there is an
operational concern here. Several extant X.400 mailers have a nasty habit of
repeatedly encapsulated forwarded bodyparts. I've seen encapsulations
ten or more levels deep. This is automatic (these mailers also recurse down to
the level where there's data and discard the intermediate levels; users never
even know that this is happening as they forward and forward and the
encapsulations get deeper and deeper) and cannot be prevented. Such messages,
if converted with the structure intact, are unbearably ugly. So I provided
a gateway option that automatically removes the layers of encapsulation
that are redundant. I don't like doing this since the message structure is
not preserved, which I think is wrong, but the horrible results (and
complaints) I get otherwise are more of a problem right now. (The mailer
that does this, which I'm not going to name, is a commercial product with
a huge installed base of hundreds of thousands of sites -- I expect that it
is the most widely used X.400 compliant mailer in the world today. If you
think you know e-mail you might want to try and guess which mailer it is.)
On the other hand, I don't have a problem with providing an explicit
content-type that says "encapsulated message". But it not because I think
it is needed for X.400 gateways -- it isn't. In fact, it introduces an
interesting ambiguity of its own. If you map the encapsulated message
type to FORWARDEDIPMSG, then what do you map a nested multipart content-type
to? (You can either just take it apart and insert the bodyparts at the
same level, in effect losing structure, or you can generate an
artificial FORWARDEDIPMSG part, in effect gaining structure that wasn't
already there. Now, when you get a FORWARDEDIPMSG with multiple parts inside,
do you map it to an encapsulated message containing a multipart content-type
or just a multipart content-type?)
Ned