I've been thinking some more about this attachments versus message stuff,
and how an X.400 mapping should work. I've decided that there's some
things I like about how Peter proposed to do the mapping, and that a
slightly different union of his approach and my approach has some
real advantages.
Here's my new proposal: At the top level, headers contain some
X.400 envelope information, some X.400 content information, and information
about either one bodypart or the fact that the message contains multiple
bodyparts (i.e. a multipart content-type is specified). If a multipart
content-type is used, each part can either be a simple bodypart or
a FORWARDEDIPMSG. The way you tell the difference is by looking at the
part headers -- a FORWARDEDIPMSG is indicated if either the part has a
multipart content-type -or- it employs one of a group of headers (the
exact group has to be specified, but it definitely should include Subject:
headers and From: headers). If neither condition holds the part is
mapped to a simple X.400 bodypart, with the content-type and content-encoding
telling what sort of X.400 bodypart to create (we'll worry about how to
deal with bodyparts that don't have a simple X.400 equivalent elsewhere).
If either condition does hold a FORWARDEDIPMSG is created, the headers
provide whatever P2 content information they can for this nested message,
and the content-type information is interpreted in the same way as it
was at the top-level.
The question of what to do about headers that don't specify P2 content
information or part structure information remains open, and must be dealt
with. And once more there are no easy answers.
This mapping is invertible, uses as many headers as possible (my earlier
mapping did not), and is completely compatible with RFC-XXXX as it stands.
(I think fixing up some of the language so that it implies this sort of
mapping is still a good idea, however.) Moreover, it obviates the need to
create an additional content-type. If there's resistance to using
the multipart content-type in this way, we can either change the name or
define a synonym that can be used in appropriate places. Adding an
additional content-type for encapsulated messages is not only unnecessary,
it is not a good idea, since if you do so it will bust this nice mapping.
Does this sound acceptable?
Ned