I see no problem with discussing the X.400 specifications here, or in
IFIP-GTWY(_at_)ics(_dot_)uci(_dot_)edu (which is more or less idle for the
moment, but
I would hope that we could settle RFC-XXXX down before we spread out
to into new territory. So, I would suggest that we concentrate on
whether we have the right model for handling X.400 body parts, and
other body parts from other sources that we have to reckon with.
On this model issue, I feel that RFC-XXX has two problems:
1. The multipart mechanism includes headers in each part.
2. There's no Content-Type refering to an included message.
I've presented reasons why I think there are problems in previous
mails. This message suggests the changes.
I suggest the following changes to RFC-XXX:
1. Content-Type "multipart" implies that the message body is
structured as a series of parts of the following form with no
useful information before, between or after the parts.
-- delim
Content-Type: <value>
<data of form depending on value>
-- delim
2. Content-Type "message" implies that the message body is a
message formatted according to RFC-XXX. (Details as to whether the
"From " line is allowed/required, TBD).
Assuming the basic 1148 mappings are already in place, here's a quick
sketch of the X.400 mapping.
A P2 message with multiple body parts maps to a "multipart" message,
with each part representing one body part. If there's just one part,
the multipart can be eliminated and the inner Content-Type carried at
the outer level.
The IA5 bodypart maps to "text". The forwarded-ipm recursively maps to
the "message" body part. Undefined maps to "binary". Others are
mapped to Content-Types according to configuration information. There
will be few other type defined for when the config info does not have a
defined mapping.
Going from RFC-XXX to P2, a multipart message maps to P2 with multiple
body parts. Other messages are treated as if they were a multipart
message with one part. For each part, the body part mapping above is
reversed, including mapping "message" recursively to forwarded-ipm. If
the config info does not describe the mapping, the whole part is
carried in a TBD externally-defined body part.
Sorry to be so brief, but I got to go.
Pete