summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1494.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1494.txt')
-rw-r--r--doc/rfc/rfc1494.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc1494.txt b/doc/rfc/rfc1494.txt
new file mode 100644
index 0000000..083d5a4
--- /dev/null
+++ b/doc/rfc/rfc1494.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group H. Alvestrand
+Request for Comments: 1494 SINTEF DELAB
+ S. Thompson
+ Soft*Switch, Inc.
+ August 1993
+
+ Equivalences between 1988 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 ............................................. 2
+ 2. Equivalence Table Definition ............................. 2
+ 3. Generic conversions ...................................... 3
+ 3.1. Byte copy .............................................. 3
+ 3.2. Text Conversion ........................................ 3
+ 3.3. Image Conversion ....................................... 3
+ 3.4. Tunneling .............................................. 3
+ 4. Conversion Table for known X.400 and MIME Types ......... 4
+ 4.1. MIME to X.400 Table .................................... 4
+ 4.2. X.400 to MIME Table .................................... 4
+ 5. Newly defined X.400 Body Parts ........................... 5
+ 5.1. Use of OBJECT IDENTIFIERs and ASN.1 MACROS ............. 5
+ 5.2. The Generic MIME Extended Body Part .................... 6
+ 5.3. The PostScript body part ............................... 7
+ 5.4. The JPEG body part ..................................... 7
+ 5.5. The GIF body part ...................................... 8
+ 6. Newly defined MIME content-types ......................... 8
+ 6.1. The application/x400-bp content-type ................... 8
+ 6.2. The image/g3fax content-type ........................... 9
+ 6.2.1. G3Fax Parameters ..................................... 9
+ 6.2.2. Content Encoding ..................................... 10
+ 6.3. The Application/ODA content-type ....................... 11
+ 7. Equivalence Definitions ................................... 11
+ 7.1. IA5Text - text/plain .................................... 11
+ 7.2. GeneralText - text/plain (ISO-8859) ..................... 12
+ 7.3. BilaterallyDefined - application/octet-stream .......... 13
+ 7.4. ODA - application/oda ................................... 14
+ 7.5. g3-facsimile - image/g3fax .............................. 15
+ 7.6. application/postscript - postscript-body-part .......... 16
+ 7.7. application/jpeg - jpeg-body-part ....................... 16
+
+
+
+Alvestrand & Thompson [Page 1]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ 7.8. image/gif - gif-body-part ............................... 16
+ 8. OID Assignments ........................................... 17
+ 9. IANA Registration form for new mappings ................... 17
+ 10. Security Considerations .................................. 18
+ 11. Authors' Addresses ....................................... 18
+ 12. References ............................................... 19
+
+1. Introduction
+
+ This document is a companion to [1], which defines the principles
+ behind interworking between MIME-based RFC-822 mail and X.400 mail.
+ This document describes the content of the "IANA MHS/MIME Equivalence
+ table" referenced in the companion document, and defines the initial
+ configuration of this table. Mappings for new MIME content-types
+ and/or X.400 body part types should be registered with the IANA to
+ minimize redundancy and promote interoperability.
+
+ In MIME, the term "content-type" is used to refer to an information
+ object contained in the body of a message. In contrast, X.400 uses
+ the term "body part type." In this document, the term "body part" is
+ used to refer to either.
+
+ Please send comments to the MIME-MHS mailing list:
+ <mime-mhs@surfnet.nl>.
+
+2. Equivalence Table Definition
+
+ For each MIME content-type/X.400 body part pair, the Equivalence
+ Table will contain an entry with the following sections:
+
+ X.400 Body Part
+ This section identifies the X.400 Body Part governed by this
+ Table entry. It includes any OBJECT IDENTIFIERs or other
+ parameters necessary to uniquely identify the Body Part.
+
+ MIME Content-Type
+ This section identifies the MIME content-type governed by this
+ Table entry. The MIME content-type named here must be
+ registered with the IANA.
+
+ Conversion Type
+ This section identifies the type of conversion applied. See the
+ section on Generic Conversions for an explanation of the
+ possible values.
+
+
+
+
+
+
+
+Alvestrand & Thompson [Page 2]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ Comments (optional)
+ This section gives any additional commentary that might be
+ useful in understanding the mapping between the X.400 and MIME
+ representations.
+
+ The initial Equivalence Table entries in this document are described
+ using this convention. Any future submissions to the IANA should
+ follow this format.
+
+3. Generic conversions
+
+3.1. Byte copy
+
+ This is the trivial case, that is, no conversion at all. The byte
+ stream is simply copied between MIME and X.400.
+
+ This is the preferred conversion, since it is the simplest.
+
+ Implementors and vendors will be registering OBJECT IDENTIFIERs and
+ MIME content-types for their various objects. They are STRONGLY
+ ENCOURAGED to specify their content formats such that a gateway can
+ use Byte Copy to map between them.
+
+ Note that in some cases, it is necessary to define exactly which
+ ASN.1 construct to replace with the content of the MIME object.
+
+3.2. Text Conversion
+
+ This type of conversion applies to text objects that cannot be mapped
+ using a simple Byte Copy. Conversion involves scanning and
+ reformatting the object. For example, the MIME and X.400 objects
+ might differ in their encoding of nonstandard characters, or line or
+ page breaks.
+
+3.3. Image Conversion
+
+ This conversion type applies to raster images, like Group 3 Facsimile
+ or JPEG. Again, it differs from Byte Copy in that it involves
+ scanning reformatting the byte stream. It differs from Text
+ Conversion in that it is pixel- oriented, rather than character-
+ oriented.
+
+3.4. Tunneling
+
+ This is not a conversion at all, but an encapsulation of the object.
+ This is the fallback conversion, used when no explicit mapping
+ applies.
+
+
+
+
+Alvestrand & Thompson [Page 3]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+4. Conversion Table for known X.400 and MIME Types
+
+ This section itemizes the equivalences for all currently known MIME
+ content-types and X.400 body parts.
+
+4.1. MIME to X.400 Table
+
+ MIME content-type X.400 Body Part Section
+ ----------------- ------------------ -------
+ text/plain
+ charset=us-ascii ia5-text 7.1
+ charset=iso-8859-x EBP - GeneralText 7.2
+ text/richtext no mapping defined 5.2
+ application/oda EBP - ODA 7.4
+ application/octet-stream bilaterally-defined 7.3
+ application/postscript EBP - mime-postscript-body 5.4, 7.6
+ image/g3fax g3-facsimile 6.2, 7.5
+ image/jpeg EBP - mime-jpeg-body 5.5, 7.7
+ image/gif EBP - mime-gif-body 5.6, 7.8
+ audio/basic no mapping defined 5.2
+ video/mpeg no mapping defined 5.2
+
+ Abbreviation: EBP - Extended Body Part
+
+4.2. X.400 to MIME Table
+
+ Basic Body Parts
+
+ X.400 Basic Body Part MIME content-type Section
+ --------------------- -------------------- -------
+ ia5-text text/plain;charset=us-ascii 7.1
+ voice No Mapping Defined 6.1
+ g3-facsimile image/g3fax 6.2, 7.5
+ g4-class1 no mapping defined 6.1
+ teletex no mapping defined 6.1
+ videotex no mapping defined 6.1
+ encrypted no mapping defined 6.1
+ bilaterally-defined application/octet-stream 7.3
+ nationally-defined no mapping defined 6.1
+ externally-defined See Extended Body Parts 6.1
+
+ X.400 Extended Body Part MIME content-type Section
+ ------------------------- -------------------- -------
+ GeneralText text/plain;charset=iso-8859-x 7.2
+ ODA application/oda 7.4
+ mime-postscript-body application/postscript 5.3, 7.6
+ mime-jpeg-body image/jpeg 5.4, 7.7
+ mime-gif-body image/gif 5.5, 7.8
+
+
+
+Alvestrand & Thompson [Page 4]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+5. Newly defined X.400 Body Parts
+
+ This section defines new X.400 Body Parts for the purposes of
+ interworking with MIME.
+
+ All new X.400 Body Parts defined here will be Extended Body Parts, as
+ defined in CCITT Recommendation X.420 [2].
+
+5.1. Use of OBJECT IDENTIFIERs and ASN.1 MACROS
+
+ X.420 dictates that Extended Body Parts shall:
+
+ (1) use OBJECT IDENTIFIERs (OIDs) to uniquely identify
+ the contents, and
+
+ (2) be defined by using the ASN.1 Macro:
+
+ EXTENDED-BODY-PART-TYPE MACRO::=
+ BEGIN
+ TYPE NOTATION ::= Parameters Data
+ VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
+
+ Parameters ::= "PARAMETERS" type "IDENTIFIED"
+ "BY" value(OBJECT IDENTIFIER)
+ | empty;
+ Data ::= "DATA" type
+ END
+
+ To meet these requirements, this document uses the OID
+
+ mime-mhs-bodies
+
+ defined in [1], as the root OID for X.400 Extended Body Parts defined
+ for MIME interworking.
+
+ Each Extended Body Part contains Data and optional Parameters, each
+ being named by an OID. To this end, two OID subtrees are defined
+ under mime-mhs-bodies, one for Data, and the other for Parameters:
+
+ mime-mhs-bp-data OBJECT IDENTIFIER ::=
+ { mime-mhs-bodies 1 }
+ mime-mhs-bp-parameter OBJECT IDENTIFIER ::=
+ { mime-mhs-bodies 2 }
+
+ All definitions of X.400 body parts submitted to the IANA for
+ registration must use the Extended Body Part Type macro for the
+ definition. See the next section for an example.
+
+
+
+
+Alvestrand & Thompson [Page 5]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ Lastly, the IANA will use the mime-mhs-bp-data and mime-mhs-bp-
+ parameter OIDs as root OIDs for any new MIME content-type/subtypes
+ that aren't otherwise registered in the Equivalence Table.
+
+5.2. The Generic MIME Extended Body Part
+
+ The following X.400 Body Part is defined to carry any MIME content-
+ type for which there is no explicit IANA registered mapping.
+
+ mime-body-part EXTENDED-BODY-PART-TYPE
+ PARAMETERS MimeParameters
+ IDENTIFIED BY mime-generic-parameters
+ DATA OCTET STRING
+ ::= mime-generic-data
+
+ MimeParameters ::=
+ SEQUENCE {
+ content-type IA5String,
+ content-parameters SEQUENCE OF
+ SEQUENCE {
+ parameter IA5String,
+ parameter-value IA5String
+ }
+
+ -- from RFC-1327, sec. 5.1.12
+ other-header-fields RFC822FieldList
+ }
+
+ mime-generic-parameters OBJECT IDENTIFIER ::=
+ { mime-mhs-bp-parameter 1 }
+ mime-generic-data OBJECT IDENTIFIER ::=
+ { mime-mhs-bp-data 1 }
+
+ To convert the MIME content-type into the X.400 mime- body-part:
+
+ (1) Copy the "type/subtype" string from the MIME
+ Content-Type: header field into
+ MimeParameters.content-type
+
+ (2) For each "parameter=value" string in the MIME
+ Content-Type header field, create a
+ MimeParameters.content-parameters structure, and copy
+ the "parameter" string into MimeParameters.content-
+ parameters.parameter field and the "value" string
+ into the paired MimeParameters.content-
+ parameters.parameter-value field.
+
+ (3) Convert the MIME body part into its canonical form.
+
+
+
+Alvestrand & Thompson [Page 6]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ (See appendix H of RFC 1341 [3] for a discussion
+ of canonical in this context.) Said another way,
+ reverse the transfer encoding to recover the original
+ byte stream.
+
+ (4) Copy the canonical byte stream into the mime-body-
+ part.data octet string.
+
+ (5) Remove the Content-type and the Content-transfer-
+ encoding header fields from the MIME body part's
+ RFC822 header.
+
+ (6) Any header fields starting with "Content-" in the
+ MIME body part is placed in the optional other-
+ header-fields structure. Note that this can only
+ occur when the MIME content-type occurs as part of a
+ "multipart" content-type.
+
+ The mapping from the X.400 mime-body-part to a MIME content-type is
+ the inverse of the above steps.
+
+5.3. The PostScript body part
+
+ The following Extended Body Part is defined for PostScript data
+ streams. It has no parameters.
+
+ postscript-body-part EXTENDED-BODY-PART-TYPE
+
+ DATA OCTET STRING
+ ::= mime-postscript-body
+
+ mime-postscript-body OBJECT IDENTIFIER ::=
+ { mime-mhs-bp-data 2 }
+
+5.4. The JPEG body part
+
+ The following Extended Body Part is defined for JPEG data streams.
+ It has no parameters.
+
+ jpeg-body-part EXTENDED-BODY-PART-TYPE
+ DATA OCTET STRING
+ ::= mime-jpeg-body
+
+ mime-jpeg-body OBJECT IDENTIFIER ::=
+ { mime-mhs-bp-data 3 }
+
+
+
+
+
+
+Alvestrand & Thompson [Page 7]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+5.5. The GIF body part
+
+ The following Extended Body Part is defined for GIF data streams. It
+ has no parameters.
+
+ gif-body-part EXTENDED-BODY-PART-TYPE
+ DATA OCTET STRING
+ ::= mime-gif-body
+
+ mime-gif-body OBJECT IDENTIFIER ::=
+ { mime-mhs-bp-data 4 }
+
+6. Newly defined MIME content-types
+
+ This section defines new MIME content-types for the purposes of
+ interworking with X.400.
+
+6.1. The application/x400-bp content-type
+
+ This content-type is defined to carry any X.400(88) body part for
+ which there is no registered IANA mapping.
+
+ The content-type field is
+
+ application/x400-bp
+
+ The parameters are:
+
+ bp-type=<INTEGER or OBJECT IDENTIFIER>
+
+ The body contains the raw ASN.1 IPM.body octet stream, including the
+ initial tag octet.
+
+ If the body is a basic body part, the bp-type parameter is set to the
+ number of the body part's context-specific tag, that is, the tag of
+ the IPMS.Body.BodyPart component.
+
+ If the body is an Extended Body Part, the bp-type parameter is set to
+ the OBJECT IDENTIFIER from
+
+ IPMS.body.externally-defined.data.direct-reference
+
+ No attempt is made to turn the parameters of Extended Body Parts into
+ MIME parameters. (This task is the responsibility of the recipient's
+ UA).
+
+ For example, a basic VideotexBodyPart will have
+
+
+
+
+Alvestrand & Thompson [Page 8]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ Content-type=application/x400-bp; bp-type=6
+
+ whilst a Extended Videotex body part will have
+
+ Content-type=application/x400-bp; bp-type=2.6.1.4.5
+
+ application/x400-bp will need a content-transfer-encoding of base64
+ or quoted-printable when carried in 7-bit MIME. Since there is no
+ way to know beforehand the content, it is recommended to just inspect
+ the first 1 KByte or so of data and choose the one that seems to
+ produce the more compact encoding.
+
+ If this is not feasible, Base64 is recommended.
+
+6.2. The image/g3fax content-type
+
+ This content-type is defined to carry G3 Facsimile byte streams.
+
+ In general, a G3Fax image contains 3 pieces of information:
+
+ (1) A set of flags indicating the particular coding
+ scheme. CCITT Recommendation T.30 defines how the
+ flags are transmitted over telephones. In this
+ medium, the flags are carried as parameters in the
+ MIME content-type header field.
+
+ (2) A structure that divides the bits into pages. CCITT
+ recommendation T.30 describes how to define page
+ boundaries. A page break algorithm is defined here
+ that is independent of how the image data is
+ conveyed.
+
+ (3) For each page, a sequence of bits that form the
+ encoding of the image. CCITT recommendation T.4
+ defines the bit image format. This is used without
+ change.
+
+6.2.1. G3Fax Parameters
+
+ The following parameters are defined:
+
+ (1) page-length - possible values: A4, B4 and Unlimited
+
+ (2) page-width - possible values: A3, A4, B4
+
+ (3) encoding - possible values: 1-dimensional, 2-
+ dimensional, Uncompressed
+
+
+
+
+Alvestrand & Thompson [Page 9]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ (4) resolution - possible values: Fine, Coarse
+
+ (5) DCS - a bit string, represented in Base64.
+
+ (6) pages - an integer, giving the number of pages in the
+ document
+
+ If nothing is specified, the default parameter settings are:
+
+ page-length=A4
+ page-width=A4
+ encoding=1-dimensional
+ resolution=Coarse
+
+ It is possible (but misleading) to view the representation of these
+ values as single-bit flags. They correspond to the following bits of
+ the T.30 control string and X.400 G3FacsimileParameters:
+
+ Parameter T.30 bit X.400 bit
+
+ page-length=A4 no bit set
+ page-length=B4 19 21
+ page-length=Unlimited 20 20
+
+ page-width=A4 no bit set
+ page-width=A3 18 22
+ page-width=B4 17 23
+
+ encoding=1-dimensional no bit set
+ encoding=2-dimensional 16 8
+ encoding=Uncompressed 26 30
+
+ resolution=Coarse no bit set
+ resolution=Fine 15 9
+
+ The reason for the different bit numbers is that X.400 counts bits in
+ an octet from the MSB down to the LSB, while T.30 uses the opposite
+ numbering scheme.
+
+ If any bit but these are set in the Device Control String, the DCS
+ parameter should be supplied.
+
+6.2.2. Content Encoding
+
+ X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT
+ STRINGs. Each BIT STRING is a page of facsimile image data, encoded
+ as defined by Recommendation T.4. The following content encoding is
+ reversible between MIME and X.400 and ensures that page breaks are
+
+
+
+Alvestrand & Thompson [Page 10]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ honored in the MIME representation.
+
+ An EOL is defined as a bit sequence of
+
+ 000000000001 (eleven zeroes and a one).
+
+ Each page of the message is delimited by a sequence of six (6) EOLs
+ that MUST start on a byte boundary. The image bit stream is padded
+ as needed to achieve this alignment.
+
+ Searching for the boundary is a matter of searching for the byte
+ sequence (HEX) 00 10 01 00 10 01 00 10 01, which cannot occur inside
+ the image.
+
+ See Section 7.5 for the algorithm on conversion between this encoding
+ and the X.400 encoding.
+
+ The Base64 content-transfer-encoding is appropriate for carrying this
+ content-type.
+
+6.3. The Application/ODA content-type
+
+ The "ODA" subtype of application is used to indicate that a body
+ contains information encoded according to the Office Document
+ Architecture [4] standards, using the ODIF representation format.
+ For application/oda, the Content- Type line should also specify an
+ attribute/value pair that indicates the document application profile
+ (DAP), using the key word "profile", and the document class, using
+ the keyword "class".
+
+ For the keyword "class", the values "formatted", "processable" and
+ "formatted-processable" are legal values.
+
+ Thus an appropriate header field might look like this:
+
+ Content-Type: application/oda; profile=Q112;
+ class=formatted
+
+ Consult the ODA standard [4] for further information.
+
+ The Base64 content-transfer-encoding is appropriate for carrying ODA.
+
+7. Equivalence Definitions
+
+7.1. IA5Text - text/plain
+
+ X.400 Body Part: IA5Text
+ MIME Content-type: text/plain; charset=US-ASCII
+
+
+
+Alvestrand & Thompson [Page 11]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ Conversion Type: Byte copy
+ 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.)
+
+7.2. GeneralText - text/plain (ISO-8859)
+
+ X.400 Body Part: GeneralText; CharacterSets in
+ 6,100,101,109,110,126,127,138,144,148
+ MIME Content-Type: text/plain; charset=ISO-8859-(1-9)
+ Conversion Type: Byte copy
+ Comments:
+
+ When mapping from X.400 to MIME, the character-set chosen from table
+ below according to the value of Parameters.CharacterSets.
+
+ 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 [5], 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"
+
+ NOTE: The GeneralText body part is defined in ISO 10021-8 [5], and
+ NOT in the corresponding CCITT recommendation. Its parameters were
+ heavily modified in a defect report, and will be a SET OF INTEGER
+ (indicating the ISO registry numbers of all the used sets) in the
+ next version of the standard.
+
+
+
+Alvestrand & Thompson [Page 12]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ 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-8 6, 148 Other Latin-using languages
+
+ 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 number in the above table, and then appending it to the id-
+ cs-eit-authority {1 0 10021 7 1 0} OID.
+
+ 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.
+
+7.3. BilaterallyDefined - application/octet-stream
+
+ X.400 Body Part: BilaterallyDefined
+ MIME Content-Type: Application/Octet-Stream (no parameters)
+ Conversion Type: Byte copy
+ Comments:
+
+ When mapping from MIME to X.400, if there are parameters present in
+ the Content-Type: header field, the conversion fails since the
+ BilaterallyDefined Body Part does not have any corresponding ASN.1
+ parameters.
+
+ DISCUSSION: The parameters "name" "type" and "conversions" are
+ advisory, but may in some cases give vital hints on the expected
+ handling of the file. The parameter "conversions" is not fully
+ defined, but it is expected that it will be useful, so we cannot drop
+ it and expect people to be satisfied.
+
+ The parameter "padding" changes the interpretation of the last byte
+ of the data, and so cannot be deleted.
+
+ An option is to prepend an IA5 body part that contains the parameter
+ text; this will aid unmodified readers, and can probably be made
+
+
+
+Alvestrand & Thompson [Page 13]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ reversible with suitable chicanery, but is it worth it????
+
+ Also, 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. 1992 X.400 defines a File Transfer
+ Body Part to solve this problem (i.e. binary file transfer through
+ email). The standard and its regional profiles are not solid enough
+ yet to exploit as a solution for this problem.
+
+7.4. ODA - application/oda
+
+ X.400 Body Part: ODA
+ MIME Content-Type: application/oda
+ Conversion Type: Byte copy
+ Comments:
+
+ The ODA body part is defined in the CCITT document T.411 [6],
+ appendix E, section E.2, "ODA identification in the P2 protocol of
+ MHS"
+
+ An abbreviated version of its ASN.1 definition is:
+
+ oda-body-part EXTENDED-BODY-PART-TYPE
+ PARAMETERS OdaBodyPartParameters
+ DATA OdaData
+ ::= id-et-oda
+
+ OdaBodyPartParameters ::= SET {
+ document-application-profile [0] OBJECT IDENTIFIER
+ document-architecture-class [1] INTEGER {
+ formatted (0)
+ processable (1)
+ formatted-processable(2)}}
+
+ id-et-oda OBJECT IDENTIFIER ::= { 2 8 1 0 1 }
+
+ Mapping from X.400 to MIME, the following is done:
+
+ The Parameters.document-application-profile is mapped onto the MIME
+ parameter "profile" according to the table below.
+
+ Profile OBJECT IDENTIFIER
+
+ Q112 { iso (1) identified-organization (3) ewos (16)
+ eg (2) oda (6) profile (0) q112 (1) }
+
+ The Parameters.document-architecture-class is mapped onto the MIME
+ parameter "class" according to the table below
+
+
+
+Alvestrand & Thompson [Page 14]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ String Integer
+
+ formatted formatted(0)
+ processable processable(1)
+ formatted-processable formatted-processable(2)
+
+ NOTE: This parameter is not defined in RFC 1341.
+
+ The body of the MIME content-type is the Data part of the ODA body
+ part.
+
+ When mapping from MIME to X.400, the following steps are done:
+
+ The Parameters.document-application-profile and Parameters.document-
+ architecture-class are set from the tables above. If any of the
+ parameters are missing, the values for Q112 and formatted-processable
+ are used.
+
+ It is an option for the gateway implementor to try to access them
+ from inside the document, where they are defined as
+
+ document-profile.document-characteristics.document-architecture-class
+
+ document-profile.document-characteristics.document-application-profile
+
+ Gateways are NOT required to do this, since the document-
+ characteristics are optional parameters. If a gateway does not, it
+ simply uses the defaulting rules defined above.
+
+ The OBJECT IDENTIFIERs for the document application profile and for
+ ODA {2 8 0 0} must be added to the Encoded Information Types
+ parameter of the message envelope.
+
+7.5. g3-facsimile - image/g3fax
+
+ X.400 Body part: g3-facsimile
+ MIME Content-Type: image/g3fax
+ Conversion Type: nearly Byte copy
+ Comments:
+
+ The Parameters of the X.400 G3Fax body part are mapped to the
+ corresponding Parameters on the MIME Image/G3Fax body part and vice
+ versa. Note that:
+
+ (1) If fineResolution is not specified, pixels will be
+ twice as tall as they are wide
+
+ (2) If any bit not corresponding to a specially named
+
+
+
+Alvestrand & Thompson [Page 15]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ option is set in the G3Fax NonBasicParameters, the
+ "DCS" parameter must be used.
+
+ (3) Interworking is not guaranteed if any bit apart from
+ those specially named are used in the
+ NonBasicParameters
+
+ From X.400 to G3Fax, the body is created in the following way:
+
+ (1) Any trailing EOL markers on each bitstring is
+ removed. The bistring is padded to a byte boundary.
+
+ (2) 6 consecutive EOL markers are appended to each
+ bitstring.
+
+ (3) The padded bitstrings are concatenated together
+
+ An EOL marker is the bit sequence 000000000001 (11 zeroes and a one).
+
+ From G3Fax to X.400, the body is created in the following way:
+
+ (1) The body is split into bitstrings at each occurrence
+ of 6 consecutive EOL markers, and trailing EOLs and
+ padding are removed
+
+ (2) Each bitstring is made into an ASN.1 BITSTRING
+
+ (3) The bitstrings are made into an ASN.1 SEQUENCE, which
+ forms the body of the G3Fax body part.
+
+7.6. application/postscript - postscript-body-part
+
+ X.400 Body Part: Extended Body Part, OID postscript-body-part
+ MIME Content-Type: application/postscript
+ Conversion Type: Byte Copy
+
+7.7. application/jpeg - jpeg-body-part
+
+ X.400 Body Part: Extended Body Part, OID jpeg-body-part
+ MIME Content-Type: application/jpeg
+ Conversion Type: Byte Copy
+
+7.8. image/gif - gif-body-part
+
+ X.400 Body Part: Extended Body Part, OID gif-body-part
+ MIME Content-Type: application/gif
+ Conversion Type: Byte Copy
+
+
+
+
+Alvestrand & Thompson [Page 16]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+8. OID Assignments
+
+ MIME-MHS-MAPPINGS DEFINITIONS ::= BEGIN
+
+
+ IMPORTS
+ mail, mime-mhs, mime-mhs-bodies
+ FROM MIME-MHS;
+
+ mime-mhs-bp-data OBJECT IDENTIFIER ::=
+ { mime-mhs-bodies 1}
+
+ mime-mhs-bp-parameter OBJECT IDENTIFIER ::=
+ { mime-mhs-bodies 2}
+
+ mime-generic-data OBJECT IDENTIFIER ::=
+ { mime-mhs-bp-data 1}
+
+ mime-generic-parameters OBJECT IDENTIFIER ::=
+ { mime-mhs-bp-parameter 1}
+
+ mime-postscript-body OBJECT IDENTIFIER ::=
+ { mime-mhs-bp-data 2}
+
+ mime-jpeg-body OBJECT IDENTIFIER ::=
+ { mime-mhs-bp-data 3}
+
+ mime-gif-body OBJECT IDENTIFIER ::=
+ { mime-mhs-bp-data 4};
+
+9. IANA Registration form for new mappings
+
+ To: IANA@isi.edu
+ Subject: Registration of new X.400/MIME content type mapping
+
+ MIME type name:
+
+ (this must have been registered previously with IANA)
+
+ X.400 body part:
+
+ X.400 Object Identifier for Data:
+
+ (If left empty, an OID will be assigned by IANA under
+ mime-mhs-bp-data)
+
+ X.400 Object Identifier for Parameters:
+
+
+
+
+Alvestrand & Thompson [Page 17]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+ (If left empty, an OID will be assigned by IANA under
+ mime-mhs-bp-parameter. If it is not used, fill in the
+ words NOT USED.)
+
+ X.400 ASN.1 Syntax:
+
+ (must be an EXTENDED-BODY-PART-TYPE macro, or reference to
+ a Basic body part type)
+
+ Conversion algorithm:
+
+ (must be defined completely enough for independent
+ implementation. It may be defined by reference to RFCs).
+
+ Person & email address to contact for further information:
+
+ INFORMATION TO THE SUBMITTER:
+
+ The accepted registrations will be listed in the "Assigned
+ Numbers" series of RFCs. The information in the
+ registration form is freely distributable.
+
+10. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+11. Authors' Addresses
+
+ Harald Tveit Alvestrand
+ SINTEF DELAB
+ N-7034 Trondheim
+ NORWAY
+
+ EMail: Harald.Alvestrand@delab.sintef.no
+
+
+ Steven J. Thompson
+ Soft*Switch, Inc.
+ 640 Lee Road
+ Wayne, PA 19087
+
+ Phone: (215) 640-7556
+ EMail: sjt@gateway.ssw.com
+
+
+
+
+
+
+
+
+Alvestrand & Thompson [Page 18]
+
+RFC 1494 X.400/MIME Body Equivalences August 1993
+
+
+12. References
+
+ [1] Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson,
+ "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495,
+ SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc, Dover Beach
+ Consulting, Inc., Soft*Switch, Inc., August 1993.
+
+ [2] CCITT Recommendation X.420 (1988), Interpersonal Messaging
+ System.
+
+ [3] Borenstein, N, and N. Freed, "MIME: Mechanisms for Specifying
+ and Describing the Format of Internet Message Bodies", RFC 1341,
+ Bellcore, Innosoft, June 1992.
+
+ [4] ISO 8613; Information Processing: Text and Office System; Office
+ Document Architecture (ODA) and Interchange Format (ODIF), Part
+ 1-8, 1989.
+
+ [5] ISO/IEC International Standard 10021, Information technology -
+ Text Communication - Message-Oriented Text Interchange Systems
+ (MOTIS) (Parts 1 to 8).
+
+ [6] CCITT Recommendation T.411 (1988), Open Document Architecture
+ (ODA) and Interchange Format, Introduction and General
+ Principles.
+
+ [7] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [8] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
+ and RFC-822", RFC 1327, University College London, May 1992.
+
+ [9] CCITT Recommendation T.4, Standardization of Group 3 Facsimile
+ Apparatus for Document Transmission (1988).
+
+ [10] CCITT Recommendation T.30, Procedures For Document Facsimile
+ Transmission in the General Switched Telephone Network (1988).
+
+ [11] CCITT, Data Communication Networks - Message Handling Systems -
+ Recommendations X.400 - X.420 (1988 version).
+
+ [12] Alvestrand, H., "X.400 Use of Extended Character Sets", RFC
+ 1502, SINTEF DELAB, August 1993.
+
+
+
+
+
+
+
+
+Alvestrand & Thompson [Page 19]
+ \ No newline at end of file