rfc2157.txt

中、英文RFC文档大全打包下载完全版 .

6.  Defined Equivalences

6.1.  IA5Text - text/plain

   X.400 Body Part: IA5Text MIME Content-type: text/plain; charset=US-
   ASCII Conversion Type: No conversion Comments:

   When mapping from X.400 to MIME, the "repertoire" parameter is
   ignored.

   When mapping from MIME to X.400, the "repertoire" parameter is set to
   IA5 (5).

   NOTE: The MIME Content-type headers are omitted, when mapping from
   X.400 to MIME, if and only if the IA5Text body part is the only body
   part in the IPMS.Body sequence.

   NOTE: IA5Text specifies the "currency" symbol in position 2/4. This
   is converted without comment to the "dollar" symbol, since the author
   of this document has seen many documents in which the position was
   intended to indicate "dollar" while he has not yet seen one in which
   the "currency" symbol is intended.

   (For reference: The T.50 (1988) recommendation, which defines IA5,
   talks about ISO registered set number 2, while ASCII, using the
   "dollar" symbol, is ISO registered set number 6. There are no other
   differences.)

   NOTE: It is not uncommon, though it is a violation of the standard,
   to use 8-bit character sets inside an IA5 body part. Gateways that
   can expect to encounter this situation should consider implementing
   something like the guidance given in RFC 1428 [MIMETRANS],
   "Transition of Internet Mail from just-send-8 to 8-bit SMTP/MIME",
   and generate appropriate charset parameters for the MIME messages
   they generate. This behavior is not required for MIXER conformance,
   since it is only needed when the base standards are violated.





Alvestrand                  Standards Track                    [Page 26]

RFC 2157                X.400/MIME Body Mapping             January 1998


6.2.  GeneralText - text/plain (ISO-8859)

   X.400 Body Part: GeneralText; CharacterSets in
                   6, 14, 42, 87, 100,101,109,110,126,127,138,144,148
   MIME Content-Type: text/plain; charset=ISO-8859-(1-9)
                               or iso-2022-jp
   Conversion Type: Text conversion without character change When
   mapping from X.400 to MIME, the character-set is chosen from the
   table below according to the value of Parameters.CharacterSets. If no
   match is found, and the gateway does not support a conversion, the
   character set shall be encoded as x-iso-nnn-nnn-nnn, where "nnn" is
   the numbers of the Parameters.CharacterSets, sorted in numeric order.

   When mapping from MIME to X.400, GeneralText is an Extended Body
   Part, hence it requires an OID.  The OID for the GeneralText body is
   defined in [MOTIS], part 8, annex D, as {2 6 1 4 11}. The OID for the
   parameters is {2 6 1 11 11}.

   The Parameters.CharacterSets is set from table below according to the
   value of "charset"


   The following table lists the MIME character sets and the
   corresponding ISO registry numbers. If no correspondence is found,
   this conversion fails, and the generic body part approach is used.

   MIME charset    ISO IR numbers          Comment
   -----------------------------------------------
   ISO-8859-1      6, 100                  West European "8-bit ASCII"
   ISO-8859-2      6, 101                  East European
   ISO-8859-3      6, 109                  <regarded as obsolete>
   ISO-8859-4      6, 110                  <regarded as obsolete>
   ISO-8859-5      6, 144                  Cyrillic
   ISO-8859-6      6, 127                  Arabic
   ISO-8859-7      6, 126                  Greek
   ISO-8859-8      6, 138                  Hebrew
   ISO-8859-9      6, 148                  Other Latin-using languages
   ISO-2022-JP     6, 14, 42, 87           Japanese

   When converting from MIME to X.400, generate the correct OIDs for use
   in the message envelope's Encoded Information Types by looking up the
   ISO IR numbers in the above table, and then appending each to the
   id-cs-eit-authority {1 0 10021 7 1 0} OID, generating 2-4 OIDs.

   Similar procedures can be used with other MIME charsets that map to a
   set of ISO character sets.





Alvestrand                  Standards Track                    [Page 27]

