rfc1495.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 619 行 · 第 1/2 页

                      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: [e-mail]


   Steve Kille
   ISODE Consortium
   P.O. Box 505
   London
   SW11 1DX
   England

   Phone: [phone]
   EMail: [e-mail]


   Robert S. Miles
   Soft*Switch, Inc.
   640 Lee Road
   Wayne, PA 19087

   Phone: [phone]
   EMail: [e-mail]


   Marshall T. Rose
   Dover Beach Consulting, Inc.
   420 Whisman Court
   Mountain View, CA  94043-2186
   US

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Steven J. Thompson
   Soft*Switch, Inc.
   640 Lee Road
   Wayne, PA 19087

   Phone: [phone]
   EMail: [e-mail]



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]