doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc1495.txt b/doc/rfc/rfc1495.txt
new file mode 100644
index 0000000..fd1faf9
--- /dev/null
+++ b/doc/rfc/rfc1495.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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
+
+            Mapping between X.400 and RFC-822 Message Bodies
+
+Status 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 Contents
+
+   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
+
+1.  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 one
+
+
+
+Alvestrand, 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 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.
+
+   Recently, the Internet Engineering Task Force (IETF) has developed an
+   document called,
+
+      Multipurpose Internet Mail Extensions
+
+   or MIME RFC-1341.  The title is actually misleading.  MIME defines
+   structure for Internet message bodies.  It is not an extension to
+   RFC-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 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.
+
+   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 loss
+
+
+
+Alvestrand, 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 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.
+
+3.  Mapping between X.400 and RFC-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 and RFC-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/rfc822
+
+   RFC-1327 specifies the mappings for headers.  Section 4 describes how
+   those mappings are modified by this document.  When mapping between
+
+
+
+Alvestrand, 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 to RFC-822
+
+   This section replaces the text in RFC-1327 starting at the bottom of
+   page 84,
+
+       The IPMS.Body is mapped into the RFC-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 of RFC-
+   1327.
+
+             If the IPMS.Body
+
+                  Body ::=
+                      SEQUENCE OF
+                          BodyPart
+
+   consists of a single body part, then the RFC-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 the RFC-
+   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 the RFC822
+   message body is NOT marked as a MIME content.  This prevents RFC822
+   mailers from invoking MIME function unnecessarily.
+
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson                       [Page 4]
+
+RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
+
+
+3.2.  Mapping from RFC-822 to X.400
+
+   First, replace the first paragraph of Section 5.1.3 on page 72 of
+   RFC-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 the RFC-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 of Section 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 subtypes
+
+
+
+
+Alvestrand, 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 in Section 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 Mappings
+
+3.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 and RFC-822 Message Headers
+
+   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:
+
+        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 used
+
+
+
+Alvestrand, 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 an RFC-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 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.
+
+   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.
+
+   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.
+
+   Modify procedure "822.Subject" on page 62 of RFC-1327 to read as:
+
+        Mapped to IMPS.Heading.subject.  The field-body uses the human-
+        oriented mapping referenceed in Section 3.3.4.
+
+   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.
+
+
+
+
+
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson                       [Page 8]
+
+RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
+
+
+5.  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 }
+
+
+   END
+
+6.  Security Considerations
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson                       [Page 9]
+
+RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
+
+
+7.  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.com
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson                      [Page 10]
+
+RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993
+
+
+8.  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
+       and RFC-822", RFC 1327, University College London, May 1992.
+
+   [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.
+
+   [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]
+
\ No newline at end of file