home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1495.txt < prev    next >
Text File  |  1996-05-07  |  21KB  |  371 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      H. Alvestrand Request for Comments: 1495                                  SINTEF DELAB Updates: 1327                                                   S. Kille                                                         ISODE Consortium                                                                 R. Miles                                                        Soft*Switch, Inc.                                                                  M. Rose                                             Dover Beach Consulting, Inc.                                                              S. Thompson                                                        Soft*Switch, Inc.                                                              August 1993 
  8.  
  9.             Mapping between X.400 and RFC-822 Message Bodies 
  10.  
  11. Status of this Memo 
  12.  
  13.    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. 
  14.  
  15. Table of Contents 
  16.  
  17.    1.  Introduction .............................................    1    2.  Approach .................................................    2    3.  Mapping between X.400 and RFC-822 Message Bodies .........    3    3.1  Mapping from X.400 to RFC-822 ...........................    4    3.2  Mapping from RFC-822 to X.400 ...........................    5    3.2.1 Asymmetric Mappings ....................................    6    3.2.1.1 Message/External-Body ................................    6    3.2.1.2 Message/Partial ......................................    6    3.2.1.3 Nested Multipart Content-types .......................    6    3.2.2 Multipart IPMS Heading Extension .......................    7    4.  Mapping between X.400 and RFC-822 Message Headers ........    7    5.  OID Assignments ..........................................    9    6.  Security Considerations ..................................    9    7.  Authors' Addresses .......................................   10    8.  References ...............................................   11 
  18.  
  19. 1.  Introduction 
  20.  
  21.    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"). 
  22.  
  23.    Use of electronic-mail in the Internet is defined primarily by one 
  24.  
  25.  
  26.  
  27. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 1] 
  28.  RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993 
  29.  
  30.     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. 
  31.  
  32.    The framework provided by RFC-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. 
  33.  
  34.    Recently, the Internet Engineering Task Force (IETF) has developed an    document called, 
  35.  
  36.       Multipurpose Internet Mail Extensions 
  37.  
  38.    or MIME RFC-1341.  The title is actually misleading.  MIME defines    structure for Internet message bodies.  It is not an extension to    RFC-822. 
  39.  
  40.    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. 
  41.  
  42.    Since the introduction of X.400(84), there has been work ongoing for    defining mappings between MHS and RFC-822.  The most recent work in    this area is RFC-1327 [3], which focuses primarily on translation of    envelope and headers.  This document is complimentary to RFC-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. 
  43.  
  44.    Please send comments to the MIME-MHS mailing list:    <mime-mhs@surfnet.nl>. 
  45.  
  46. 2.  Approach 
  47.  
  48.    The mappings have been specifically designed to provide optimal    behavior for three different scenarios: 
  49.  
  50.    (1) Allow a MIME user and an MHS user to exchange an arbitrary binary        content; 
  51.  
  52.    (2) Allow MIME content-types to "tunnel" through an MHS relay that        is, two MIME users can exchange content-types without loss 
  53.  
  54.  
  55.  
  56. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 2] 
  57.  RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993 
  58.  
  59.         through an MHS relay); and, 
  60.  
  61.    (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). 
  62.  
  63.    Other, related, scenarios can also be easily accommodated. 
  64.  
  65.    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. 
  66.  
  67.    The companion document, "Equivalences between 1988 X.400 and RFC-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 of RFC-1327. 
  68.  
  69. 3.  Mapping between X.400 and RFC-822 Message Bodies 
  70.  
  71.    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). 
  72.  
  73.    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. 
  74.  
  75.    The mapping between X.400 and RFC-822 message bodies which this    document defines is symmetrical for the following cases: 
  76.  
  77.           (1) any atomic body part 
  78.  
  79.           (2) multipart: digest and mixed subtypes 
  80.  
  81.           (3) message/rfc822 
  82.  
  83.    RFC-1327 specifies the mappings for headers.  Section 4 describes how    those mappings are modified by this document.  When mapping between 
  84.  
  85.  
  86.  
  87. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 3] 
  88.  RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993 
  89.  
  90.     an MHS body and a MIME content, the following algorithm is used: 
  91.  
  92. 3.1.  Mapping from X.400 to RFC-822 
  93.  
  94.    This section replaces the text in RFC-1327 starting at the bottom of    page 84, 
  95.  
  96.        The IPMS.Body is mapped into the RFC-822 message body.  Each        IPMS.BodyPart is converted to ASCII as follows: 
  97.  
  98.    and continuing up to and including page 86 of Section 5.3.4 of RFC-    1327. 
  99.  
  100.              If the IPMS.Body 
  101.  
  102.                   Body ::=                       SEQUENCE OF                           BodyPart 
  103.  
  104.    consists of a single body part, then the RFC-822 message body is    constructed as the MIME content corresponding to that body part. 
  105.  
  106.    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]. 
  107.  
  108.    If the IPMS.Body consists of more than one body part, then the RFC-    822 message body is constructed as a 
  109.  
  110.           multipart/mixed 
  111.  
  112.    content-type, unless all of the body parts are messages, in which    case it is mapped to a 
  113.  
  114.           multipart/digest 
  115.  
  116.    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. 
  117.  
  118.    There is one case which gets special treatement.  If the IPMS.Body    consists solely of a single IA5Text body part, then the RFC822    message body is NOT marked as a MIME content.  This prevents RFC822    mailers from invoking MIME function unnecessarily. 
  119.  
  120.  
  121.  
  122.  Alvestrand, Kille, Miles, Rose & Thompson                       [Page 4] 
  123.  RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993 
  124.  
  125.  3.2.  Mapping from RFC-822 to X.400 
  126.  
  127.    First, replace the first paragraph of Section 5.1.3 on page 72 of    RFC-1327 to read as: 
  128.  
  129.        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 
  130.  
  131.                            IPMS.IA5TextBodyPart 
  132.  
  133.                       with                            IPMS.IA5TextBodyPart.parameters.repertoire 
  134.  
  135.        set to the default (ia5), which contains the body of the RFC-822        message.  However, if the 822.MIME-Version header field is        present, a special algorithm is used to generate the IPMS.body. 
  136.  
  137.         Second, replace the "Comments:" paragraph on page 74 to reads as: 
  138.  
  139.        Comments: 
  140.  
  141.           If an 822.MIME-Version header field is not present,           generate an IPMS.Bodypart of type 
  142.  
  143.               IPMS.IA5TextBodyPart 
  144.  
  145.           with 
  146.  
  147.               IPMS.IA5TextBodyPart.parameters.repertoire 
  148.  
  149.           set to the default (ia5), containing the value of           the fields, preceded by the string "Comments: ".           This body part shall preceed the other one. 
  150.  
  151.    Third, add the remainder of this section to the end of Section 5.1.3    of RFC-1327. 
  152.  
  153.    If the 822.MIME-Version header field is present, the following    mapping rules are used to generate the IPMS.body. 
  154.  
  155.    If the MIME content-type is one of: 
  156.  
  157.    (1)  any atomic body part 
  158.  
  159.    (2)  multipart: digest and mixed subtypes 
  160.  
  161.  
  162.  
  163.  Alvestrand, Kille, Miles, Rose & Thompson                       [Page 5] 
  164.  RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993 
  165.  
  166.     (3)  message/rfc822 
  167.  
  168.    then the symmetric mapping applies as described in Section 6.1.  Note    that the multipart content-types should be marked with the    IPMS.HeadingExtension described below. 
  169.  
  170.    Otherwise, three cases remain, which are discussed in turn. 
  171.  
  172. 3.2.1.  Asymmetric Mappings 
  173.  
  174. 3.2.1.1.  Message/External-Body 
  175.  
  176.    This is mapped into a mime-body-part, as specified in [4]. 
  177.  
  178. 3.2.1.2.  Message/Partial 
  179.  
  180.    This is mapped onto a message, and the following heading extension is    used.  The extension is derived from the message/partial parameters: 
  181.  
  182.                   partial-message  HEADING-EXTENSION                       VALUE PartialMessage                       ::= id-hex-partial-message 
  183.  
  184.                   PartialMessage ::=                       SEQUENCE {                           number INTEGER,                           total  INTEGER,                           id     IA5String                       } 
  185.  
  186.    If this heading is present when mapping from MHS to MIME, then a    message/partial should be generated. 
  187.  
  188. 3.2.1.3.  Nested Multipart Content-types 
  189.  
  190.    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. 
  191.  
  192.    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. 
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  Alvestrand, Kille, Miles, Rose & Thompson                       [Page 6] 
  199.  RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993 
  200.  
  201.     The IPM.subject fields for the various types are: 
  202.  
  203.    mixed:        "Multipart Message"    alternative:  "Alternate Body Parts containing the same information"    digest:       "Message Digest"    parallel:     "Body Parts to be interpreted in parallel" 
  204.  
  205. 3.2.2.  Multipart IPMS Heading Extension 
  206.  
  207.    The following IPMS.HeadingExtension should be generated for all    multipart content-types, with the enumerated value set according to    the subtype: 
  208.  
  209.                   multipart-message HEADING-EXTENSION                       VALUE MultipartType                       ::= id-hex-multipart-message 
  210.  
  211.                   MultipartType ::=                       ENUMERATED {                           mixed(1),                           alternative(2),                           digest(3),                           parallel(4)                       } 
  212.  
  213.    If this heading is present when mapping from MHS to MIME, then the    appropriate multipart content-type should be generated. 
  214.  
  215. 4.  Mapping between X.400 and RFC-822 Message Headers 
  216.  
  217.    Replace the first paragraph of Section 3.3.4 on page 26 of RFC-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: 
  218.  
  219.         1) If all the characters in the string are contained within the         ASCII repertoire, the string is simply copied. 
  220.  
  221.         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. 
  222.  
  223.         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 used 
  224.  
  225.  
  226.  
  227. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 7] 
  228.  RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993 
  229.  
  230.          [CCITT/ISO88a].  These will then be encoded in ASCII. 
  231.  
  232.         This approach will only be used for human-readable information         (Subject and FreeForm Name). 
  233.  
  234.         When mapping from an RFC-822 header, when an encoded-word (as         defined in [5]) is encountered: 
  235.  
  236.         1) If all the characters contained therein are mappable to T.61,         the string content shall be converted into T.61. 
  237.  
  238.         2) Otherwise, the encoded-word shall be copied directly into the         T.61 string. 
  239.  
  240.    Modify procedure "2a" on page 56 of RFC-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. 
  241.  
  242.    Modify the final paragraph of procedure "2" on page 55 of RFC-1327 to    read as:         The string is then encoded into T.61 or ASCII using a human-         oriented mapping (as described in Section 3.3.4).  If the string         is not null, it is assigned to IPMS.ORDescriptor.free-form.name. 
  243.  
  244.    Modify the second paragraph of procedure "3" on page 55 of RFC-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 in         Section 3.3.4), and an IPMS.ORDescriptor with only an free-         form-name component is built from it. 
  245.  
  246.    Modify procedure "822.Subject" on page 62 of RFC-1327 to read as: 
  247.  
  248.         Mapped to IMPS.Heading.subject.  The field-body uses the human-         oriented mapping referenceed in Section 3.3.4. 
  249.  
  250.    Modify procedure "IPMS.Heading.subject" on page 71 of RFC-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. 
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  Alvestrand, Kille, Miles, Rose & Thompson                       [Page 8] 
  259.  RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993 
  260.  
  261.  5.  OID Assignments 
  262.  
  263.    MIME-MHS DEFINITIONS ::= BEGIN 
  264.  
  265.     mail OBJECT IDENTIFIER ::= { internet 7 } 
  266.  
  267.    mime-mhs OBJECT IDENTIFIER ::= { mail 1 } 
  268.  
  269.    mime-mhs-headings OBJECT IDENTIFIER ::= { mime-mhs 1 } 
  270.  
  271.    id-hex-partial-message OBJECT IDENTIFIER ::=            { mime-mhs-headings 1 } 
  272.  
  273.    id-hex-multipart-message OBJECT IDENTIFIER ::=            { mime-mhs-headings 2 } 
  274.  
  275.     mime-mhs-bodies OBJECT IDENTIFIER ::= { mime-mhs 2 } 
  276.  
  277.     END 
  278.  
  279. 6.  Security Considerations 
  280.  
  281.    There are no explicit security provisions in this document.  However,    a warning is in order.  This document maps two mechanisms between    RFC822 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. 
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297. Alvestrand, Kille, Miles, Rose & Thompson                       [Page 9] 
  298.  RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993 
  299.  
  300.  7.  Authors' Addresses 
  301.  
  302.    Harald Tveit Alvestrand    SINTEF DELAB    N-7034 Trondheim    NORWAY 
  303.  
  304.    EMail: Harald.Alvestrand@delab.sintef.no 
  305.  
  306.     Steve Kille    ISODE Consortium    P.O. Box 505    London    SW11 1DX    England 
  307.  
  308.    Phone: +44-71-223-4062    EMail: S.Kille@ISODE.COM 
  309.  
  310.     Robert S. Miles    Soft*Switch, Inc.    640 Lee Road    Wayne, PA 19087 
  311.  
  312.    Phone: (215) 640-7556    EMail: rsm@spyder.ssw.com 
  313.  
  314.     Marshall T. Rose    Dover Beach Consulting, Inc.    420 Whisman Court    Mountain View, CA  94043-2186    US 
  315.  
  316.    Phone: +1 415 968 1052    Fax:   +1 415 968 2510    EMail: mrose@dbc.mtview.ca.us 
  317.  
  318.     Steven J. Thompson    Soft*Switch, Inc.    640 Lee Road    Wayne, PA 19087 
  319.  
  320.    Phone: (215) 640-7556    EMail: sjt@gateway.ssw.com 
  321.  
  322.  
  323.  
  324. Alvestrand, Kille, Miles, Rose & Thompson                      [Page 10] 
  325.  RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993 
  326.  
  327.  8.  References 
  328.  
  329.    [1] Crocker, D., "Standard for the Format of ARPA Internet Text        Messages", STD 11, RFC 822, UDEL, August 1982. 
  330.  
  331.    [2] Borenstein, N., and N. Freed, "MIME: Mechanisms for Specifying        and Describing the Format of Internet Message Bodies", RFC 1341,        Bellcore, Innosoft, June 1992. 
  332.  
  333.    [3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021        and RFC-822", RFC 1327, University College London, May 1992. 
  334.  
  335.    [4] Alvestrand, H., and S. Thompson, "Equivalences between 1988 X.400        and RFC-822 Message Bodies", RFC 1494, SINTEF DELAB, Soft*Switch,        Inc., August 1993. 
  336.  
  337.    [5] Moore, K., "Representation of Non-ASCII Text in Internet Message        Headers Message Bodies", RFC 1342, University of Tennesse, June        1992. 
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  Alvestrand, Kille, Miles, Rose & Thompson                      [Page 11] 
  370.  
  371.