I have written a document specifiying a possible conversion between MIME
and X.400/88.
I will bring it to the San Diego IETF, and see if the X.400-ops groups and
822ext groups are interested in seeing if this can be made into a standards
track RFC.
The document is enclosed.
Due to the volume of traffic on non-X.400 matters on the ietf-822 list, and
the close relation between this document and RFC-1148, I would prefer to
have the discussion mostly on the list ifip-gtwy(_at_)ics(_dot_)uci(_dot_)edu,
which has
not had much traffic of late.
Harald Tveit Alvestrand
UNINETT, Norway
....all too many other titles...
DRAFT RFC/RARE TECHNINCAL DOCUMENT
A mapping between X.400/88 and messages structured according to RFC-MIME
and RFC-HDR.
Updates: RFC-1148bis, RFC-88to84downgrading
Status of this memo
===================
This RFC specifies a standard for the Internet community.
Hosts that operate RFC1148-compliant gateways are expected to
implement this standard.
ALTERNATIVE:
This RFC specifies a proposed standard for the Internet community.
Hosts that operate gateways between X.400-based systems and the
Internet are encouraged to implement this standard.
This document will be reviewed by whatever exists of the following
groups before being submitted as Internet draft:
IETF 822-ext
IETF X400-ops
RARE WG1
Discussion is preferably carried out on the list
ifip-gtwy(_at_)ics(_dot_)uci(_dot_)edu
Distribution of this memo is unlimited.
1. Introduction
===============
Since 1988, the X.400 standard has been able to handle messages of
any defined type.
In the same period of time, this facility has not been widely used,
perhaps because the applications now present did not support it, and
the number of mail systems in fact supporting X.400/88 was limited.
In 1992, the Internet Mail system, RFC-822, gained the possibility of
sending messages containing things that were not ASCII text, through
the adoption of the RFC called MIME.
This document attempts to provide for the transfer of any document
that may be represented in MIME as an X.400 message, and vice versa.
This document is structured into 5 general parts:
- Introduction (this part)
- General principles, which gives the design goals that are followed
- Detailed mappings, which provides the bit-level conversion to be
applied
- X.400/84 interworking, which provides for things to take care of
when converting the messages to X.400/84.
- Operational principles, which cover guidelines on how and when to
convert messages inside an X.400/88 network when the capabilities of
the receiving UA are not known to be adequate for handling the
messages to be transferred.
<SHOULD THIS BE ITS OWN RFC????>
2. General principles
=====================
We should not reinvent the wheel.
Whenever there is a predefined way of representing the information
carried in one protocol on the other side, one should use that,
rather than invent a new way.
But since both MIME and X.400 are extensible standards, it is
inevitable that there will be cases when a gateway has to handle
messages for which there is no close equivalent in the other system,
leading to the need for an ultimate fallback rendition.
The set of applicable conversions will grow over time, as experience
with both MIME and multimedia X.400 grows. Therefore, a registration
authority, administered by IANA, is set up; a proforma for conversion
registration is specified in Appendix X.
We should also expect that there will be cases where one gateway
chooses a different representation than another for a particular
message. We should make every effort possible to ensure consistency
between the two. In particular, when one chooses a "not well deployed
body part", and another chooses "MIME fallback", the result when the
message arrives at a user agent that does not implement "not well
deployed body part" should be the same.
This affects X.400 systems that are not Internet gateways.
3. Detailed mappings
====================
3.1 RFC-MIME to X.400
3.1.1 Ultimate fallback
If no close equivalent exists, the message is transferred as a
MIME-body-part.
MIME-body-part EXTENDED-BODY-PART
PARAMETERS MIME-parameters
CONTENTS OCTET STRING -- Body after removing all transport encodings
MIME-parameters ::= SEQUENCE {
Content-type IA5String, -- Up to the first ;
Content-type-parameters IA5String OPTIONAL, -- Anything after -
-- may be set of???
Other-parameters RFC-822-Parameters -- adopted from RFC-1148bis
}
3.1.2 TEXT
3.1.2.1 TEXT/PLAIN
If character-set is USASCII, map to IA5text.
If character-set is other, and representable in GeneralText, use
GeneralText.
If character-set is MNEMONIC, or unknown, use MIME-body-part.
OPTION: If the gateway implementor so desires, one may scan the body
of the message to see if all the characters invoked by Mnemonic fit
into the maximum of 4 graphic character sets that are allowed by
GeneralText, and use that.
3.1.2.2 TEXT/RICHTEXT
Use MIME-body-part. It is FOR FURTHER STUDY whether a RichText DTD
will be written that allows RichText to be sent as SGML.
3.1.2 MULTIPART
3.1.2.1 MULTIPART/PLAIN
Mapped to the multipart facility of X.400.
Each component is mapped according to these rules again. A component
that is itself MULTIPART is mapped onto the Multipart-Body type.
Multipart-Body EXTENDED-BODY-PART
PARAMETERS Multipart-Parameters
CONTENT SEQUENCE OF X400-Body-part
::= (object-identifier-here)
Multipart-Parameters SEQUENCE {
MultipartType ENUMERATED {plain(1), alternative(2), parallel(3)}
}
3.1.2.2 MULTIPART/DIGEST
Each message is mapped into a P22.ForwardedIPMessage according to
RFC1148bis rules, unless a different Content-Type is specified on the
part.
3.1.2.3 MULTIPART/ALTERNATIVE
Mapped onto the Multipart-Body type.
3.1.2.4 MULTIPART/PARALELL
Mapped onto the Multipart-Body type.
3.1.3 MESSAGE
3.1.3.1 MESSAGE/RFC822
Mapped onto the P22.ForwardedIPMessage according to RFC1148bis, as
modified by this RFC.
3.1.3.2 MESSAGE/PARTIAL
Mapped onto MIME-body-part.
OPTION for gateway implementors: Store the message on a wait-queue,
and wait until all the components arrive. If all the components do
not arrive in a reasonable time, or if the components' total size
exceeds the maximum size that can reasonably be handled in a single
message by the X.400 network, forward as separate messages with
MIME-body-part.
RATIONALE: there is no guarantee that the other components did
not travel over another mailpath, so complete reassembly at one
gateway is not always possible.
The size limitation WILL be hit; it is possible to order the source of
X11R5 by E-mail.
3.1.3.3 MESSAGE/EXTERNAL-BODY
Mapped onto MIME-body-part.
RATIONALE: It would at first seem possible to fetch the
external-reference and include it into the message. However, this
will often turn very short messages into very long ones, and will in
some cases (for instance, where the reference is to a dataset that
changes over time) defeat the purpose of the reference. It is better
to use fallback until X.400 gets exernal-reference mechanisms.
3.1.4 APPLICATION
3.1.4.1 APPLICATION/OCTET-STREAM
If any parameters are given to this type, use MIME-body-part.
If not, mapped onto Bilaterally-Defined body part.
RATIONALE: the Bilaterally-Defined body part is a widely deployed
means of interchanging data between X.400 systems, but bears no
possibility of carrying the parameters around.
3.1.4.2 APPLICATION/POSTSCRIPT
Mapped onto MIME-body-part.
3.1.4.3 APPLICATION/ODA
Mapped onto the ODA extended-body-part.
3.1.4.4 APPLICATION/X.400-BODY
Turned into a body part with the same OID as the parameter given, and
the same octets of content.
OPTION: If it is a body part that is known to the gateway to be of
basic body part type, it may be downgraded from "extended" to "basic"
body part. This is not mandatory.
RATIONALE: This rule, paired with its mate in the other direction,
offers full and free transfer of all X.400 body parts across RFC-822
based networks where MIME may be handled.
3.1.5 IMAGE
In contrast with the Internet world, the only well-defined and
reasonably well-deployed image format in X.400 is G3Fax, so this is
the format of choice for carrying two-level bitmaps. All other
encodings are FOR FURTHER STUDY.
Note that the size of images will be reduced by 25 % by removing the
Base64 encoding and carrying them as binary MIME-body-parts.
3.1.5.1 IMAGE/G3FAX
Mapped onto the G3Fax body part.
3.1.5.2 IMAGE/any other
Mapped onto MIME-body-part. If the images are two-level bitmaps of
reasonable size and resolution, they may be converted to the G3Fax
body part.
3.1.7 VIDEO, AUDIO and content-types not specified here
Mapped onto MIME-body-part.
The IANA will register new conversions between particular MIME body
parts and X.400 body parts; a proforma for registration is given in
Appendix X.
3.2 X.400 to RFC-MIME
3.2.1 Deciding between MULTIPART and not MULTIPART
A message with a single body part is mapped onto a single message,
with the content-type in the original RFC-822 header.
A message with two or more body parts is mapped onto a
MULTIPART/PLAIN message. The MULTIPART/DIGEST subtype is not generated.
3.2.2 Ultimate fallback handling
When the body type is completely unknown to the gateway, or if the
gateway has no knowledge of any remotely similar MIME type, an
ultimate fallback is required.
This is defined as follows:
Content-type: APPLICATION/X.400-BODY; oid=<oid>
The BNF for OID is
oid ::= "{" oidnums "}"
oidnums ::= oidnum lwsp oidnums | NULL
oidnum ::= string "(" number ")" | number
The use of tagged numbers is encouraged, because this gives a hint of
the content type even when it is not known to the recipient.
When comparing two OIDs, only the numbers are significant.
QUESTION: Should this be done in 2 parameters, one all-numeric and
another all-text, in order to ease matching of OIDs to processors?
The body of the message is the complete sequence of bytes for the
extended body part, including the introducing tag.
The reason why the OID is extracted and put into the heading is to
make it easier to call different interpreting functions on different
types of X.400 body.
If a basic body part has to be encoded in this way, it is first
converted to the corresponding EXTENDED body part. The assignment of
object identifiers to the basic body parts is completely specified in
[X40088].
3.2.2 IA5Text
Map onto TEXT/PLAIN, with character set USASCII.
<NOTE: Check for conflicts between USASCII and IA5 IRV>
NOTE: If lines longer than 1000 characters exist, or if the body part
does not end with a CRLF, and the mail transport requires it,
transport encoding must be applied. Quoted-Printable encoding is
probably appropriate.
3.2.3 ForwardedIPMessage
Map onto Message/RFC-822.
3.2.4 GeneralText
Case 1: Character set is covered by USASCII, ISO-8859-X or ISO-2022-jp:
Map onto Text/Plain, with the character set indicated.
This may cause transformation of the message to a different character set.
Case 2: Character set is outside defined MIME charsets.
Map onto Text/Plain, and use Mnemonic encoding.
RATIONALE: At the moment of writing, Mnemonic is the only character
set-like object that is fairly well defined and covers all character
sets that are likely to occur in E-mail.
3.2.4 Bilaterally-defined
Map onto Application/Octetstring, without any parameters.
3.2.5 MIME-body
Map in the obvious way.
3.2.6 Multipart-body
If multipartType is plain, convert to Multipart/Plain.
If multipartType is alternative, convert to Multipart/Alternative.
If multipartType is paralell, convert to Multipart/Paralell.
Apply the conversion rule to each bodypart.
4. Downgrading for UAs that are not able to handle the message
==============================================================
4.1 Deciding when to downgrade
In some cases, the service delivered to the user is improved if the
message is converted to a format that the recipient's UA can
understand.
In other cases, the mail system has insufficient information to be
able to know if the recipient UA is able to handle the message or
not.
We identify three cases here:
1) The recipient UA is known to be able to handle the message, or the
next MTA can take necessary action.
No problem. Send the message.
2) The recipient UA is known not to be able to view this message in
any reasonable fashion. This will most often occur at the MTA of the
recipient user, or at a gateway into another mail system with more
limited capabilities.
If conversion is possible, and conversion is allowed by the sending
user, convert the message into a form viewable by the enduser
(including the possibly irritating "there was a nice picture here,
but you are not allowed to see it" style of "conversion").
Otherwise, nondeliver the message.
3) Insufficient information exists to decide whether or not the user
can handle the message, but there exists information that identifies
the user as handling some of it, or some body parts that it can be
covnerted to.
If conversion is possible and allowed, convert.
If conversion is prohibited by the sender, send the message.
DISCUSSION: There are actually three different ways to solve the last
case.
a) If we do not know that delivery is possible, convert or
nondeliver. This is the "strict enclave" model.
b) If we do not know that delivery is possible, just send. This is
the approach taken by RFC-MIME.
Since X.400 user agents are generally less capable of handling
unknown body parts than RFC-822 (there is no equivalent to "just show
the text"), this is likely to be a less than popular approac.
c) The approach outlined above ("strict enclave with blastout"). This
allows the end-user to send to anyone (including a mailing list)
without worrying about the recipient's mailbox being filled with
garbage, and still allows the user to override the safeguards if
he/she knows positively that the other user is able to handle the
message, and this information has just not entered the tables of the
intervening systems yet.
If conversion is possible, and allowed
4.2 Downgrading rules
The object of the downgrading rules is:
- Whenever the target UA supports some part of the required
functionality, we should map messages using only this functionality
correctly.
- When the target UA does not support anything, it should not be
worse off than when handling messages through an RFC-1148bis gateway
that does not understand RFC-MIME.
However, all X.400 UAs support multipart messages, so this facility
should always be used.
If the bodypart is the only bodypart in the message, and the message
is in X.400/88 format (P22), RFC-822 headers indicating content type
should be inserted as Extended-Headers.
If the bodypart is the only bodypart in the message, and the message
is in X.400/84 format (P2), and cannot be upgraded to P22, put the
headers into an extra IA5 body part.
In both cases, the resulting message should be the same as if it had
passed through an RFC-1148bis gateway that did not know about MIME.
If there are multiple body parts in the message, insert the header
Content-type: Multipart/plain
in the same fashion.
This indicates to knowing agents that any IA5 body part should be
interpreted as a complete MIME body part, which may have MIME
functionality. Any real IA5 body part must then have a blank line
prepended to it in order to be MIME-conformant.
4.2.1 Downgrading MIME-body-part
Convert to IA5 body part by:
- Inserting the headers
- Inserting a blank line
- Inserting the body, in quoted-printable or Base64 encoding, at the
gateway implementor's choice.
4.2.2 Downgrading Multipart (plain)
This body variant is only used when a message consists of a
Multipart/Plain inside another Multipart, a rather bizarre way of
sending messages. It must be handled, but we accept loss of
functionality here.
Convert to a sequence of body parts. This means that the nesting of
body parts is lost, but the content of each body part is retained.
COMMENT: It might be an idea to insert an IA5 bodypart containing a
message telling that this bodypart sequence was the result of such a
downgrade. Then again, this might confuse more than it enlightens.
4.2.3 Downgrading Multipart (alternative)
Pick the last (most complex) bodypart that the user is able to
understand. Only if the first (least complex) body part is not
understandable by the user should conversions be applied.
COMMENT: This is based on the premise that a sender that goes to the
trouble of sending a Multipart/Alternative wants the message to be
rendered to the end-user in a format he has sent, rather than some
random, possibly lossy conversion being applied to one of his other
formats. The choice is somewhat ad hoc.
Another option would be to choose the last (most complex) body part
for which a non-loss conversion to a format understood by the
end-user exists, and convert that.
4.2.4 Downgrading GeneralText
This may be downgraded into ISO6937 according to ENV......, or to
Teletex or IA5.
If downgrading to a character set that does not support the full
repertoire used by the message, one option is to use Mnemonic
encoding (Keld Simonsen encoding) to represent the missing
characters. This is possibly more informative to the end-user than
simply replacing the unsupported characters with "?".
COMMENT: A problem exists, in that when Keld Simonsen mnemonics are
used in IA5Text, there is no way to specify that they are used.
In X.400/88, this may be solved by adding an extended header with the
content "Content-type: text/plain; charset=mnemonic"; in
X.400/84, this header may be added to the "RFC-822-Headers:" body
part inserted in front of the real message.
If there are several body parts to the message, the solution of
inserting the "Content-type: multipart" in the headers, and adding
the necessary headers to each IA5text body part must be used.
In both cases, the message would look exactly equal to an RFC-MIME
message that had passed through a naive RFC-1148bis gateway.
COMMENTS ON CONVERSIONS:
If the reasoning above is strictly followed, we should be reasonably
sure that messages passing around combinations of
RFC-822 -> 1148bis/MIME -> X.400/88 -> Downgrading -> X.400/84 -> RFC822
should be reasonably safe against serious loss of information.
One potentially damaging problem is that RFC1148bis (pre-MIME)
gateways do not generate messages that can be divided into parts
according to RFC-MIME, but to the older RFC-1058 standard; it is hoped
that this rather small change will soon be made to the gateway
software, or that mail readers will be able to understand the rather
weird combinations of headers and delimiters.
5. SECURITY CONSIDERATIONS
==========================
No security issues apart from those that are described in the base
message standards (RFC-MIME and X.400) are known to exist.
Author's address
================
Harald Tveit Alvestrand
SINTEF DELAB
N-7034 Trondheim
NORWAY
Tel: +47 7 59 70 94 (timezone GMT+1)
Email: Harald(_dot_)Alvestrand(_at_)delab(_dot_)sintef(_dot_)no
APPENDIX A: Proforma for registering new conversions
====================================================
REGISTRATION OF CONVERSION TO BE USED WITH RFC-MIME.400
We hereby request that the IANA registers the following conversion:
X.400 body part: ISO 61234 smell <textual description>
with OID: 1 61234 5 19 38 <numeric-only form>
MIME body part: Application/smell <must also be IANA registered>
The syntax and semantics of the X.400 body part is specified in:
ISO 61234, "Classification of smells by strength and group"
Addendum 24, "Binary encoding of smell values for E-mail transfer"
<other alternatives: RFC-XXX
Other quotable document
available from the author on request
a company secret>
The syntax and semantics of the MIME body part is specified in:
This application form (by implication)
<Alternatives: RFC-XXX
other quotable document
not specified>
Conversion rule:
The OCTET STRING inside the body part is used as-is in the MIME
message. The following parameter rules apply:
The "strength" attribute is mapped into a parameter "strength=",
with the parameter value being the name of the named-number.
<May also be specified in a separate RFC, but must always be
implementable by outside agents>
Downgrading rules:
This body part cannot be downgraded. Suggested replacement text is:
"There was something smelly here, but it has been removed"
<Alternative: Can be converted to XXX by.... with/without loss of
information>
Security considerations:
Direct representation of smells with strength larger than
"exhilarating" has been known to have serious effects on the
recipient's state of mind, and should be avoided.
Person responsible for this conversion:
Dr. I. Feelgood
Sweet Smell Inc.
1234 Notodden
Norway
Tel: +12 34 56 78 90
Email: i(_dot_)feelgood(_at_)smell(_dot_)com
Example converter:
Send message to be converted to:
Internet host: rose-mail.smell.com
X.400 host: C=no;ADMD=pricey;PRMD=stinky;MTA=rose-mail
Source code (for PP) is available from:
Anonymous FTP from rose-mail.smell.com, directory smellmail, file
smellgate.tar.Z