OK, I've retreated from my coding work so I can get back to this
X.400 to RFC-XXXX mapping stuff.
Unfortunately I'm going to have to retreat into other work for awhile :-(.
I'll try to get back to your analysis (looks good!) later. On the
multipart part point,
One point you did not discuss here is how to deal with a nested
multipart content-type.
Yeah. I'm still not sure of the "right thing" to do here. From one of
my messages sent Saturday
So, how does one handle multipart parts in X.400? There are three ways:
1. disallow it.
2. use forwarded-ipm
3. create a new body part type
Multipart parts can be disallowed by specifying that "multipart" can
only be used as a content-type at the 822 message level, not as a
content-type at the attachment level.
You can use forwarded-ipms by leaving out the envelope and headers
(which technically isn't legal as IP-message-id is not optional).
You can create a new X.400 body part as follows
EXTENDED-BODY-PART-TYPE
DATA Body
::= <some OID to be defined>
or, in other words, use an externally-defined body part with no
parameters and using single-asn1 where the ANY is the X.420 Body type
(which is a sequence of body Parts).
My personal ordering of the choices would be: 3 (best), 1, 2. Other
opinions? How much do we like recursive multiparts? (Remember that
recursively included messages containing multiple parts is a different
matter).
The basic problem is that there's no clean mapping of a multipart part
to X.400 as X.400 has multiple parts built in to the basic structure of
P2 but it's only a one level structure.
So what do we do about it? I don't really like any of the options.
The negatives:
If we disallow multipart parts (option 1), we've left out some
nice clean recursive structure.
If we map a multipart part to a forwarded-ipm (option 2), we're not
using forwarded-ipm for what it's intended. We're just using the
fact that an ipm contains a list of body parts and we leave the
other parts (envelope and headers) empty. This may cause problems
on the X.400 side.
Also note that option 2 leads to a message that is not technically
legal in X.400 as the heading must contain an IPM-Id.
If we map to an externally-defined body part (option 3), we run
into the possibility that recipient X.400 implementations will not
recognize the part.
Are there other factors?
I like option 3 because it seems like the cleanest, most direct way to
"fix" X.400. And I suspect it's going to be a fact of life, that for
some time some of the body parts generated by the gateways will not be
recognized by X.400 systems -- we can carry TeX in RFC-XXX but how many
X.400 systems will recognize the externally-defined on the X.400 side?
Hopefully, we can get the multipart body part advertised fairly widely
with the hope that many X.400 implementations will handle it.
I put option 2 second for a strange reason. My thinking is something
like "If this recursive multipart structure is useful, let's get the
X.400 people to adopt it (option 3). If it's not useful, then let's
take it out of RFC-XXX (option 1)".
Other opinions?
Pete