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
Nope. It gets translated into a FORWARDIPMSG that in turn contains one
bodypart, G3FAX. A message of the form
From: mumble
To: other-mumble
Content-type: G3Fax
Content-Encoding: Base64
... fax data ...
--asdfgh
Gets translated into a message with a single G3FAX bodypart.
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).
Yup, I do it this way.
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).
Well, it is not how I interpreted it. I don't draw a parallel between 822
message and X.400 P2 content. I can see how you might interpret it that way,
however, and that means the language should be shifted to block this
interpretation.
The example could be changed to something that maps to X.400 in a more obvious
way, if that will clear things up.
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?
The subtlety is not lost on me. The problem here is the same one I already
discussed -- that there exist headers which don't map cleanly into the X.400
world. However, you're only dealing with the tippy top tip of the iceberg here.
How do you deal with headers that don't have a defined mapping (which are
explicitly allowed)? How do you deal with nested headers whose mapping is
defined to be to the X.400 envelope, not the content (for those folks that are
trying to follow this stuff without X.400 experience, there's a chunk of X.400
material that's only allowed at the outermost level, and some of this material
maps to/from RFC822 header lines)?
According to spec, what you're supposed to do is stuff all the headers into an
extra bodypart. This certainly should be provided as an option, but most people
prefer to have them punted into the ozone instead, and this option also has to
be provided for practical reasons. I prefer to use a mixture of the two
techniques, since there's no really satisfactory solution. Preservation
of stray subject headers is especially important, for example.
I don't have good answers for what to do with this material at any level.
But the problem is at most exacerbated by the choice of how we deal with
structure. No clever mapping choice is going to make the problem go away.
This all comes from the fact that a multipart message is defined to be
a collection of messages.
I do see what you're driving at here, finally. (And please pardon my denseness
- I should have figured it out sooner.) The problem is that we're faced with
the obvious use of RFC-XXXX as a new digest format (or, if you prefer, the
conversion of existing digests to RFC-XXXX), and the obvious mapping that you'd
use (and that RFC-XXXX implies) leads to a digest that is not very palatable to
X.400.
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?
Well, yes! For the most part, I agree! (And you'll notice that my
implementation also agrees.)
Using your terminology, I view the parts of a multipart message as
attachments. Headers associated with most content types are restricted
to information that describes the attachment and does not include
other material that would normally appear in a P2 content.
The only exception for me is a "multipart" message (your "message" type) which
is special in the sense that it creates a FORWARDEDIPMSG, a new P2 content
part, and all the headers that ride along with the "multipart" content-type get
mapped into that.
The reason I don't use a "message" content-type is because if I do that and
define "multipart" so that it works like G3FAX or whatever (cannot have P2
content headers associated with it), then there's no X.400 mapping for
"multipart" -- you would either have to move the parts under "multipart" up to
the level where the "multipart" appeared (loss of structure results) or create
an extra FORWARDEDIPMSG level (in which you can no longer tell the difference
between "multipart" and a "message" bodypart that didn't have additional
headers). I don't like this, and so I use "multipart" in this special way.
The only disadvantage I see to using "multipart" this way is that it
forces you to use a bunch of boundary markers that you really don't need.
(I'm not concerned about the name here -- we're talking semantics, not
syntactic sugar.)
How about this approach? When "multipart" appears as a nested part, it
describes an entire 822 message, and the headers associated with it can include
P2 content headers. The parts under it are attachments. Then we add a
"singlepart" content-type, which is semantically identical to "multipart", but
can contain only a single part and thus does not need the boundary markers.
This is just to make things pretty; it is not useful otherwise.
I'm not sure this change will fly with the rest of the group, however.
It makes things look a little strange, for one thing, and I'm not sure
that X.400 interoperability is enough of a goal to force this level of
strangeness onto the RFC822 world.
Amazing, isn't it? We were basically in agreement all along, but spent more
time confusing each other than anything else. If we had a difference here, it
was that I was interpreting the RFC the way you thought it should be done,
while you interpreted it as saying what I thought it didn't say!
Ned