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.
Ned,
As I read the current RFC, you'd translate
From: mumble
To: other-mumble
Content-Type: multipart; 1-S; asdfgh
--asdfgh
Content-type: G3Fax
Content-Encoding: Base64
... fax data ...
--asdfgh
into an X.400 message with one G3FAX body part and translate
From: mumble
To: other-mumble
Content-Type: multipart; 1-S; asdfgh
--asdfgh
Content-type: G3Fax
Content-Encoding: Base64
To: new-mumble
... fax data ...
--asdfgh
into an X.400 message with one ForwardedIPM body part (that contains a
single FAX body part).
Note the difference. G3Fax verses ForwardedIPM. The switch to
ForwardedIPM is required because of the 822 "To:" header within the
G3Fax part. (See the new RFC, section 4, first paragraph and the third
part of the example in section 5).
I have a feeling that this subtlety may have been missed by many. Did
you catch it? Does your gateway actually detect the 822 header and use
ForwardedIPM? If so, do you feel that it is sufficiently robust?
This all comes from the fact that a multipart message is defined to be
a collection of messages.
We feel that the parts of a multipart message should be "attachments",
where an attachment has a Content-Type header (and others as currently
debated, but not the 822 headers) and data. The case of a forwarded
message would be handled by a "message" content type.
To me, this seems a much cleaner mapping to X.400. What do you think?
Pete