view Side-By-Side changes
Equivalences between 1988 X.400 and RFC-822 Message Bodies
Tue May 16 13:42:18 MET DST 1995
Harald Tveit Alvestrand
UNINETT
Harald.T.Alvestrand@uninett.no
Steven J. Thompson
Soft*Switch, Inc.
sjt@gateway.ssw.com
Status of this Memo
The name of this draft is draft-ietf-mixer-bodymap-00.txt. draft-ietf-mixer-bodymap-01.txt.
The following text is required for all drafts:
This document is an Internet Draft. Internet Drafts
are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups.
Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are draft documents valid for a
maximum of six months. Internet Drafts may be
updated, replaced, or obsoleted by other documents at
any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other
than as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in
each Internet Draft directory to learn the current
status of this or any other Internet Draft.
This document is an update to RFC 1494, and will obsolete
it once it is ready for publication.
draft X.400/MIME body equivalences July 95
Please send comments to the MIXER mailing list:
<ietf-mixer@innosoft.com>
Alvestrand, Thompson Exp Jan 96 [Page 2]
draft X.400/MIME body equivalences July 95
1. Introduction
This document is a companion to [MIXER], 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.
Alvestrand, Thompson Exp Jan 96 [Page 3]
draft X.400/MIME body equivalences July 95
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.
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.
Alvestrand, Thompson Exp Jan 96 [Page 4]
draft X.400/MIME body equivalences July 95
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.
In this case, conversion can be performed even if
"conversion prohibited" is set in the X.400 message.
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.
In this case, "conversion prohibited" will prohibit the
conversion, while "conversion with loss prohibited" will
not.
Alvestrand, Thompson Exp Jan 96 [Page 5]
draft X.400/MIME body equivalences July 95
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
charset=3Dus-ascii ia5-text 7.1
charset=iso-8859-x
charset=3Diso-8859-x EBP - GeneralText 7.2
text/richtext no mapping defined MIXER
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 MIXER
video/mpeg no mapping defined MIXER
message/rfc822 ForwardedIPMessage MIXER
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 text/plain;charset=3Dus-ascii 7.1
voice No Mapping Defined MIXER
g3-facsimile image/g3fax 6.2, 7.5
g4-class1 no mapping defined MIXER
teletex no mapping defined MIXER
videotex no mapping defined MIXER
encrypted no mapping defined MIXER
bilaterally-defined application/octet-stream 7.3
nationally-defined no mapping defined MIXER
externally-defined See Extended Body Parts below
ForwardedIPMessage message/rfc822 or multi MIXER
X.400 Extended Body Part MIME content-type Section
------------------------- -------------------- -------
GeneralText text/plain;charset=iso-8859-x 7.2
Alvestrand, Thompson Exp Jan 96 [Page 6]
draft X.400/MIME body equivalences July 95
------------------------- -------------------- -------
GeneralText text/plain;charset=3Diso-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 Exp Jan 96 [Page 7]
draft X.400/MIME body equivalences July 95
In all cases where "MIXER" is named in the third column,
the fallback conversion described in [MIXER] is applied.
This conversion is not a "conversion" as defined in X.400,
so will be allowed no matter what is forbidden in the
X.400 per message flags.
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
[X.420].
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::= MACRO::=3D
BEGIN
TYPE NOTATION ::= ::=3D Parameters Data
VALUE NOTATION ::= ::=3D value (VALUE OBJECT IDENTIFIER)
Parameters ::= ::=3D "PARAMETERS" type "IDENTIFIED"
"BY" value(OBJECT IDENTIFIER)
| empty;
Data ::= ::=3D "DATA" type
END
To meet these requirements, this document uses the OID
mime-mhs-bodies
defined in [MAPPING], [MIXER], as the root OID for X.400 Extended
Body Parts defined for MIME interworking.
Each Extended Body Part contains Data and optional
Alvestrand, Thompson Exp Jan 96 [Page 8]
draft X.400/MIME body equivalences July 95
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:
mixer-bp-data OBJECT IDENTIFIER ::= ::=3D
{ mixer-bodies 1 }
mixer-bp-parameter OBJECT IDENTIFIER ::= ::=3D
{ mixer-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.
Lastly, the IANA will use the mixer-bp-data and mixer-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 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
::=
::=3D mime-postscript-body
mime-postscript-body OBJECT IDENTIFIER ::= ::=3D
{ mixer-bp-data 2 }
5.3. 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
::=
::=3D mime-jpeg-body
Alvestrand, Thompson Exp Jan 96 [Page 9]
draft X.400/MIME body equivalences July 95
mime-jpeg-body OBJECT IDENTIFIER ::= ::=3D
{ mixer-bp-data 3 }
5.4. 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
::=
::=3D mime-gif-body
mime-gif-body OBJECT IDENTIFIER ::= ::=3D
{ mixer-bp-data 4 }
Alvestrand, Thompson Exp Jan 96 [Page 10]
draft X.400/MIME body equivalences July 95
6. Newly defined MIME content-types
This section defines new MIME content-types for the
purposes of interworking with X.400.
6.1. 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 T.4 describes how a "return to define
page boundaries. A page break algorithm
command mode" string; this is defined used here that is independent of how the image data is
conveyed. to indicate
page breaks.
(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. The highest bit of the first byte is the
first bit of the T.4 bitstream.
6.1.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
(4) resolution - possible values: Fine, Coarse
Alvestrand, Thompson Exp Jan 96 [Page 11]
draft X.400/MIME body equivalences July 95
(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
page-length=3DA4
page-width=3DA4
encoding=3D1-dimensional
resolution=3DCoarse
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
page-length=3DA4 no bit set
page-length=B4
page-length=3DB4 19 21
page-length=Unlimited
page-length=3DUnlimited 20 20
page-width=A4
page-width=3DA4 no bit set
page-width=A3
page-width=3DA3 18 22
page-width=B4
page-width=3DB4 17 23
encoding=1-dimensional
encoding=3D1-dimensional no bit set
encoding=2-dimensional
encoding=3D2-dimensional 16 8
encoding=Uncompressed
encoding=3DUncompressed 26 30
resolution=Coarse
resolution=3DCoarse no bit set
resolution=Fine
resolution=3DFine 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.
Alvestrand, Thompson Exp Jan 96 [Page 12]
draft X.400/MIME body equivalences July 95
6.1.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 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 with zeroes 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.2. 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 [ODA] 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:
Alvestrand, Thompson Exp Jan 96 [Page 13]
draft X.400/MIME body equivalences July 95
Thus an appropriate header field might look like this:
Content-Type: application/oda; profile=Q112;
class=formatted profile=3DQ112;
class=3Dformatted
Consult the ODA standard [ODA] 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 charset=3DUS-ASCII
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.)
Alvestrand, Thompson Exp Jan 96 [Page 14]
draft X.400/MIME body equivalences July 95
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) charset=3DISO-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 [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"
NOTE: The GeneralText body part is defined in ISO 10021-8
[MOTIS], 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.
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
Alvestrand, Thompson Exp Jan 96 [Page 15]
draft X.400/MIME body equivalences July 95
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 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.
Alvestrand, Thompson Exp Jan 96 [Page 16]
draft X.400/MIME body equivalences July 95
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
[T.411], 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
::=
::=3D id-et-oda
OdaBodyPartParameters ::= ::=3D SET {
document-application-profile [0] OBJECT IDENTIFIER
document-architecture-class [1] INTEGER {
formatted (0)
processable (1)
formatted-processable(2)}}
id-et-oda OBJECT IDENTIFIER ::= ::=3D { 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
String Integer
formatted formatted(0)
processable processable(1)
Alvestrand, Thompson Exp Jan 96 [Page 17]
draft X.400/MIME body equivalences July 95
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
document-profile.document-characteristics.document-application-profil=
e
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:
Alvestrand, Thompson Exp Jan 96 [Page 18]
draft X.400/MIME body equivalences July 95
(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
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 bit order is changed to conform to the
most common Internet encoding (highest bit of first
byte = =3D first bit of the G3Fax). The bitstring 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 markers. Trailing
EOLs and padding are removed must NOT be removed, since the X.400
Implementor Guide recommends that each page should
end with 6 consecutive EOLs. (This is a change
from RFC 1494).
(2) Each bitstring is made into an ASN.1 BITSTRING,
reversing the order of bits within each byte to
conforom to the X.400 Implementors Guide
recommendation for bit order in the G3Fax body
part.
Alvestrand, Thompson Exp Jan 96 [Page 19]
draft X.400/MIME body equivalences July 95
(3) The bitstrings are made into an ASN.1 SEQUENCE,
which forms the body of the G3Fax body part.
Alvestrand, Thompson Exp Jan 96 [Page 19]
draft X.400/MIME body equivalences July 95
7.6. Teletex - Text/Plain (Teletex)
X.400 Body Part: Teletex
MIME Content-Type: text/plain; charset=Teletex charset=3DTeletex
Conversion Type: Text conversion
Comments:
The Teletex body part is frequently used in X.400(84) to
send around text with slightly extended character sets
beyond ASCII.
Its body consists of a series of "pages", separated by
ASN.1 representation. It is important to many people to
have this mapped into something that is readable to most
end-users; therefore, it is recommended to map this onto
Text/Plain; however, since this is not plain text, the
conversion must be specified.
From X.400 to RFC-822, the conversion shall take the bytes
of all the pages in the "data" part of the
TeletexBodyPart, add a FF character (0x0C, control-L) to
each part that does not already end in one, and
concatenate them together to form the body of the
Text/Plain.
The character set shall be "Teletex", which is especially
registered for this purpose. Its definition is shown in an
appendix.
The parameters are discarded.
From RFC-822 to X.400, the conversion shall split the
content at each occurence of the FF character (0x0C),
delete the character and construct the Teletex body part
as a SEQUENCE OF TeletexString, as described in X.420(88),
section 7.3.5
The TeletexParameters may, but need not, contain the
number-of-pages component.
NOTE: It is recommended, but not mandated, that the data
be converted into a more widespread character set like
Alvestrand, Thompson Exp Jan 96 [Page 20]
draft X.400/MIME body equivalences July 95
ISO-8859-1 or ISO-2022-JP (if applicable) if possible.
This will result in the reverse translation giving a
GeneralText body part, which will have to be dealt with
appropriately at the X.400/88 to X.400/84 downgrading
Alvestrand, Thompson Exp Jan 96 [Page 20]
draft X.400/MIME body equivalences July 95
boundary, if possible, but will give a much greater chance
that the MIME recipient can actually read the message.
7.7. 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.8. application/jpeg image/jpeg - jpeg-body-part
X.400 Body Part: Extended Body Part, OID jpeg-body-part
MIME Content-Type: application/jpeg image/jpeg
Conversion Type: Byte Copy
7.9. image/gif - gif-body-part
X.400 Body Part: Extended Body Part, OID gif-body-part
MIME Content-Type: application/gif image/gif
Conversion Type: Byte Copy
Alvestrand, Thompson Exp Jan 96 [Page 21]
draft X.400/MIME body equivalences July 95
8. OID Assignments
MIXER-MAPPINGS DEFINITIONS ::= ::=3D BEGIN
EXPORTS -- everything --;
IMPORTS
experimental
FROM RFC1155-SMI;
mixer
FROM MIXER --Companion RFC--;
mixer-bp-data OBJECT IDENTIFIER ::= ::=3D
{ mixer-bodies 1};
mixer-bp-parameter OBJECT IDENTIFIER ::= ::=3D
{ mixer-bodies 2};
mime-generic-data OBJECT IDENTIFIER ::= ::=3D
{ mixer-bp-data 1};
mime-generic-parameters OBJECT IDENTIFIER ::= ::=3D
{ mixer-bp-parameter 1};
mime-postscript-body OBJECT IDENTIFIER ::= ::=3D
{ mixer-bp-data 2};
mime-jpeg-body OBJECT IDENTIFIER ::= ::=3D
{ mixer-bp-data 3};
mime-gif-body OBJECT IDENTIFIER ::= ::=3D
{ mixer-bp-data 4};
Alvestrand, Thompson Exp Jan 96 [Page 22]
draft X.400/MIME body equivalences July 95
9. Registration information for the Teletex character
set
The Teletex character set is a character set in which the
ISO 2022 character set switching mechanism may be used to
switch between the following registered ISO character
sets:
ISO-IR-87 - JIS_C6226-1983; a 16-bit Japanese character set
ISO-IR-102 - a fairly standard US-ASCII variant
ISO-IR-103 - Latin characters using nonspacing accents
ISO-IR-106 - Control characters for C0 use; CR, LF, FF and a few more.
ISO-IR-107 - Control characters for C1 use
Its intended use of this character set is to represent
data that comes from ISO protocols that use the ASN.1
construct "TeletexString" or "T61string" without
conversion.
The set of allowed character sets can be found in CCITT
recommendation X.208(1993), X.208(1988), chapter 31.2 and Table
6/X.208.
The rules for encoding the datatype can be found in CCITT
recommendation X.209(1993), X.209(1988), chapter 23. It states that at
the beginning of the string, G0 is always ISO-IR-102, C0
is ISO-IR-106, and C1 is ISO-IR-107.
The specification seems somehow to have missed the
implicit assumption that ISO-IR-103 is designated and
invoked as G1 and shifted into the upper half of the
character set which seems to be assumed at least by the
X.400 and X.500 software that uses TeletexStrings;
implementors should act as if the sequence ESC 2/9 7/6
LS1R is always present at the beginning of the data.
The rules for interpreting T.61 data are found (I believe)
in CCITT recommendations T.51, T.52 and T.53 (data from
the ITU WWW server):
T.51 (09/92) [Rev.1] [26 pp.] [Publ.: May.93]
Latin based coded character sets for telematic services
T.52 (1993) [New] [88 pp.] [Publ.: Apr.94]
Non-latin coded character sets for telematic services
T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95]
Character coded control functions for telematic services
Note - C: 26/48/69
Alvestrand, Thompson Exp Jan 96 [Page 23]
draft X.400/MIME body equivalences July 95
Character coded control functions for telematic services
Note - C: 26/48/69
(The author has not yet obtained a copy of these, even
though they only cost SFR 70 from the ITU...)
The Teletex character set is closely related to (but not
identical with) that specified in ISO 6937.
No further restrictions are imposed by this registration;
in particular, character set switching can occur anywhere,
and there is no guarantee that the character sets will be
switched "back" at the end.
10. 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
mixer-bp-data)
X.400 Object Identifier for Parameters:
(If left empty, an OID will be assigned by IANA under
mixer-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
Alvestrand, Thompson Exp Jan 96 [Page 24]
draft X.400/MIME body equivalences July 95
implementation. It may be defined by reference to RFCs).
Person & email address to contact for further information:
Alvestrand, Thompson Exp Jan 96 [Page 24]
draft X.400/MIME body equivalences July 95
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.
11. Changes from RFC 1494
The following changes have been made since the publication
of RFC 1494:
(1) The Teletex body part mapping was added
(2) The G3Fax body part had the order of bits in its
body defined. It turned out that 2 implementations
had done this in opposite directions.
12. References
[RFC-822]
D.H. Crocker, Standard for the Format of ARPA
Internet Text Messages. Request for Comments 822,
(August, 1982).
[MIME]
N. Borenstein, N. Freed, MIME: Mechanisms for
Specifying and Describing the Format of Internet
Message Bodies. Request for Comments 1341, (June,
1992).
[MIXER]
S.E. Hardcastle-Kille, Mapping between X.400(1988) /
ISO 10021 and RFC-822. (in preparation)
[T.4]
CCITT Recommendation T.4, Standardization of Group 3
Facsimile Apparatus for Document Transmission (1988)
[T.30]
CCITT Recommendation T.30, Procedures For Document
Facsimile Transmission in the General Switched
Telephone Network (1988)
Alvestrand, Thompson Exp Jan 96 [Page 25]
draft X.400/MIME body equivalences July 95
Facsimile Transmission in the General Switched
Telephone Network (1988)
[T.411]
CCITT Recommendation T.411 (1988), Open Document
Architecture (ODA) and Interchange Format,
Introduction and General Principles
[MOTIS]
ISO/IEC International Standard 10021, Information
technology - Text Communication - Message-Oriented
Text Interchange Systems (MOTIS) (Parts 1 to 8)
[X.400]
CCITT, Data Communication Networks - Message Handling
Systems - Recommendations X.400 - X.420 (1988
version)
[X.420]
CCITT Recommendation X.420 (1988), Interpersonal
Messaging System
[RFC-X400USE]
Harald Tveit Alvestrand, X.400 use of extended
Character Sets, Internet Draft, June 1992
Alvestrand, Thompson Exp Jan 96 [Page 26]
draft X.400/MIME body equivalences July 95
Table of Contents
Status of this Memo ................................ 1
1 Introduction ...................................... 3
2 Equivalence Table Definition ...................... 4
3 Generic conversions ............................... 5
3.1 Byte copy ....................................... 5
3.2 Text Conversion ................................. 5
3.3 Image Conversion ................................ 5
4 Conversion Table for known X.400 and MIME Types
................................................ 6
4.1 MIME to X.400 Table ............................. 6
4.2 X.400 to MIME Table ............................. 6
5 Newly defined X.400 Body Parts .................... 8
5.1 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ...... 8
5.2 The PostScript body part ........................ 9
5.3 The JPEG body part .............................. 9
5.4 The GIF body part ............................... 10
6 Newly defined MIME content-types .................. 11
6.1 The image/g3fax content-type .................... 11
6.1.1 G3Fax Parameters .............................. 11
6.1.2 Content Encoding .............................. 13
6.2 The Application/ODA content-type ................ 13
7 Equivalence Definitions ........................... 14
7.1 IA5Text - text/plain ............................ 14
7.2 GeneralText - text/plain (ISO-8859) ............. 15
7.3 BilaterallyDefined - application/octet-stream
................................................ 16
7.4 ODA - application/oda ........................... 17
7.5 g3-facsimile - image/g3fax ...................... 18
7.6 Teletex - Text/Plain (Teletex) .................. 20
7.7 application/postscript - postscript-body-part
................................................ 21
7.8 application/jpeg image/jpeg - jpeg-body-part ............... ..................... 21
7.9 image/gif - gif-body-part ....................... 21
8 OID Assignments ................................... 22
9 Registration information for the Teletex charac charac=AD
ter set ........................................ 23
10 IANA Registration form for new mappings .......... 24
11 Changes from RFC 1494 ............................ 25
12 References ....................................... 25
Alvestrand, Thompson Exp Jan 96 [Page 27]
----