As per Relevance of the word messages, we have this rfc below:
Network Working Group H.
Request for Comments: 1496 SINTEF
Updates: 1328 J.
NetConsult
K.
Control Data Systems, Inc
August 1993
Rules for Downgrading Messages from X.400/88 to X.400/84
MIME Content-Types are Present in the
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
Table of
1. Introduction ............................................... 1
2. Basic approach ............................................. 2
3. Conversion rules ........................................... 3
3.1 EBP conversions to Basic .................................. 3
3.2 Encapsulation format ...................................... 3
4. Implications ............................................... 4
5. Security Considerations .................................... 4
6. Authors' Addresses ......................................... 4
7. References ................................................. 5
1.
Interworking between X.400(88) and MIME is achieved by [4],
complements RFC-1327 [2], which in turn specifies the
between X.400(88) and RFC-822 based mail
Interworking between X.400(88) and X.400 (84) is achieved by RFC-1328
[3]. That document does not describe what to do in the case
body parts arrive at the gateway that cannot be
represented in the X.400(84) system
This document describes how RFC-1328 must be modified in order
provide adequate support for the scenarios
SMTP(MIME) -> X.400(84)
X.400(84) -> SMTP(MIME
Alvestrand, Romaguera & Jordan [Page 1]
RFC 1496 HARPOON August 1993
It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is
obsoleted
NOTE: A desireable side-effect of HARPOON is that a
method for the identification and transmission of multimedia
binary data (like spreadsheets) between X.400/84 UAs is achieved
While this method is not compatible with current
approaches, we believe that it requires less invasive changes
current UAs than other possible methods
This memo updates RFC 1328. HARPOON is a pure name, and has
meaning. Please send comments to the MIME-MHS mailing
.
2. Basic
The approach is to imagine that the connection X.400(84) <->
SMTP(MIME) never happens. This, of course, is an illusion, but can
a very useful illusion
All mail will therefore go on one of the
X.400(84) -> X.400(88) -> SMTP(MIME
SMTP(MIME) -> X.400(88) -> X.400(84)
when it goes between a MIME user and an X.400(84) user
The approach at the interface between X.400(88) and X.400(84) is
o Convert what you
o Encapsulate what you have
o Never drop a
Of course, for X.400/88 body parts that are already defined
X.400/84, no downgrading should be done. In particular, multi-
messages should remain multi-body messages, IA5 messages
IA5 messages encoded as Extended Body Parts) should remain IA
messages, and G3Fax messages should remain G3Fax messages
Alvestrand, Romaguera & Jordan [Page 2]
RFC 1496 HARPOON August 1993
3. Conversion
3.1. EBP conversions to
Some body parts are defined by X.400(88) as having both a Basic
and an Extended form. These are listed in Annex B of X.420.
For all of these, the transformation from the Extended Body Part
the Basic Body Part takes the form of putting the PARAMETERS and
DATA members together in a SEQUENCE
This transformation should be applied by the gateway in order
allow (for example) X.400(88) systems that use the Extended form
the IA5 body part to communicate with X.400(84) systems
3.2. Encapsulation
For any body part that cannot be used directly in X.400(84),
following IA5Text body part is made
- Content = IA5
- First bytes of content: (the description is in USASCII, with
escape sequences used to represent control characters):
MIME-version: \r\
Content-type: \r\
Content-transfer-encoding: printable or base64>\r\
terminated by\r\n
\r\
proper encoding
All implementations MUST place the MIME-version: header first in
body part. Headers that are placed by [2] and [4] into other parts
the message MUST NOT be placed in the MIME body part
This includes RFC-822 headings carried as heading-extensions,
must be placed in a new IA5 body part starting with the string "RFC
822-HEADERS", as specified in [2], Appendix G
Other heading-extensions are still handled as described in chapter 5
of RFC 1328: They are dropped
Since all X.400(88) body parts can be represented in MIME by
the x400-bp MIME content-type, this conversion will never fail
Alvestrand, Romaguera & Jordan [Page 3]
RFC 1496 HARPOON August 1993
In the reverse direction, any IA5 body part that starts with
token "MIME-Version:" will be subjected to conversion according
[4] before including the body part into an X.400(88) message
4.
The implications are several
- People with X.400(84) readers who have the ability to save
to file will now be able to save MIME multimedia
- People who can use features like the "Mailcaps" file to
what to do about a bodypart can now grab implementations of
that can run as subprograms and achieve at least some
5. Security
The security considerations in [1] and [4] (beware of trojans
can hit you if your UA automagically starts programs for you) are
relevant also for X.400(84) systems
6. Authors'
Harald Tveit
SINTEF
N-7034
EMail: Harald.T.Alvestrand@delab.sintef.
Kevin E. Jordan, ARH215
Control Data Systems, Inc
4201 Lexington Avenue
Arden Hills, MN 55126
EMail: Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.
James A.
NetConsult
Mettlendwaldweg 20
3037
EMail: Romaguera@netconsult.
Alvestrand, Romaguera & Jordan [Page 4]
RFC 1496 HARPOON August 1993
7.
[1] Borenstein, N, and N. Freed, "MIME: Mechanisms for
and Describing the Format of Internet Message Bodies", RFC 1341,
Bellcore, Innosoft, June 1992.
[2] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
and RFC-822", RFC 1327, University College London, May 1992.
[3] Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading",
1328, University College London, May 1992.
[4] Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson
"Mapping between X.400 and RFC-822 Message Bodies", RFC 1494,
SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc, Dover
Consulting, Inc., Soft*Switch, Inc., August 1993.
Alvestrand, Romaguera & Jordan [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
