home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1495 < prev    next >
Text File  |  1993-08-26  |  20KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      H. Alvestrand
  8. Request for Comments: 1495                                  SINTEF DELAB
  9. Updates: 1327                                                   S. Kille
  10.                                                         ISODE Consortium
  11.                                                                 R. Miles
  12.                                                        Soft*Switch, Inc.
  13.                                                                  M. Rose
  14.                                             Dover Beach Consulting, Inc.
  15.                                                              S. Thompson
  16.                                                        Soft*Switch, Inc.
  17.                                                              August 1993
  18.  
  19.             Mapping between X.400 and RFC-822 Message Bodies
  20.  
  21. Status of this Memo
  22.  
  23.    This RFC specifies an IAB standards track protocol for the Internet
  24.    community, and requests discussion and suggestions for improvements.
  25.    Please refer to the current edition of the "IAB Official Protocol
  26.    Standards" for the standardization state and status of this protocol.
  27.    Distribution of this memo is unlimited.
  28.  
  29. Table of Contents
  30.  
  31.    1.  Introduction .............................................    1
  32.    2.  Approach .................................................    2
  33.    3.  Mapping between X.400 and RFC-822 Message Bodies .........    3
  34.    3.1  Mapping from X.400 to RFC-822 ...........................    4
  35.    3.2  Mapping from RFC-822 to X.400 ...........................    5
  36.    3.2.1 Asymmetric Mappings ....................................    6
  37.    3.2.1.1 Message/External-Body ................................    6
  38.    3.2.1.2 Message/Partial ......................................    6
  39.    3.2.1.3 Nested Multipart Content-types .......................    6
  40.    3.2.2 Multipart IPMS Heading Extension .......................    7
  41.    4.  Mapping between X.400 and RFC-822 Message Headers ........    7
  42.    5.  OID Assignments ..........................................    9
  43.    6.  Security Considerations ..................................    9
  44.    7.  Authors' Addresses .......................................   10
  45.    8.  References ...............................................   11
  46.  
  47. 1.  Introduction
  48.  
  49.    The Internet community is a large collection of networks under
  50.    autonomous administration, but sharing a core set of protocols.
  51.    These are known as the Internet suite of protocols (or simply
  52.    "TCP/IP").
  53.  
  54.    Use of electronic-mail in the Internet is defined primarily by one
  55.  
  56.  
  57.  
  58. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 1]
  59.  
  60. RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
  61.  
  62.  
  63.    document, STD-11, RFC-822 [1], which defines the standard format for
  64.    the exchange of messages.  RFC-822 has proven immensely popular; in
  65.    fact, the 822-connected Internet, is larger than the scope of the
  66.    IP-connected Internet.
  67.  
  68.    The framework provided by RFC-822 allows for memo-based textual
  69.    messages.  Each message consists of two parts:  the headers and the
  70.    body.  The headers are analogous to the structured fields found in an
  71.    inter-office memo, whilst the body is free-form.  Both parts are
  72.    encoded using ASCII.
  73.  
  74.    Recently, the Internet Engineering Task Force (IETF) has developed an
  75.    document called,
  76.  
  77.       Multipurpose Internet Mail Extensions
  78.  
  79.    or MIME RFC-1341.  The title is actually misleading.  MIME defines
  80.    structure for Internet message bodies.  It is not an extension to
  81.    RFC-822.
  82.  
  83.    Independently of this, the International standards community
  84.    developed a different framework in 1984 (some say that's the
  85.    problem).  This framework is known as the OSI Message Handling System
  86.    (MHS) or sometimes X.400.
  87.  
  88.    Since the introduction of X.400(84), there has been work ongoing for
  89.    defining mappings between MHS and RFC-822.  The most recent work in
  90.    this area is RFC-1327 [3], which focuses primarily on translation of
  91.    envelope and headers.  This document is complimentary to RFC-1327 as
  92.    it focuses on translation of the message body.  The mappings defined
  93.    are largely symmetrical with respect to MIME and MHS structuring
  94.    semantics, although the MIME semantics are somewhat richer.  In order
  95.    to provide for reversible transformations, MHS heading extensions are
  96.    used to carry the additional MIME semantics.
  97.  
  98.    Please send comments to the MIME-MHS mailing list:
  99.    <mime-mhs@surfnet.nl>.
  100.  
  101. 2.  Approach
  102.  
  103.    The mappings have been specifically designed to provide optimal
  104.    behavior for three different scenarios:
  105.  
  106.    (1) Allow a MIME user and an MHS user to exchange an arbitrary binary
  107.        content;
  108.  
  109.    (2) Allow MIME content-types to "tunnel" through an MHS relay that
  110.        is, two MIME users can exchange content-types without loss
  111.  
  112.  
  113.  
  114. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 2]
  115.  
  116. RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
  117.  
  118.  
  119.        through an MHS relay); and,
  120.  
  121.    (3) Allow MHS body parts to "tunnel" through a MIME relay that is,
  122.        two MHS users can exchange body parts without loss through a MIME
  123.        relay).
  124.  
  125.    Other, related, scenarios can also be easily accommodated.
  126.  
  127.    To facilitate the mapping process, the Internet Assigned Numbers
  128.    Authority (IANA) maintains a table termed the "IANA MHS/MIME
  129.    Equivalence Table".  Once an enterprise has registered an OID to
  130.    describe an MHS body part, it should complete a corresponding
  131.    registry with the IANA for a MIME content-type/subtype.  In practice,
  132.    the corresponding content-type will be "application", with an
  133.    appropriate choice of sub-type and possible parameters.  If a new
  134.    MIME content-type/subtype is registered with the IANA without a
  135.    corresponding entry in the Equivalence Table, the IANA will assign it
  136.    an OID, from the arc defined in this memo. See [4], section 5 for
  137.    details.
  138.  
  139.    The companion document, "Equivalences between 1988 X.400 and RFC-822
  140.    Message Bodies"[4], defines the initial configuration of this table.
  141.    The mappings described in both this document and the companion
  142.    document use the notational conventions of RFC-1327.
  143.  
  144. 3.  Mapping between X.400 and RFC-822 Message Bodies
  145.  
  146.    MHS messages are comprised of an IPMS.heading and an IPMS.body.  The
  147.    IPMS.Body is a sequence of IPMS.BodyParts.  An IPMS.BodyPart may be a
  148.    nested message (IPMS.MessageBodyPart).
  149.  
  150.    A MIME message consists of headers and a content.  For the purpose of
  151.    discussion, the content may be structured (multipart or message), or
  152.    atomic (otherwise).  An element of a structured content may be a
  153.    message or a content.  Both message and structured content have
  154.    subtypes which do not have direct analogies in MHS.
  155.  
  156.    The mapping between X.400 and RFC-822 message bodies which this
  157.    document defines is symmetrical for the following cases:
  158.  
  159.           (1) any atomic body part
  160.  
  161.           (2) multipart: digest and mixed subtypes
  162.  
  163.           (3) message/rfc822
  164.  
  165.    RFC-1327 specifies the mappings for headers.  Section 4 describes how
  166.    those mappings are modified by this document.  When mapping between
  167.  
  168.  
  169.  
  170. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 3]
  171.  
  172. RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
  173.  
  174.  
  175.    an MHS body and a MIME content, the following algorithm is used:
  176.  
  177. 3.1.  Mapping from X.400 to RFC-822
  178.  
  179.    This section replaces the text in RFC-1327 starting at the bottom of
  180.    page 84,
  181.  
  182.        The IPMS.Body is mapped into the RFC-822 message body.  Each
  183.        IPMS.BodyPart is converted to ASCII as follows:
  184.  
  185.    and continuing up to and including page 86 of Section 5.3.4 of RFC-
  186.    1327.
  187.  
  188.              If the IPMS.Body
  189.  
  190.                   Body ::=
  191.                       SEQUENCE OF
  192.                           BodyPart
  193.  
  194.    consists of a single body part, then the RFC-822 message body is
  195.    constructed as the MIME content corresponding to that body part.
  196.  
  197.    If the body part is an IPMS.MessageBodyPart (forwarded IPM), the
  198.    mapping is applied recursively.  Otherwise, to map a specific MHS
  199.    body part to a MIME content-type, the IANA MHS/MIME Equivalence table
  200.    is consulted.  If the MHS body part is not identified in this table,
  201.    then the body-part is mapped onto an "application/x400-bp" content,
  202.    as specified in [4].
  203.  
  204.    If the IPMS.Body consists of more than one body part, then the RFC-
  205.    822 message body is constructed as a
  206.  
  207.           multipart/mixed
  208.  
  209.    content-type, unless all of the body parts are messages, in which
  210.    case it is mapped to a
  211.  
  212.           multipart/digest
  213.  
  214.    content-type.  Each component of the multipart content-type
  215.    corresponds to a IPMS.BodyPart, preserving the ordering of the body
  216.    parts in the IPMS.Body.
  217.  
  218.    There is one case which gets special treatement.  If the IPMS.Body
  219.    consists solely of a single IA5Text body part, then the RFC822
  220.    message body is NOT marked as a MIME content.  This prevents RFC822
  221.    mailers from invoking MIME function unnecessarily.
  222.  
  223.  
  224.  
  225.  
  226. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 4]
  227.  
  228. RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
  229.  
  230.  
  231. 3.2.  Mapping from RFC-822 to X.400
  232.  
  233.    First, replace the first paragraph of Section 5.1.3 on page 72 of
  234.    RFC-1327 to read as:
  235.  
  236.        The IPM (IPMS Service Request) is generated according to the
  237.        rules of this section.  The IPMS.body usually consists of one
  238.        IPMS.BodyPart of type
  239.  
  240.                            IPMS.IA5TextBodyPart
  241.  
  242.                       with
  243.                            IPMS.IA5TextBodyPart.parameters.repertoire
  244.  
  245.        set to the default (ia5), which contains the body of the RFC-822
  246.        message.  However, if the 822.MIME-Version header field is
  247.        present, a special algorithm is used to generate the IPMS.body.
  248.  
  249.  
  250.        Second, replace the "Comments:" paragraph on page 74 to reads as:
  251.  
  252.        Comments:
  253.  
  254.           If an 822.MIME-Version header field is not present,
  255.           generate an IPMS.Bodypart of type
  256.  
  257.               IPMS.IA5TextBodyPart
  258.  
  259.           with
  260.  
  261.               IPMS.IA5TextBodyPart.parameters.repertoire
  262.  
  263.           set to the default (ia5), containing the value of
  264.           the fields, preceded by the string "Comments: ".
  265.           This body part shall preceed the other one.
  266.  
  267.    Third, add the remainder of this section to the end of Section 5.1.3
  268.    of RFC-1327.
  269.  
  270.    If the 822.MIME-Version header field is present, the following
  271.    mapping rules are used to generate the IPMS.body.
  272.  
  273.    If the MIME content-type is one of:
  274.  
  275.    (1)  any atomic body part
  276.  
  277.    (2)  multipart: digest and mixed subtypes
  278.  
  279.  
  280.  
  281.  
  282. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 5]
  283.  
  284. RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
  285.  
  286.  
  287.    (3)  message/rfc822
  288.  
  289.    then the symmetric mapping applies as described in Section 6.1.  Note
  290.    that the multipart content-types should be marked with the
  291.    IPMS.HeadingExtension described below.
  292.  
  293.    Otherwise, three cases remain, which are discussed in turn.
  294.  
  295. 3.2.1.  Asymmetric Mappings
  296.  
  297. 3.2.1.1.  Message/External-Body
  298.  
  299.    This is mapped into a mime-body-part, as specified in [4].
  300.  
  301. 3.2.1.2.  Message/Partial
  302.  
  303.    This is mapped onto a message, and the following heading extension is
  304.    used.  The extension is derived from the message/partial parameters:
  305.  
  306.                   partial-message  HEADING-EXTENSION
  307.                       VALUE PartialMessage
  308.                       ::= id-hex-partial-message
  309.  
  310.                   PartialMessage ::=
  311.                       SEQUENCE {
  312.                           number INTEGER,
  313.                           total  INTEGER,
  314.                           id     IA5String
  315.                       }
  316.  
  317.    If this heading is present when mapping from MHS to MIME, then a
  318.    message/partial should be generated.
  319.  
  320. 3.2.1.3.  Nested Multipart Content-types
  321.  
  322.    In MIME, a multipart content refers to a set of content-types, not a
  323.    message with a set of content-types. However, a nested multipart
  324.    content will always be mapped to an IPMS.MessageBodyPart, with an
  325.    IPMS.BodyPart for each contained content-type.
  326.  
  327.    The only mandatory field in the heading is the IPMS.this-IPM, which
  328.    must always be generated (by the gateway). A IPMS.subject field
  329.    should also be generated where there is no "real" heading. This will
  330.    present useful information to the non-MIME capable X.400(88) and to
  331.    all X.400(84) UAs.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 6]
  339.  
  340. RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
  341.  
  342.  
  343.    The IPM.subject fields for the various types are:
  344.  
  345.    mixed:        "Multipart Message"
  346.    alternative:  "Alternate Body Parts containing the same information"
  347.    digest:       "Message Digest"
  348.    parallel:     "Body Parts to be interpreted in parallel"
  349.  
  350. 3.2.2.  Multipart IPMS Heading Extension
  351.  
  352.    The following IPMS.HeadingExtension should be generated for all
  353.    multipart content-types, with the enumerated value set according to
  354.    the subtype:
  355.  
  356.                   multipart-message HEADING-EXTENSION
  357.                       VALUE MultipartType
  358.                       ::= id-hex-multipart-message
  359.  
  360.                   MultipartType ::=
  361.                       ENUMERATED {
  362.                           mixed(1),
  363.                           alternative(2),
  364.                           digest(3),
  365.                           parallel(4)
  366.                       }
  367.  
  368.    If this heading is present when mapping from MHS to MIME, then the
  369.    appropriate multipart content-type should be generated.
  370.  
  371. 4.  Mapping between X.400 and RFC-822 Message Headers
  372.  
  373.    Replace the first paragraph of Section 3.3.4 on page 26 of RFC-1327
  374.    to read as:
  375.         In cases where T.61 strings are used only for conveying human-
  376.         interpreted information, the aim of this mapping is to render
  377.         the characters appropriately in the remote character set, rather
  378.         than to maximize reversibility.  For these cases, the following
  379.         steps are followed to find an appropriate encoding:
  380.  
  381.         1) If all the characters in the string are contained within the
  382.         ASCII repertoire, the string is simply copied.
  383.  
  384.         2) If all the characters in the string are from an IANA-
  385.         registered character set, then the appropriate encoded-word(s)
  386.         according to [5] are generated instead.
  387.  
  388.         3) If the characters in the string are from a character set
  389.         which is not registered with the IANA, then the mappings to IA5
  390.         defined in CCITT Recommendation X.408 (1988) shall be used
  391.  
  392.  
  393.  
  394. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 7]
  395.  
  396. RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
  397.  
  398.  
  399.         [CCITT/ISO88a].  These will then be encoded in ASCII.
  400.  
  401.         This approach will only be used for human-readable information
  402.         (Subject and FreeForm Name).
  403.  
  404.         When mapping from an RFC-822 header, when an encoded-word (as
  405.         defined in [5]) is encountered:
  406.  
  407.         1) If all the characters contained therein are mappable to T.61,
  408.         the string content shall be converted into T.61.
  409.  
  410.         2) Otherwise, the encoded-word shall be copied directly into the
  411.         T.61 string.
  412.  
  413.    Modify procedure "2a" on page 56 of RFC-1327 to read as:
  414.         If the IPMS.ORDescriptor.free-form-name is present, convert it
  415.         to ASCII or T.61 (Section 3.3.4), and use this as the 822.phrase
  416.         component of the 822.mailbox construct.
  417.  
  418.    Modify the final paragraph of procedure "2" on page 55 of RFC-1327 to
  419.    read as:
  420.         The string is then encoded into T.61 or ASCII using a human-
  421.         oriented mapping (as described in Section 3.3.4).  If the string
  422.         is not null, it is assigned to IPMS.ORDescriptor.free-form.name.
  423.  
  424.    Modify the second paragraph of procedure "3" on page 55 of RFC-1327
  425.    to read as:
  426.         If the 822.group construct is present, any included 822.mailbox
  427.         is encoded as above to generate a separate IPMS.ORDescriptor.
  428.         The 822.group is mapped to T.61 or ASCII (as described in
  429.         Section 3.3.4), and an IPMS.ORDescriptor with only an free-
  430.         form-name component is built from it.
  431.  
  432.    Modify procedure "822.Subject" on page 62 of RFC-1327 to read as:
  433.  
  434.         Mapped to IMPS.Heading.subject.  The field-body uses the human-
  435.         oriented mapping referenceed in Section 3.3.4.
  436.  
  437.    Modify procedure "IPMS.Heading.subject" on page 71 of RFC-1327 to
  438.    read as:
  439.         Mapped to "Subject:".  The contents are converted to ASCII or
  440.         T.61 (Section 3.3.4).  Any CRLF are not mapped, but are used as
  441.         points at which the subject field must be folded.
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 8]
  451.  
  452. RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
  453.  
  454.  
  455. 5.  OID Assignments
  456.  
  457.    MIME-MHS DEFINITIONS ::= BEGIN
  458.  
  459.  
  460.    mail OBJECT IDENTIFIER ::= { internet 7 }
  461.  
  462.    mime-mhs OBJECT IDENTIFIER ::= { mail 1 }
  463.  
  464.    mime-mhs-headings OBJECT IDENTIFIER ::= { mime-mhs 1 }
  465.  
  466.    id-hex-partial-message OBJECT IDENTIFIER ::=
  467.            { mime-mhs-headings 1 }
  468.  
  469.    id-hex-multipart-message OBJECT IDENTIFIER ::=
  470.            { mime-mhs-headings 2 }
  471.  
  472.  
  473.    mime-mhs-bodies OBJECT IDENTIFIER ::= { mime-mhs 2 }
  474.  
  475.  
  476.    END
  477.  
  478. 6.  Security Considerations
  479.  
  480.    There are no explicit security provisions in this document.  However,
  481.    a warning is in order.  This document maps two mechanisms between
  482.    RFC822 and X.400 that could cause problems.  The first is the
  483.    transfer of binary files.  The inherent risks are well known and
  484.    won't be reiterated here.  The second is the propagation of strong
  485.    content typing.  The typing can be used to automatically "launch" or
  486.    initiate applications against those contents.  Any such launching
  487.    leaves the invoker vulnerable to application-specific viruses; for
  488.    example, a spreadsheet macro or Postscript command that deletes
  489.    files.  See [2], Section 7.4.2 for a Postscript-specific discussion
  490.    of this issue.
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 9]
  507.  
  508. RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
  509.  
  510.  
  511. 7.  Authors' Addresses
  512.  
  513.    Harald Tveit Alvestrand
  514.    SINTEF DELAB
  515.    N-7034 Trondheim
  516.    NORWAY
  517.  
  518.    EMail: Harald.Alvestrand@delab.sintef.no
  519.  
  520.  
  521.    Steve Kille
  522.    ISODE Consortium
  523.    P.O. Box 505
  524.    London
  525.    SW11 1DX
  526.    England
  527.  
  528.    Phone: +44-71-223-4062
  529.    EMail: S.Kille@ISODE.COM
  530.  
  531.  
  532.    Robert S. Miles
  533.    Soft*Switch, Inc.
  534.    640 Lee Road
  535.    Wayne, PA 19087
  536.  
  537.    Phone: (215) 640-7556
  538.    EMail: rsm@spyder.ssw.com
  539.  
  540.  
  541.    Marshall T. Rose
  542.    Dover Beach Consulting, Inc.
  543.    420 Whisman Court
  544.    Mountain View, CA  94043-2186
  545.    US
  546.  
  547.    Phone: +1 415 968 1052
  548.    Fax:   +1 415 968 2510
  549.    EMail: mrose@dbc.mtview.ca.us
  550.  
  551.  
  552.    Steven J. Thompson
  553.    Soft*Switch, Inc.
  554.    640 Lee Road
  555.    Wayne, PA 19087
  556.  
  557.    Phone: (215) 640-7556
  558.    EMail: sjt@gateway.ssw.com
  559.  
  560.  
  561.  
  562. Alvestrand, Kille, Miles, Rose & Thompson                      [Page 10]
  563.  
  564. RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
  565.  
  566.  
  567. 8.  References
  568.  
  569.    [1] Crocker, D., "Standard for the Format of ARPA Internet Text
  570.        Messages", STD 11, RFC 822, UDEL, August 1982.
  571.  
  572.    [2] Borenstein, N., and N. Freed, "MIME: Mechanisms for Specifying
  573.        and Describing the Format of Internet Message Bodies", RFC 1341,
  574.        Bellcore, Innosoft, June 1992.
  575.  
  576.    [3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
  577.        and RFC-822", RFC 1327, University College London, May 1992.
  578.  
  579.    [4] Alvestrand, H., and S. Thompson, "Equivalences between 1988 X.400
  580.        and RFC-822 Message Bodies", RFC 1494, SINTEF DELAB, Soft*Switch,
  581.        Inc., August 1993.
  582.  
  583.    [5] Moore, K., "Representation of Non-ASCII Text in Internet Message
  584.        Headers Message Bodies", RFC 1342, University of Tennesse, June
  585.        1992.
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Alvestrand, Kille, Miles, Rose & Thompson                      [Page 11]
  619.  
  620.