Let's say the X.400 message has one body part which is a ForwardedIPM
with two body parts, say, text and g3FAX. What does this map to? It
seems like the minimum is:
It maps to a multipart message with one part. That part in turn has its own
headers, which identify it has a multipart message and include the DELIVERYDATE
and DELIVERYINFO stuff that's part of a FORWARDEDIPM. This inner multipart
message has two parts of its own -- the text and the g3FAX parts from the
original message. Simple, clean, and totally invertible. Your example
encoding follows this model.
Is there a way to do without the outer multipart? It seems that using
the multipart mechanism (in single part mode) just to carry a message
is overkill. Of course there's "message", but that implies carrying
the forwarded message in ASN.1 rather than broken out.
It is overkill if you don't care about reproducing the structure. If you do,
you map exactly. If you don't you can say "aha, that outer multipart thingie
isn't needed, let's toss it". What you do with the deliver information is
a problem; I guess you either toss it or merge it into the main set of headers.
But these are choices for a gateway to make. If a gateway decides to
flatten out any multipart parts with only one part, that is certainly
a well-defined and doable. Structure will be lost, however. I think it is
important that we provide facilities for representing the structures
of X.400 correctly, even if we later on decide that structural compatibility
is not an issue and we don't use them.
The important thing to note is that modulo that extra delivery information,
the use of a FORWARDEDIPM in X.400 was _exactly_ the same sort of overkill.
Why is the X.400 version of the message exempt from your complaint?
Again, it seems like the culprit is that the notion of recursive
messages is tied up with the multipart mechanism.
I'm sorry, but I think you've done nothing more than create a straw man here.
The RFC-XXXX message reproduces the X.400 message structure exactly. But
somehow, when it was in X.400 form, it was OK to have redundant structure, but
once you convert it the extra structure is bad. This is not logical.
I appreciate the elegance of Nathaniel's scheme -- that there's just
one header mechanism -- but I just don't think it works out right.
I have implemented a complete mapping between X.400-1984 and an early draft of
RFC-XXXX. (X.400-1988 and current draft RFC-XXXX don't change the structure.)
The mapping is demonstrably structurally 1-1 and onto. The fact that it is is
both 1-1 and onto means, in mathematical terms, that there's no fat and it's
not too lean -- every feature of RFC-XXXX is used, none are wasted. If you
eliminate one, you cannot map X.400 without information loss. If you add one,
you can now build messages in RFC-XXXX format that cannot be mapped to X.400
without information loss.
I think we're stuck with the notions of both message headers (the 822
kind) and part headers. Part headers contain the information
associated with each part of a multipart content (like Content-type and
Content-encoding).
Yes, but I object to creating two syntaxes when only one is needed. That's
why the headers have the same format, even though the information they carry
is distinct. For any given header you can tell if it applies to the message
or to the message data (what you call the part headers).
X.400 is by no means free from similar problems. Once you get into the grungy
details of writing a gateway X.400's separation of messages into envelope and
content seems at best arbitrary and at worst just plain wrong in some
particulars. (I'd rather not bore this group with an X.400-specific discussion
of these points, if you don't mind.)
For the case where there are multiple parts, the message Content-type
is "multi-part" and each part's Content-type identifies the data for
that part. In the case where a message has just one part, the part
headers are merged with the 822 headers. The "message" content type is
defined to mean that the data is another 822 message (which may contain
a content-type header).
As I said before, the introduction of a type that means "this is an
encapsulated 822 message" adds ambiguity rather than removing it. I agree that
it seems like a useful idea on first examination, but it is precisely because
it busts X.400 mapping (rather than fixing it), that I didn't advocate its
inclusion.
Now, there is a problem with X.400 mappings that we have not covered here.
Regardless of syntax, regardless of structure, an inherent characteristic of
the RFC822 world (and its associated philosophy) is extensibility. Message
headers are definitely extensible. Part headers are also extensible in
RFC-XXXX, and while we could by fiat say they aren't, I don't propose to do
this. (It implies that we not only know what we're doing, but we know what
everyone else needs to do, which is an arrogance I'd rather not indulge in.)
X.400, on the other hand, is not generally extensible (bodyparts are
extensible, but you cannot add arbitrary information at the envelope or content
level).
This means that you can define headers of one sort or another that you cannot
map to X.400. This is a real problem, and there are a couple of possible
solutions:
(1) Map the extra headers to a separate bodypart. RFC987 and RFC1148 both
recommend this approach, with the mapping being to a text bodypart.
However, it would be possible to define a new bodypart just for this
purpose, if you want to impose some structure on it.
(2) Just toss the headers. This has a number of advantages: it is simple,
and it doesn't clutter up the X.400 version of the message with trash.
On the other hand, you lose information.
I don't propose to decide this now; I'm simply including it here for
completeness.
(The current "message" type (the ASN.1
encoding of a forwarded message) doesn't seem too useful.)
Since there are mappings for all the other X.400 bodypart types, omitting this
particular one seems somewhat artificial. I agree that it does not seem to be
too useful, and I don't propose to use it, but the business of specifying
exactly how an X.400 mapping to RFC-XXXX is outside the scope of RFC-XXXX. If,
upon reflection, the folks who do that mapping (this will probably be Steve
Kille, but I'm not counting on that) decide that they need this bodypart, I'd
feel kind of dumb if I'd removed it. Just because it is there does not mean
that an X.400 mapping RFC would ever use it.
Ned