view Side-By-Side changes
Date: Tue, 09 Apr 2002 05:07:49 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 09 Dec 1992 04:35:00 GMT
ETag: "3ddde2-2096-2b257774"
Accept-Ranges: bytes
Content-Length: 8342
Connection: close
Content-Type: text/plain
draft HARPOON May 92
HARPOON
Rules for downgrading messages from X.400/88 to X.400/84 when
MIME content-types are present in the messages
Sun Aug 30 23:40:19 MET DST 1992
Harald Tveit
Network Working Group H. Alvestrand
Request for Comments: 1496 SINTEF DELAB
Harald.T.Alvestrand@delab.sintef.no
Jim
Updates: 1328 J. Romaguera
NetConsult AG
Romaguera@cosine-mhs.switch.ch
Kevin
K. Jordan
Control Data Systems, Inc.
kej@mercury.udev.cdc.com
August 1993
Rules for Downgrading Messages from X.400/88 to X.400/84 When
MIME Content-Types are Present in the Messages
Status of this Memo
This document is RFC specifies an Internet Draft. Internet Drafts are
working documents of IAB standards track protocol for the Internet Engineering Task Force
(IETF), its Areas,
community, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid requests discussion and suggestions for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material or
to cite them other than as a "working draft" or "work in
progress." improvements.
Please check the I-D abstract listing contained in each
Internet Draft directory refer to learn the current status edition of this
or any other Internet Draft.
If consensus is reached in the IETF MIME-MHS Interworking
Working Group, it will be submitted to the IESG asking that
Alvestrand et al Expires March 28 1993 [Page 1]
draft HARPOON May 92
it be recommended to the IAB as a Proposed Standard protocol
specification.
HARPOON stands "IAB Official Protocol
Standards" for Holistic Approach to Reliable Provision of
Open Networking, the standardization state and status of this protocol.
Distribution of this memo is used solely to catch the eye unlimited.
Table of
readers.
Please send comments Contents
1. Introduction ............................................... 1
2. Basic approach ............................................. 2
3. Conversion rules ........................................... 3
3.1 EBP conversions to the MIME-MHS mailing list
<mime-mhs@surfnet.nl>
Alvestrand et al Expires March 28 1993 [Page 2]
draft HARPOON May 92 Basic .................................. 3
3.2 Encapsulation format ...................................... 3
4. Implications ............................................... 4
5. Security Considerations .................................... 4
6. Authors' Addresses ......................................... 4
7. References ................................................. 5
1. Introduction
Interworking between X.400(88) and MIME is achieved by [MAPPING], [4], which modifies
complements RFC-1327 [RFC 1327], [2], which in turn specifies the interworking
between X.400(88) and RFC-822 based mail.
Interworking between X.400(88) and X.400 (84) is achieved by RFC-
1328 [RFC 1328]. RFC-1328
[3]. That document does not describe what to do in the case where
body parts arrive at the gateway that cannot be adequately
represented in the X.400(84) system.
This document describes how RFC-1328 must be modified in order to
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 NOT
obsoleted.
NOTE: A desireable side-effect of HARPOON is that a standardized
method for the identification and transmission of multimedia and
binary data (like spreadsheets) between X.400/84 UAs is achieved.
While this method is not compatible with current proprietary
approaches, we believe that it requires less invasive changes to
current UAs than other possible methods.
This memo updates RFC 1328. HARPOON is a pure name, and has no
meaning. Please send comments to the MIME-MHS mailing list
<mime-mhs@surnet.nl>.
2. Basic approach
The approach is to imagine that the connection X.400(84) <->
SMTP(MIME) never happens. This, of course, is an illusion, but can be
a very useful illusion.
All mail will therefore go on one of the paths
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 can
o Encapsulate what you have to
o Never drop a message
Of course, for X.400/88 body parts that are already defined in
X.400/84, no downgrading should be done. In particular, multi-body
messages should remain multi-body messages, IA5 messages including
IA5 messages encoded as Extended Body Parts) should remain IA5
messages, and G3Fax messages should remain G3Fax messages.
Alvestrand, Romaguera & Jordan [Page 2]
RFC 1496 HARPOON August 1993
3. Conversion rules
3.1. EBP conversions to Basic fallback
Some body parts are defined by X.400(88) as having both a Basic form
and an Extended form. These are listed in Annex B of X.420.
For all of these, the transformation from the Extended Body Part to
the Basic Body Part takes the form of putting the PARAMETERS and the
DATA members together in a SEQUENCE.
This transformation should be applied by the gateway in order to
allow (for example) X.400(88) systems that use the Extended form of
the IA5 body part to communicate with X.400(84) systems.
3.2. Encapsulation format
For any body part that cannot be used directly in X.400(84), the
following IA5Text body part is made:
Alvestrand et al Expires March 28 1993 [Page 3]
draft HARPOON May 92
- Tag = 14 (Bilaterally defined)
- Content = Octet string IA5String
- First bytes of content: (in (the description is in USASCII, with C
escape sequences used to represent control characters):
MIME-version: <version>\r\n
Content-type: <the proper MIME content type>\r\n
Content-transfer-encoding: <encoding>\r\n <quoted-printable or base64>\r\n
<Possibly other Content headings here, terminated by\r\n>
\r\n
<Here follows the bytes of the content, as per [MAPPING]>
The preferred encoding is BINARY, because X.400 does not have any
limitations to what octets it can pass [4], encoded in an Octet String, but
this RFC does not require use of the BINARY encoding.
proper encoding>
All implementations MUST place the MIME-version: header first in the
body part. Headers that are placed by [RFC-1327] [2] and [MAPPING] [4] into other parts of
the message MUST NOT be placed in the MIME body part.
This includes RFC-822 headings carried as heading-extensions, which
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 using
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 the
token "MIME-Version:" will be subjected to conversion according to
[MAPPING]
[4] before including the body part into an X.400(88) message.
4. Implications
The implications are several:
- People with X.400(84) readers who have the ability to save
Bodypart 14 messages
to file will now be able to save MIME multimedia messages
- People who can use features like the "Mailcaps" file to identify
what to do about a bodypart 14 can now grab MetaMail
or MHN implementations of MIME
that can run as subprograms and achieve at least some multimedia
functionality
Alvestrand et al Expires March 28 1993 [Page 4]
draft HARPOON May 92
- People with E-mail systems that drop into BP 14 when an 8-bit
character comes along can now include the magic tokens by
hand at the beginning of the message, and get their
characters received properly by MIME users
5. Security considerations Considerations
The security considerations in [MIME] [1] and [MAPPING] [4] (beware of trojans that
can hit you if your UA automagically starts programs for you) are now
relevant also for X.400(84) systems.
6. Authors' address Addresses
Harald Tveit Alvestrand
SINTEF DELAB
N-7034 Trondheim
NORWAY
EMail: Harald.T.Alvestrand@delab.sintef.no
Kevin E. Jordan, ARH215
Control Data Systems, Inc.
4201 Lexington Avenue N
Arden Hills, MN 55126
USA
EMail: Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.com
James A. Romaguera
NetConsult AG
Mettlendwaldweg 20a
3037 Herrenschwanden
Switzerland
Romaguera@cosine-mhs.switch.ch
EMail: Romaguera@netconsult.ch
Alvestrand, Romaguera & Jordan [Page 4]
RFC 1496 HARPOON August 1993
7. References
[MIME]
N.
[1] Borenstein, N, and N. Freed, MIME: "MIME: Mechanisms for Specifying
and Describing the Format of Internet Message Bodies. Internet-
Draft, (January, 1992).
[RFC-1327]
S.E. Bodies", RFC 1341,
Bellcore, Innosoft, June 1992.
[2] Hardcastle-Kille, Mapping S., "Mapping between X.400(1988) / ISO 10021
and RFC-822.
Alvestrand et al Expires March 28 1993 [Page 5]
draft HARPOON RFC-822", RFC 1327, University College London, May 92
[RFC-1328]
S.E. 1992.
[3] Hardcastle-Kille, X.400 S., "X.400 1988 to 1984 downgrading.
[MAPPING]
H.T. downgrading", RFC
1328, University College London, May 1992.
[4] Alvestrand, R.S. H., Kille, S., Miles, M.T. R., Rose, S.J. M., and S. Thompson,
Mapping
"Mapping between X.400 and RFC-822 Message Bodies Internet-
Draft, (June, 1992).
Alvestrand et al Expires March 28 1993 [Page 6]
draft HARPOON May 92
Table of Contents
Status of this Memo ........................................ 1
1 Introduction .............................................. 3
2 Basic approach ............................................ 3
3 Basic fallback format ..................................... 3
4 Implications .............................................. 4
5 Security considerations ................................... 5
6 Authors' address .......................................... 5
7 References ................................................ 5
Alvestrand et al Expires March 28 1993 Bodies", RFC 1494,
SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc, Dover Beach
Consulting, Inc., Soft*Switch, Inc., August 1993.
Alvestrand, Romaguera & Jordan [Page 7]
------------------------------ End of body part 2 5]
----