OK, I've retreated from my coding work so I can get back to this
X.400 to RFC-XXXX mapping stuff.
I'm going to repeat Peter's discription of his mapping here for
reference purposes.
*********
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-XXXX. (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 types defined for when the configuration info does not have a
defined mapping.
Going from RFC-XXXX 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.
*********
Thank you for laying out your mapping. It saves me the trouble of doing it.
Might I also say that your mapping contained no surprises for me.
One point you did not discuss here is how to deal with a nested multipart
content-type. I assume that you're not going to allow it to be nested, except
when it appears inside of a message RFC-XXXX attachment? If you allow multipart
content-types anywhere other than at top-level or within a message RFC-XXXX
attachment, there's an ambiguity -- you have to map it to a forwarded-ipm on
the X.400 side, since there's no other way to represent a multipart entity
within a multipart entity in X.400. But the reverse mapping will take this to a
message attachment that contains a multipart attachment, and bang, you've
created structure out of nowhere.
I'll assume that you're going to forbid their use where they would cause
an ambiguity.
You've ignored the Content-encoding header; I understand this and I'll
ignore it too for purposes of this discussion. However, I'll present
somewhat more fleshed out examples below since I think some meat on the
bones is necessary to get a feel for what is going on.
Anyway, here's my counter-proposal and mapping:
*********
A content-type of multipart implies that the message body consists of a series
of RFC-XXXX attachments -or- X.400 attachments (recall that forwarded-ipm is
itself a type of X.400 attachment). The way you determine how to map an
RFC-XXXX attachment to a corresponding X.400 attachment goes like this:
(0) If the content-type is multipart, the RFC-XXXX attachment maps to an
X.400 forwarded-ipm attachment unconditionally. Any other headers specify
additional P2 and delivery information that become part of the
forwarded-ipm. The RFC-XXXX attachments under this multipart content-type
then map recursively to X.400 attachments, using this same mapping.
(1) If the content-type is something other than multipart but is accompanied
by one or more headers that map to P2 content information, the RFC-XXXX
attachment is mapped to an X.400 forwarded-ipm attachment. This
forwarded-ipm attachments then contains a single attachment of the
type specified in the content-type header.
(2) If the content-type is something other than multipart and is not
accompanied by any P2 content information, the RFC-XXXX attachment maps to
a simple X.400 attachment of the appropriate type (the mapping of the
various content-types other than multipart to corresponding X.400
entities is outside the scope of this specification).
*********
That's it. Now, let's discuss the differences.
(0) Modulo the handling of message bodyparts in Peter's mapping, both of
these proposals provide a 1-1 and onto mapping from X.400 to RFC-XXXX
and vice versa.
(1) In the case where a multipart RFC-XXXX message contains nothing more than a
series of pure attachments that simply contain data and no headers (or,
if you prefer, content information), the mappings are identical.
(2) Peter's mapping maintains more the X.400 in a more obvious way when it
gets mapped to RFC-XXXX. X.400 types probably won't like my mapping as
much as his.
This topic, plus the following one, implicitly raises the question of
how far we want to go to make X.400 mapping easy versus making our
lives marginally harder.
(3) The structure of a very common entity in the 822 world, a digest, gets
more complex with Peter's proposal. Here an example of what Peter's digest
format would look like:
*********
From: "The Generic Digest" <digest(_at_)host(_dot_)domain>
To: "Digest Recipient" <recipient(_at_)host(_dot_)domain>
Subject: Volume 1 #1
Date: whenever
Content-type: multipart; 1-S; d8fud8du
--d8fud8du
Content-type: message
From: "First digest submitter" <submit1(_at_)host(_dot_)domain>
Subject: Generic first subject
Date: long before whenever
Content-type: text
A long generic first discussion.
--d8fud8du
Content-type: message
From: "Second digest submitter" <submit2(_at_)host(_dot_)domain>
Subject: Generic second subject
Date: somewhat before whenever
Content-type: text
A long generic second discussion.
--d8fud8du
*********
And here's my format for the same digest:
*********
From: "The Generic Digest" <digest(_at_)host(_dot_)domain>
To: "Digest Recipient" <recipient(_at_)host(_dot_)domain>
Subject: Volume 1 #1
Date: whenever
Content-type: multipart; 1-S; d8fud8du
--d8fud8du
From: "First digest submitter" <submit1(_at_)host(_dot_)domain>
Subject: Generic first subject
Date: long before whenever
Content-type: text
A long generic first discussion.
--d8fud8du
From: "Second digest submitter" <submit2(_at_)host(_dot_)domain>
Subject: Generic second subject
Date: somewhat before whenever
Content-type: text
A long generic second discussion.
--d8fud8du
*********
(4) Another case where things are more complex using Peter's scheme is
where you have a multipart content-type that contains two multipart
content-types.
I recommend that people whose eyes are beginning to cross skip this
example. You can search for (5) at this point...
Here's Peter's (I'm assuming here that Peter want to forbid multipart
except at top-level and with a message content-type):
*********
From: "Loves Structure" <structure-lover-1(_at_)host(_dot_)domain>
To: "Another Structure Lover" <structure-lover-2(_at_)host(_dot_)domain>
Subject: Four attachments in a pear tree
Date: whenever
Content-type: multipart; 1-S; d8fud8du
--d8fud8du
Content-type: message
Content-type: multipart; 1-S; djjfefep
--djjfefep
Content-type: text
First chunk of text.
--djjfefep
Content-type: text
Second chunk of text.
--djjfefep
--d8fud8du
Content-type: message
Content-type: multipart; 1-S; erueehnf
--erueehnf
Content-type: text
Third chunk of text.
--erueehnf
Content-type: text
Fourth chunk of text.
--erueehnf
--d8fud8du
*********
And here's the same message using my mapping:
*********
From: "Loves Structure" <structure-lover-1(_at_)host(_dot_)domain>
To: "Another Structure Lover" <structure-lover-2(_at_)host(_dot_)domain>
Subject: Four attachments in a pear tree
Date: whenever
Content-type: multipart; 1-S; d8fud8du
--d8fud8du
Content-type: multipart; 1-S; djjfefep
--djjfefep
Content-type: text
First chunk of text.
--djjfefep
Content-type: text
Second chunk of text.
--djjfefep
--d8fud8du
Content-type: multipart; 1-S; erueehnf
--erueehnf
Content-type: text
Third chunk of text.
--erueehnf
Content-type: text
Fourth chunk of text.
--erueehnf
--d8fud8du
*********
(5) Are there cases where Peter's mapping is simpler? The answer is yes;
this happens when you have an X.400 message that contains one
attachment which is itself a forwarded-ipm. Here's Peter's mapping
for such a thing:
*********
From: "Random Originator" <randomoriginator(_at_)randomsystem(_dot_)domain>
To: "Random Recipient" <randomrecipient(_at_)randomsystem(_dot_)domain>
Subject: Here's the message randomotherperson sent me the other day
Date: whenever
Content-type: message
From: "Random Other Person" <randomotherperson(_at_)randomsystem(_dot_)domain>
To: "Random Originator" <randomoriginator(_at_)randomsystem(_dot_)domain>
Subject: Random subject
Date: before whenever
Content-type: text
A long discussion.
*********
And here's mine:
*********
From: "Random Originator" <randomoriginator(_at_)randomsystem(_dot_)domain>
To: "Random Recipient" <randomrecipient(_at_)randomsystem(_dot_)domain>
Subject: Here's the message randomotherperson sent me the other day
Date: whenever
Content-type: multipart; 1-S; d8fud8du
--d8fud8du
From: "Random Other Person" <randomotherperson(_at_)randomsystem(_dot_)domain>
To: "Random Originator" <randomoriginator(_at_)randomsystem(_dot_)domain>
Subject: Random subject
Date: before whenever
Content-type: text
A long discussion.
--d8fud8du
*********
Now, I argue that the delimiters that you end up with by using
multipart are far from being superfluous, since they provide a clean set
of delimiters for the included part. However, you could add delimiters to
Peter's message content-type if you want, or you could define a singlepart
content-type for use with my mapping that doesn't have delimiters. In
other words, there are trivial modifications that can take this stuff
any direction you want. I personally favor one set of delimiters per
bodypart, but that's just my opinion.
(6) One way to look at this is to say that Peter is explicitly applying a
restriction of X.400 to RFC-XXXX -- the inability of X.400 to specify
a nested multipart structure without also specifying a full forwarded-ipm.
I simply state this; you can draw your own conclusions.
Well, that's enough for now. Comments from persons other than Peter or myself?
Ned