RFC 2157                X.400/MIME Body Mapping             January 1998


   The escape sequences to designate and invoke the relevant character
   sets in their proper positions must be added to the front of the
   GeneralText character string.

   For ISO 8859-1, the relevant escape sequence will be:

   ESC 28 42
         ASCII in G0

   ESC 2D 41
         ISO-IR-100 in G1

   ESC 21 41
         High control character set in C1

   ESC 7E
         Locking shift 1 Right

   These escape sequences are removed when converting from GeneralText
   to text/plain.

   Note that new character sets may be defined on both the Internet side
   and the X.400 side; a gateway MAY choose to implement more
   conversions in the same fashion.

   DISCUSSION:

   The conversion of text is a problematic one, and one in which it is
   likely that gateways should be given wide latitude to make decisions
   based upon their knowledge of the user's preferences. The text given
   below is thought to give the best approximation to a gateway
   conforming to current and anticipated usage in the MIME and X.400
   worlds, and is the way recommended when no knowledge of the
   recipient's capabilities exists.

   The lossless changes, such as normalizing escape sequences, can be
   done even when "conversion-prohibited" is set. If "conversion-with-
   loss-prohibited" is set, translation to a character set that is not
   able to encode all characters cannot be done, and the message should
   be non-delivered with an appropriate non-delivery reason.

   The common use of character sets in MIME is somewhat different from
   the rules given by X.400; in particular, it is common in MIME to
   assume that the character sets follow strict rules. For the ISO-
   8859-x character sets, it is assumed that they are designated and
   invoked at the beginning of the text, and that no designation or
   invocation sequences occur within the body of the text.




Alvestrand                  Standards Track                    [Page 28]

RFC 2157                X.400/MIME Body Mapping             January 1998


   The rules for ISO-2022-JP are given in RFC 1468 [2022-JP], and are
   even more particular, using a pure 7-bit encoding in which each line
   of text starts in ASCII.

   Therefore, the text must be "normalized" by going through the whole
   message, using a state machine or similar device to remove or rewrite
   all escape and shift sequences.

   Appendix A gives pseudocode for such a conversion.

   NOTE: In 1988, the GeneralText body part was defined in ISO 10021-8
   [MOTIS], and NOT in the corresponding CCITT recommendation; this was
   added later.  Also, the parameters have been heavily modified; they
   should be a SET OF INTEGER in the currently valid text.  Use the
   latest version of the standard that you can get hold of.

6.3.  BilaterallyDefined - application/octet-stream

   X.400 Body Part: BilaterallyDefined
   MIME Content-Type: Application/Octet-Stream (no parameters)
   Conversion Type: No conversion

   When mapping from MIME to X.400, if there are parameters present in
   the Content-Type: header field, they are removed.

   DISCUSSION:

   The parameters "name" "type" and "conversions" are advisory; name and
   conversions are depreciated in RFC 2046.

   The parameter "padding" changes the interpretation of the last byte
   of the data, but it is deemed better by the WG to delete this
   information than to non-deliver the body part. The "padding"
   parameter is rarely used with MIME.


   Use of BilaterallyDefined Body Parts is specifically deprecated in
   both 1988 and 1992 X.400.  It is retained solely for backward
   compatibility with 1984 systems, and because it is in common use.

6.4.  FTBP EMA Unknown Attachment - application/octet-stream

   X.400 Body Part: FTBP EMA Unknown Attachment
   MIME Content-Type: Application/Octet-Stream
   Conversion Type: No conversion






Alvestrand                  Standards Track                    [Page 29]

RFC 2157                X.400/MIME Body Mapping             January 1998


   The OID for the Unknown Attachment is { joint-iso-ccitt(2)
   country(16) us(840) organization(1) ema(113694) objects(2)
   messaging(2) attachments(1) unknown(1) }, or
   2.16.840.1.113694.2.2.1.1 for short.

   NOTE: Previous EMA drafts gave it as { iso(1) countries(2) usa(840)
   organization (1) ema (113694) objects(2) messaging(2) attachments(1)
   unknown (1)}, or 1.2.840.1.113694.2.2.1.1 for short.

   The parameters for this type must be mapped according to chapter 2.3,
   with the following extensions for the parameters of the
   application/octet-stream:

      If there is no Content-Disposition parameter with a filename, and
      there is a name parameter, the FTBP.FileTransferParameters.File-
      attributes.pathname is generated from this parameter. Note that
      RFC 2046 recommends not using the "name" parameter.

   The "type", "conversions" and "padding" attributes are ignored;
   "type" is for human consumption; "conversions" are discouraged in RFC
   2046.

   The body mapping is just copying the bytes in both directions.

