Movatterモバイル変換

Network Working Group                                      H. AlvestrandRequest for Comments: 1495                                  SINTEF DELABUpdates:1327                                                   S. Kille                                                        ISODE Consortium                                                                R. Miles                                                       Soft*Switch, Inc.                                                                 M. Rose                                            Dover Beach Consulting, Inc.                                                             S. Thompson                                                       Soft*Switch, Inc.                                                             August 1993Mapping between X.400 andRFC-822 Message BodiesStatus of this Memo   This RFC specifies an IAB standards track protocol for the Internet   community, and requests discussion and suggestions for improvements.   Please refer to the current edition of the "IAB Official Protocol   Standards" for the standardization state and status of this protocol.   Distribution of this memo is unlimited.Table of Contents1.  Introduction .............................................12.  Approach .................................................23.  Mapping between X.400 andRFC-822 Message Bodies .........33.1  Mapping from X.400 toRFC-822 ...........................43.2  Mapping fromRFC-822 to X.400 ...........................53.2.1 Asymmetric Mappings ....................................63.2.1.1 Message/External-Body ................................63.2.1.2 Message/Partial ......................................63.2.1.3 Nested Multipart Content-types .......................63.2.2 Multipart IPMS Heading Extension .......................74.  Mapping between X.400 andRFC-822 Message Headers ........75.  OID Assignments ..........................................96.  Security Considerations ..................................97.  Authors' Addresses .......................................108.  References ...............................................111.  Introduction   The Internet community is a large collection of networks under   autonomous administration, but sharing a core set of protocols.   These are known as the Internet suite of protocols (or simply   "TCP/IP").   Use of electronic-mail in the Internet is defined primarily by oneAlvestrand, Kille, Miles, Rose & Thompson                       [Page 1]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993   document, STD-11,RFC-822 [1], which defines the standard format for   the exchange of messages.RFC-822 has proven immensely popular; in   fact, the 822-connected Internet, is larger than the scope of the   IP-connected Internet.   The framework provided byRFC-822 allows for memo-based textual   messages.  Each message consists of two parts:  the headers and the   body.  The headers are analogous to the structured fields found in an   inter-office memo, whilst the body is free-form.  Both parts are   encoded using ASCII.   Recently, the Internet Engineering Task Force (IETF) has developed an   document called,      Multipurpose Internet Mail Extensions   or MIMERFC-1341.  The title is actually misleading.  MIME defines   structure for Internet message bodies.  It is not an extension toRFC-822.   Independently of this, the International standards community   developed a different framework in 1984 (some say that's the   problem).  This framework is known as the OSI Message Handling System   (MHS) or sometimes X.400.   Since the introduction of X.400(84), there has been work ongoing for   defining mappings between MHS andRFC-822.  The most recent work in   this area isRFC-1327 [3], which focuses primarily on translation of   envelope and headers.  This document is complimentary toRFC-1327 as   it focuses on translation of the message body.  The mappings defined   are largely symmetrical with respect to MIME and MHS structuring   semantics, although the MIME semantics are somewhat richer.  In order   to provide for reversible transformations, MHS heading extensions are   used to carry the additional MIME semantics.   Please send comments to the MIME-MHS mailing list:   <mime-mhs@surfnet.nl>.2.  Approach   The mappings have been specifically designed to provide optimal   behavior for three different scenarios:   (1) Allow a MIME user and an MHS user to exchange an arbitrary binary       content;   (2) Allow MIME content-types to "tunnel" through an MHS relay that       is, two MIME users can exchange content-types without lossAlvestrand, Kille, Miles, Rose & Thompson                       [Page 2]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993       through an MHS relay); and,   (3) Allow MHS body parts to "tunnel" through a MIME relay that is,       two MHS users can exchange body parts without loss through a MIME       relay).   Other, related, scenarios can also be easily accommodated.   To facilitate the mapping process, the Internet Assigned Numbers   Authority (IANA) maintains a table termed the "IANA MHS/MIME   Equivalence Table".  Once an enterprise has registered an OID to   describe an MHS body part, it should complete a corresponding   registry with the IANA for a MIME content-type/subtype.  In practice,   the corresponding content-type will be "application", with an   appropriate choice of sub-type and possible parameters.  If a new   MIME content-type/subtype is registered with the IANA without a   corresponding entry in the Equivalence Table, the IANA will assign it   an OID, from the arc defined in this memo. See [4], section 5 for   details.   The companion document, "Equivalences between 1988 X.400 andRFC-822   Message Bodies"[4], defines the initial configuration of this table.   The mappings described in both this document and the companion   document use the notational conventions ofRFC-1327.3.  Mapping between X.400 andRFC-822 Message Bodies   MHS messages are comprised of an IPMS.heading and an IPMS.body.  The   IPMS.Body is a sequence of IPMS.BodyParts.  An IPMS.BodyPart may be a   nested message (IPMS.MessageBodyPart).   A MIME message consists of headers and a content.  For the purpose of   discussion, the content may be structured (multipart or message), or   atomic (otherwise).  An element of a structured content may be a   message or a content.  Both message and structured content have   subtypes which do not have direct analogies in MHS.   The mapping between X.400 andRFC-822 message bodies which this   document defines is symmetrical for the following cases:          (1) any atomic body part          (2) multipart: digest and mixed subtypes          (3) message/rfc822RFC-1327 specifies the mappings for headers.Section 4 describes how   those mappings are modified by this document.  When mapping betweenAlvestrand, Kille, Miles, Rose & Thompson                       [Page 3]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993   an MHS body and a MIME content, the following algorithm is used:3.1.  Mapping from X.400 toRFC-822   This section replaces the text inRFC-1327 starting at the bottom of   page 84,       The IPMS.Body is mapped into theRFC-822 message body.  Each       IPMS.BodyPart is converted to ASCII as follows:   and continuing up to and including page 86 of Section 5.3.4 ofRFC-1327.             If the IPMS.Body                  Body ::=                      SEQUENCE OF                          BodyPart   consists of a single body part, then theRFC-822 message body is   constructed as the MIME content corresponding to that body part.   If the body part is an IPMS.MessageBodyPart (forwarded IPM), the   mapping is applied recursively.  Otherwise, to map a specific MHS   body part to a MIME content-type, the IANA MHS/MIME Equivalence table   is consulted.  If the MHS body part is not identified in this table,   then the body-part is mapped onto an "application/x400-bp" content,   as specified in [4].   If the IPMS.Body consists of more than one body part, then theRFC-822 message body is constructed as a          multipart/mixed   content-type, unless all of the body parts are messages, in which   case it is mapped to a          multipart/digest   content-type.  Each component of the multipart content-type   corresponds to a IPMS.BodyPart, preserving the ordering of the body   parts in the IPMS.Body.   There is one case which gets special treatement.  If the IPMS.Body   consists solely of a single IA5Text body part, then theRFC822   message body is NOT marked as a MIME content.  This preventsRFC822   mailers from invoking MIME function unnecessarily.Alvestrand, Kille, Miles, Rose & Thompson                       [Page 4]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 19933.2.  Mapping fromRFC-822 to X.400   First, replace the first paragraph ofSection 5.1.3 on page 72 ofRFC-1327 to read as:       The IPM (IPMS Service Request) is generated according to the       rules of this section.  The IPMS.body usually consists of one       IPMS.BodyPart of type                           IPMS.IA5TextBodyPart                      with                           IPMS.IA5TextBodyPart.parameters.repertoire       set to the default (ia5), which contains the body of theRFC-822       message.  However, if the 822.MIME-Version header field is       present, a special algorithm is used to generate the IPMS.body.       Second, replace the "Comments:" paragraph on page 74 to reads as:       Comments:          If an 822.MIME-Version header field is not present,          generate an IPMS.Bodypart of type              IPMS.IA5TextBodyPart          with              IPMS.IA5TextBodyPart.parameters.repertoire          set to the default (ia5), containing the value of          the fields, preceded by the string "Comments: ".          This body part shall preceed the other one.   Third, add the remainder of this section to the end ofSection 5.1.3   of RFC-1327.   If the 822.MIME-Version header field is present, the following   mapping rules are used to generate the IPMS.body.   If the MIME content-type is one of:   (1)  any atomic body part   (2)  multipart: digest and mixed subtypesAlvestrand, Kille, Miles, Rose & Thompson                       [Page 5]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993   (3)  message/rfc822   then the symmetric mapping applies as described inSection 6.1.  Note   that the multipart content-types should be marked with the   IPMS.HeadingExtension described below.   Otherwise, three cases remain, which are discussed in turn.3.2.1.  Asymmetric Mappings3.2.1.1.  Message/External-Body   This is mapped into a mime-body-part, as specified in [4].3.2.1.2.  Message/Partial   This is mapped onto a message, and the following heading extension is   used.  The extension is derived from the message/partial parameters:                  partial-message  HEADING-EXTENSION                      VALUE PartialMessage                      ::= id-hex-partial-message                  PartialMessage ::=                      SEQUENCE {                          number INTEGER,                          total  INTEGER,                          id     IA5String                      }   If this heading is present when mapping from MHS to MIME, then a   message/partial should be generated.3.2.1.3.  Nested Multipart Content-types   In MIME, a multipart content refers to a set of content-types, not a   message with a set of content-types. However, a nested multipart   content will always be mapped to an IPMS.MessageBodyPart, with an   IPMS.BodyPart for each contained content-type.   The only mandatory field in the heading is the IPMS.this-IPM, which   must always be generated (by the gateway). A IPMS.subject field   should also be generated where there is no "real" heading. This will   present useful information to the non-MIME capable X.400(88) and to   all X.400(84) UAs.Alvestrand, Kille, Miles, Rose & Thompson                       [Page 6]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993   The IPM.subject fields for the various types are:   mixed:        "Multipart Message"   alternative:  "Alternate Body Parts containing the same information"   digest:       "Message Digest"   parallel:     "Body Parts to be interpreted in parallel"3.2.2.  Multipart IPMS Heading Extension   The following IPMS.HeadingExtension should be generated for all   multipart content-types, with the enumerated value set according to   the subtype:                  multipart-message HEADING-EXTENSION                      VALUE MultipartType                      ::= id-hex-multipart-message                  MultipartType ::=                      ENUMERATED {                          mixed(1),                          alternative(2),                          digest(3),                          parallel(4)                      }   If this heading is present when mapping from MHS to MIME, then the   appropriate multipart content-type should be generated.4.  Mapping between X.400 andRFC-822 Message Headers   Replace the first paragraph ofSection 3.3.4 on page 26 ofRFC-1327   to read as:        In cases where T.61 strings are used only for conveying human-        interpreted information, the aim of this mapping is to render        the characters appropriately in the remote character set, rather        than to maximize reversibility.  For these cases, the following        steps are followed to find an appropriate encoding:        1) If all the characters in the string are contained within the        ASCII repertoire, the string is simply copied.        2) If all the characters in the string are from an IANA-        registered character set, then the appropriate encoded-word(s)        according to [5] are generated instead.        3) If the characters in the string are from a character set        which is not registered with the IANA, then the mappings to IA5        defined in CCITT Recommendation X.408 (1988) shall be usedAlvestrand, Kille, Miles, Rose & Thompson                       [Page 7]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993        [CCITT/ISO88a].  These will then be encoded in ASCII.        This approach will only be used for human-readable information        (Subject and FreeForm Name).        When mapping from anRFC-822 header, when an encoded-word (as        defined in [5]) is encountered:        1) If all the characters contained therein are mappable to T.61,        the string content shall be converted into T.61.        2) Otherwise, the encoded-word shall be copied directly into the        T.61 string.   Modify procedure "2a" on page 56 ofRFC-1327 to read as:        If the IPMS.ORDescriptor.free-form-name is present, convert it        to ASCII or T.61 (Section 3.3.4), and use this as the 822.phrase        component of the 822.mailbox construct.   Modify the final paragraph of procedure "2" on page 55 ofRFC-1327 to   read as:        The string is then encoded into T.61 or ASCII using a human-        oriented mapping (as described inSection 3.3.4).  If the string        is not null, it is assigned to IPMS.ORDescriptor.free-form.name.   Modify the second paragraph of procedure "3" on page 55 ofRFC-1327   to read as:        If the 822.group construct is present, any included 822.mailbox        is encoded as above to generate a separate IPMS.ORDescriptor.        The 822.group is mapped to T.61 or ASCII (as described inSection 3.3.4), and an IPMS.ORDescriptor with only an free-        form-name component is built from it.   Modify procedure "822.Subject" on page 62 ofRFC-1327 to read as:        Mapped to IMPS.Heading.subject.  The field-body uses the human-        oriented mapping referenceed inSection 3.3.4.   Modify procedure "IPMS.Heading.subject" on page 71 ofRFC-1327 to   read as:        Mapped to "Subject:".  The contents are converted to ASCII or        T.61 (Section 3.3.4).  Any CRLF are not mapped, but are used as        points at which the subject field must be folded.Alvestrand, Kille, Miles, Rose & Thompson                       [Page 8]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 19935.  OID Assignments   MIME-MHS DEFINITIONS ::= BEGIN   mail OBJECT IDENTIFIER ::= { internet 7 }   mime-mhs OBJECT IDENTIFIER ::= { mail 1 }   mime-mhs-headings OBJECT IDENTIFIER ::= { mime-mhs 1 }   id-hex-partial-message OBJECT IDENTIFIER ::=           { mime-mhs-headings 1 }   id-hex-multipart-message OBJECT IDENTIFIER ::=           { mime-mhs-headings 2 }   mime-mhs-bodies OBJECT IDENTIFIER ::= { mime-mhs 2 }   END6.  Security Considerations   There are no explicit security provisions in this document.  However,   a warning is in order.  This document maps two mechanisms betweenRFC822 and X.400 that could cause problems.  The first is the   transfer of binary files.  The inherent risks are well known and   won't be reiterated here.  The second is the propagation of strong   content typing.  The typing can be used to automatically "launch" or   initiate applications against those contents.  Any such launching   leaves the invoker vulnerable to application-specific viruses; for   example, a spreadsheet macro or Postscript command that deletes   files.  See [2], Section 7.4.2 for a Postscript-specific discussion   of this issue.Alvestrand, Kille, Miles, Rose & Thompson                       [Page 9]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 19937.  Authors' Addresses   Harald Tveit Alvestrand   SINTEF DELAB   N-7034 Trondheim   NORWAY   EMail: Harald.Alvestrand@delab.sintef.no   Steve Kille   ISODE Consortium   P.O. Box 505   London   SW11 1DX   England   Phone: +44-71-223-4062   EMail: S.Kille@ISODE.COM   Robert S. Miles   Soft*Switch, Inc.   640 Lee Road   Wayne, PA 19087   Phone: (215) 640-7556   EMail: rsm@spyder.ssw.com   Marshall T. Rose   Dover Beach Consulting, Inc.   420 Whisman Court   Mountain View, CA  94043-2186   US   Phone: +1 415 968 1052   Fax:   +1 415 968 2510   EMail: mrose@dbc.mtview.ca.us   Steven J. Thompson   Soft*Switch, Inc.   640 Lee Road   Wayne, PA 19087   Phone: (215) 640-7556   EMail: sjt@gateway.ssw.comAlvestrand, Kille, Miles, Rose & Thompson                      [Page 10]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 19938.  References   [1] Crocker, D., "Standard for the Format of ARPA Internet Text       Messages", STD 11,RFC 822, UDEL, August 1982.   [2] Borenstein, N., and N. Freed, "MIME: Mechanisms for Specifying       and Describing the Format of Internet Message Bodies",RFC 1341,       Bellcore, Innosoft, June 1992.   [3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021       andRFC-822",RFC 1327, University College London, May 1992.   [4] Alvestrand, H., and S. Thompson, "Equivalences between 1988 X.400       andRFC-822 Message Bodies",RFC 1494, SINTEF DELAB, Soft*Switch,       Inc., August 1993.   [5] Moore, K., "Representation of Non-ASCII Text in Internet Message       Headers Message Bodies",RFC 1342, University of Tennesse, June       1992.Alvestrand, Kille, Miles, Rose & Thompson                      [Page 11]