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
1148++).
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
be detrimental.
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.
Pete