6.5.  MessageBodyPart - message/RFC822

   X.400 body part: MessageBodyPart
   MIME Content-Type: message/RFC822
   Conversion Type: Special

   NOTE: If the headers of the X.400 MessageBodyPart contains the
   "multipart-message" heading extension with the isAMessage bit set
   (either explicitly or implicitly), the mapping should be to
   multipart/* according to section 6.6, below.

   To map an IPMS.MessageBodyPart, the full X.400 -> RFC 822 mapping  is
   recursively applied, to generate an RFC 822 Message.  If present, the
   IPMS.MessageBodyPart.parameters.delivery-envelope is used for the MTS
   Abstract Service Mappings.  If present, the
   IPMS.MessageBodyPart.parameters.delivery-time is mapped to the
   extended RFC 822 field "Delivery-Date:".

   When a message/RFC822 is contained within a MIME message, it is
   mapped to an IPMS.MessageBodyPart according to MIXER.  specification.
   Any mappings that would have been made to the MTS Abstract Service
   are placed in IPMS.MessageBodyPart.parameters.delivery-envelope.





Alvestrand                  Standards Track                    [Page 30]

RFC 2157                X.400/MIME Body Mapping             January 1998


6.6.  MessageBodyPart - multipart/*

   X.400 body part: MessageBodyPart
   MIME Content-Type: multipart/*
   Conversion Type: Special

   NOTE: If the headers of the X.400 MessageBodyPart do not contain the
   "multipart-message" heading extension with the "isAMessage" flag
   FALSE=, the mapping should be to message/RFC822.

   A MIME multipart is a set of content-types and not a message with a
   set of content types. When the multipart is at the outermost MIME
   header, elements of the multipart are mapped directly onto
   IPMS.Bodypart.

   When the MIME multipart is not at the outermost level, it is mapped
   to an IPMS.MessageBodyPart containing an IPMS.Bodypart for each
   element of the multipart.

   When a nested IPMS.Message is generated from a multipart, an
   IPMS.heading shall always be generated.  The only mandatory field is
   the IPMS.Heading.this-IPM message id, which shall be generated by the
   gateway.  An IPMS.Heading.subject field shall also be generated, in
   order to provide useful information to non-MIME capable X.400(88) UAs
   and to all X.400(84) UAs.  The subject field is set as follows
   according to the multipart subtype:

   mixed:
      "Multipart Message"

   alternative:
      "Alternative Body Parts containing the same information"

   digest:
      "Message Digest"

   parallel:
      "Body Parts interpreted in parallel"

   other:
      "Multipart Message (<subtype>)"

   For other types of multipart, the multipart subtype shall be included
   in the subject line.

   For each multipart, the following IPMS.HeadingExtension shall be
   generated, with the value set according to the subtype.




Alvestrand                  Standards Track                    [Page 31]

RFC 2157                X.400/MIME Body Mapping             January 1998


   If the multipart is the outermost multipart, and the subtype is
   "mixed", it may be omitted.

           multipart-message HEADING-EXTENSION
                   VALUE MultipartType
                    ::= id-hex-multipart-message-v2

           MultipartType ::= SEQUENCE {
                         subtype IA5String,
                         isAMessage BOOLEAN DEFAULT TRUE }

   The MultipartType contains the subtype, for example "digest".  If
   this heading is present when mapping from X.400 to MIME, the
   appropriate multipart may be generated.

   The isAMessage flag is needed because of the case where a message
   contains a ForwardedIPMessage, which itself was generated from a MIME
   message that was a Multipart; it is set whenever the multipart is the
   outermost level of nesting inside a Message/RFC822.

   NOTE:
      When downgrading to X.400/84, the content-type SHOULD be
      regenerated from this heading-extension and put into the RFC-822-