This having been said, I'm not opposed to splitting the X.400
content-type definitions out into a companion RFC.
This is the right way to go for the reasons I'll state below. The
companion RFC should be the X.400 <-> 822 RFC (which I'll call RFC
1. It is important to avoid wrong definitions. We can't have RFC-XXX
and RFC 1148++ specifying contradictory things. But that is exactly
the course we're on right now, because RFC-XXX specifies that the
Content-Type "message" denotes the ASN.1 encoding of the BodyPart,
whereas RFC-1148++ is likely to specify it as a recursive mapping of P2
to 822. Similarly, I'm pretty sure the FAX format used by existing
tools is not the ASN.1 form as specified in RFC-XXX.
2. It is also important to avoid misinterpretations. If we leave in
the X.400 Content-Types, those not "in the know" might think that
RFC-XXX defines an agreed upon X.400 <-> 822 mapping.
3. RFC-XXX is properly an open-ended framework which allows new
Content-Types to be defined well after RFC-XXX itself has stabilized.
We should use this mechanism so that when agreement is reached on the
X.400 <-> 822 mapping, *then* the X.400 Content-Types are defined.
Doing so before agreement is reached serves no useful purpose and may
I'd like to continue
the discussion of this material on this list, however, since I think
these bodyparts are generally useful -- no matter how much you happen
to hate X.400, there are some bodyparts there that you may want to use
(G3Fax, for instance). And if the FAX people _don't_ want to use the
G3Fax bodypart, we need to know that too. Further than this I'm not
willing to go, since I happen to think that these bodyparts are
IMPORTANT and NEED to be specified.
I too would like to hear from the FAX people -- are they on this list?
But for the X.400 types in general, I think we should move the
discussion to something like ifip-gtwy.