view Side-By-Side changes
draft X.400/MIME body equivalences July 95
Equivalences between 1988 X.400 and RFC-822 Message Bodies
Tue May 16 13:42:18 MET
Fri Sep 15 18:10:48 WET 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-01.txt. draft-ietf-mixer-bodymap-02.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] 1]
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,
[MIXER], 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 addition, this document describes the basic functions
used for manipulating multipart structures and tunneling
body parts for which no exact equivalent exists.
NOTE: 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] 2]
draft X.400/MIME body equivalences July 95
2. Equivalence Table Definition
For each MIME content-type/X.400
1.1. Philosophy of body part pair, conversion
At the
Equivalence Table will contain an entry with moment (Sept 1995) both the following
sections:
X.400 Body Part
This section identifies MIME and the X.400 Body Part governed
by this Table entry. It includes any OBJECT
IDENTIFIERs or other parameters necessary
worlds are in a state of flux with regards to uniquely
identify carrying
stuff that is not text around.
In such a situation, there is little chance of defining a
mapping between them that is the Body Part.
MIME Content-Type
This section identifies best for all people, all
of the MIME content-type
governed by time.
For this Table entry. reason, this specification allows a gateway
considerable latitude in deciding exactly what conversion
to apply.
The MIME content-type
named here must decision taken by the gateway may be registered with based on various
information sources:
(1) If the IANA.
Conversion Type
This section identifies gateway knows what body parts or content
types the type recipient is able to handle, or has
registered a particular set of conversion
applied. See the section on Generic Conversions preferences for an explanation of
user, and knows how to convert the possible values.
Comments (optional)
This section gives any additional commentary that
might be useful message
reasonably to those body parts, the gateway may
choose to convert body parts in understanding the mapping between message to
those types only.
(2) If the gateway gets a message with bad typing
information (like an X.400 and MIME representations.
The initial Equivalence Table entries in this document are
described using this convention. Any future submissions BP14 or FTAM "just a
file", it may apply heuristics like looking at
content or looking at filenames to figure out how
to deal with the IANA should follow this format.
Alvestrand, Thompson message.
(3) If the gateway gets indications (via special
headers or heading-extensions defined for the
purpose) that the sender wanted a particular
representation on the "other side", and the gateway
is able to satisfy the request, it may do so.
(4) If the gateway knows that the next hop for the
message has limited capabilities (like X.400/84),
it may choose to perform conversions appropriate
for that medium.
The rest of this document will, in most instances,
document the action that should be taken in the case where
the gateway knows nothing more about the recipient than
the fact that its next hop is Internet SMTP or X.400/88;
in some cases, special actions that can be applied to
Alvestrand, Thompson Exp Jan 96 [Page 3]
draft X.400/MIME body equivalences July 95
support other cases will be mentioned.
1.2. Describing an equivalence
The following information MUST be supplied when describing
an equivalence:
MIME type name (which must be preregistered)
X.400 body part (often BP15 or FTAM Body Part)
If the BP15 is used, the following information must be
given:
(1) X.400 Object Identifier for Data
(2) X.400 Object Identifier for Parameters
(3) X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART-
TYPE macro)
Conversion algorithm. If it fits within one of the
categories listed under "Generic conversions", this should
be referred; if not, the expected effect of "Conversion
prohibited" and "Conversion with loss prohibited" should
be noted.
The conversion must be specified with enough detail to
permit independent implementation; literature references
are acceptable.
Alvestrand, Thompson Exp Jan 96 [Page 4]
draft X.400/MIME body equivalences July 95
3.
2. Generic conversions
3.1.
2.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.
2.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.
In this case, "conversion prohibited" will prohibit the
conversion, while "conversion with loss prohibited" will
not.
2.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.
Alvestrand, Thompson Exp Jan 96 [Page 5]
draft X.400/MIME body equivalences July 95
In this case, "conversion prohibited" will prohibit the
conversion, while "conversion with loss prohibited" will
not.
Alvestrand, Thompson Exp Jan 96 [Page 5] 6]
draft X.400/MIME body equivalences July 95
4. Conversion
3. Equivalence 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
3.1. Equivalence Table format
For each MIME content-type content-type/X.400 body part pair, the
Equivalence Table will contain an entry with the following
sections:
X.400 Body Part Section
----------------- ------------------ -------
text/plain
charset=3Dus-ascii ia5-text 7.1
charset=3Diso-8859-x EBP - GeneralText 7.2
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.
Section/document reference
Reference to section of this document, or to the
other document that describes this mapping.
The initial Equivalence Table entries in this document are
described using this convention.
Further registrations of equivalences should be submitted
to the IANA after a public review, using the example form
given at the end of this document.
3.2. MIME to X.400 Table
MIME content-type X.400 Body Part Section
----------------- ------------------ -------
text/plain
charset=3Dus-ascii ia5-text 7.1
charset=3Diso-8859-x EBP - GeneralText 7.2
Alvestrand, Thompson Exp Jan 96 [Page 7]
draft X.400/MIME body equivalences July 95
text/richtext no mapping defined MIXER Tunnel
application/oda EBP - ODA 7.4
application/octet-stream bilaterally-defined 7.3
application/postscript EBP - mime-postscript-body 5.4, 7.6 [POSTSCRIPT]
image/g3fax g3-facsimile 6.2, 7.5 [IMAGES]
image/jpeg EBP - mime-jpeg-body 5.5, 7.7 [IMAGES]
image/gif EBP - mime-gif-body 5.6, 7.8 [IMAGES]
audio/basic no mapping defined MIXER Tunnel
video/mpeg no mapping defined MIXER Tunnel
message/rfc822 ForwardedIPMessage MIXER n.n
multipart/* ForwardedIPMessage n.n
Abbreviation: EBP - Extended Body Part
4.2.
3.3. X.400 to MIME Table
Basic Body Parts
X.400 Basic Body Part MIME content-type Section
--------------------- -------------------- -------
ia5-text text/plain;charset=3Dus-ascii 7.1
voice No Mapping Defined MIXER Tunnel
g3-facsimile image/g3fax 6.2, 7.5 [IMAGES]
g4-class1 no mapping defined MIXER Tunnel
teletex no mapping defined MIXER text/plain;charset=3Dteletex n.n
videotex no mapping defined MIXER Tunnel
encrypted no mapping defined MIXER Tunnel
bilaterally-defined application/octet-stream 7.3 n.n
nationally-defined no mapping defined MIXER Tunnel
externally-defined See Extended Body Parts below
ForwardedIPMessage message/rfc822 or multi MIXER multipart n.n
X.400 Extended Body Part MIME content-type Section
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 [ODA]
mime-postscript-body application/postscript 5.3, 7.6 [POSTSCRIPT]
mime-jpeg-body image/jpeg 5.4, 7.7 [IMAGES]
mime-gif-body image/gif 5.5, 7.8 [IMAGES]
Alvestrand, Thompson Exp Jan 96 [Page 7] 8]
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.
4. Use of OBJECT IDENTIFIERs and ASN.1 MACROS
X.420 dictates that Extended Body Parts shall:
(1) use OBJECT IDENTIFIERs
When one wants to define new BP15 body parts for use with
equivalences, it is important to know that 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::=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
mixer-bodies
defined in [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, mixer-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.
Alvestrand, Thompson Exp Jan 96 [Page 9]
draft X.400/MIME body equivalences July 95
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
NOTE: The following Extended Body Part is defined ASN.1 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 an ExternallyDefinedBodyPart is
ExternallyDefinedBodyPart ::=3D SEQUENCE { mixer-bp-data 2 }
5.3. The JPEG body part
The following Extended Body Part is defined for JPEG
parameters [0] ExternallyDefinedParameters OPTIONAL,
data
streams. It has no parameters.
jpeg-body-part EXTENDED-BODY-PART-TYPE
DATA OCTET STRING ExternallyDefinedData }
ExternallyDefinedParameters ::=3D mime-jpeg-body
Alvestrand, Thompson Exp Jan 96 [Page 9]
draft X.400/MIME body equivalences July 95
mime-jpeg-body OBJECT IDENTIFIER EXTERNAL
ExternallyDefinedData ::=3D
{ mixer-bp-data 3 }
5.4. The GIF body part EXTERNAL
The following Extended Body Part is defined ASN.1 for GIF data
streams. It has no parameters.
gif-body-part EXTENDED-BODY-PART-TYPE
DATA OCTET STRING EXTERNAL is (from X.208):
EXTERNAL ::=3D mime-gif-body
mime-gif-body [UNIVERSAL 8] IMPLICIT SEQUENCE
{direct-reference OBJECT IDENTIFIER OPTIONAL,
indirect-reference INTEGER OPTIONAL,
data-value-descriptor ObjectDescriptor OPTIONAL,
encoding CHOICE
{single-ASN1-type [0] ANY,
octet-aligned [1] IMPLICIT OCTET STRING,
arbitrary [2] IMPLICIT BIT STRING}}
ObjectDescriptor ::=3D
{ mixer-bp-data 4 } [UNIVERSAL 7] IMPLICIT GraphicString
There are a bit too many choices here; the common X.400
usage is to:
(1) Always use direct-reference
(2) Omit indirect-reference and data-value-descriptor
(3) Use the single-ASN1-type encoding only
Unfortunately, some implementations have chosen to use the
octet-aligned choice when constructing values where the
ASN.1 type is OCTET STRING, which of course caused
interoperability problems.
An attempt to specify that X.420 only allowed the single-
ASN1-type choice in the 1996 versions is still (Sept 1995)
being debated in ISO; the end result seems to be that all
Alvestrand, Thompson Exp Jan 96 [Page 10]
draft X.400/MIME body equivalences July 95
6. Newly defined
agree in principle that single-ASN1-type should be used,
but that one has to allow the generation of the octet-
aligned choice as being conformant.
5. Ground rules for generating the IPM Body from MIME content-types
This section defines new
X.400 and MIME content-types define extensible approaches for body
parts, and the
purposes of interworking with X.400.
6.1. The image/g3fax content-type
This content-type is defined ability to carry G3 Facsimile byte
streams.
In general, map a G3Fax image contains 3 pieces of
information:
(1) A set of flags indicating specific body part depends
on the particular coding
scheme. CCITT Recommendation T.30 defines how gateway's knowledge.
Where no mapping is known by the
flags are transmitted over telephones. In this
medium, gateway, it may choose to
drop the flags are carried as parameters in body part, or reject the
MIME content-type header field.
(2) A structure that divides message. It may also
encapsulate the bits into pages.
CCITT recommendation T.4 describes body part in a "return to
command mode" string; this is mechanism which can be used here to indicate
page breaks.
(3) For each page,
for any extended X.400 body part. This is specified
below. The option will depend on the gateway
configuration and its knowledge of the recipient
capabilities.
If the header does not contain a sequence 822.MIME-Version field,
then generate a IPMS.Body with a single IPMS.BodyPart of bits that form
type IPMS.IA5TextBodyPart with
IPMS.IA5TextBodyPart.parameters.repertoire set to the
encoding
default (ia5) containing the body of the image. CCITT recommendation T.4
defines RFC 822 message.
If 822.MIME-Version is present, then the bit image format. This body part is used without
change. The highest bit
analysed as a MIME message and the body is converted
according to the Equivalence Table.
6. Ground rules for generating the MIME Body from the
IPMS.Body
First, to support X.400(1984) mappings of Internet
Messages, the following procedure shall be followed.
If there is more than one body part, and the first byte body
part is IA5 starts with the string "RFC-822-Headers:" as
the first bit line, then the remainder of this body part shall
be appended to 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 RFC 822 header. This relies upon the
theory that this body part has been generated according to
Appedix B of MIXER. A gateway shall check the consistency
Alvestrand, Thompson Exp Jan 96 [Page 11]
draft X.400/MIME body equivalences July 95
(5) DCS - a bit string, represented in Base64.
(6) pages - an integer, giving the number
and syntax of pages in this body part, to ensure that the document
If nothing resulting
message is specified, conformant with RFC 822.
If the default parameter settings
are:
page-length=3DA4
page-width=3DA4
encoding=3D1-dimensional
resolution=3DCoarse
It remaining IPMS.Body consists of a single
IPMS.Bodypart, there are two possibilities.
(1) If it is possible (but misleading) to view the representation of these values as single-bit flags. They correspond type IPMS.IA5Text, then this is mapped
directly and no MIME encoding is used.
(2) All other parts are mapped according to the following bits
Equivalence Table.
If the IPMS.Body contains multiple IPMS.BodyPart fields,
then a MIME message of content type multipart is
generated. If all of the T.30 control string and X.400
G3FacsimileParameters:
Parameter T.30 bit X.400 bit
page-length=3DA4 no bit set
page-length=3DB4 19 21
page-length=3DUnlimited 20 20
page-width=3DA4 no bit set
page-width=3DA3 18 22
page-width=3DB4 17 23
encoding=3D1-dimensional no bit set
encoding=3D2-dimensional 16 8
encoding=3DUncompressed 26 30
resolution=3DCoarse no bit set
resolution=3DFine 15 9 body parts are messages, then
this is multipart/digest. Otherwise it is
multipart/mixed. The reason for components of the different bit numbers is that X.400
counts bits multipart are
generated in an octet from the MSB down to same order as in the LSB,
while T.30 uses IPMS.Body.
Each component is mapped according to the opposite numbering scheme.
If any bit but Equivalence
Table.
6.1. Information that is lost when mapping
RFC 1494bis defines mappings onto Body Part 15. Similar
considerations apply to body parts 1-14. MIME defines
fields which add information to MIME contents. Two of
these are set in the Device Control String, "Content-ID", and "Content-Description". When
mapping, this information must be discarded, unless the DCS parameter should
specific body part 15 mapping allows it to be supplied. retained.
6.2. Mapping the EMA FTBP parameters
EMA has defined a profile for use of the File Transfer
Body Part (FTBP). [28]
New mappings are expected to use this as the mechanism for
carrying body parts, and since it is important to have a
Alvestrand, Thompson Exp Jan 96 [Page 12]
draft X.400/MIME body equivalences July 95
6.1.2. Content Encoding
X.400 defines
consistent mapping for the g3-facsimile data stream as a SEQUENCE
of BIT STRINGs. Each BIT STRING is a page special FTBP parameters, these
are defined here.
The mapping of facsimile
image data, encoded as the body will depend on the attachment
being mapped, and so cannot be defined by Recommendation T.4. here. The
following content encoding is reversible between MIME and
X.400 and ensures that page breaks
headers are honored in the mapped as follows.
6.2.1. Parameter mapping MIME
representation.
An EOL to X.400
Content-ID:
If this is defined as a bit sequence of
000000000001 (eleven zeroes present, create an element
FTBP.FileTransferParameters.related-stored-file.
file-identifier.cross-reference.message-reference and a one).
Each page of
set it to the message IPM.MessageIdentifier derived from the
"Content-ID:".
FTBP.FileTransferParameters.related-stored-file.
relationship.descriptive-relationship is delimited by a sequence of six
(6) EOLs that MUST start on set to the
string "Internet MIME Body Part".
FTBP.FileTransferParameters.related-stored-file.
file-identifier.cross-refernce.application-
crossreference is set to a byte boundary. The image
bit stream null OCTET STRING.
Content-Description
This is padded with zeroes as needed mapped to achieve this
alignment.
Searching for the boundary is first string in
FTBP.FileTransferParameters.environment.user-visible-
string.
6.2.2. Parameter mapping X.400 to MIME
X.400 specifies a matter file transfer body part (FTBP). Generic
mapping of searching for FTBP is beyond the byte sequence (HEX) 00 10 01 00 10 01 00 10 01, scope of MIXER. EMA have
defined a profile of FTBP to carry attachments [28].
MIXER defines a mapping of FTBP to MIME, 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 intended
for
carrying use in conjunction with this content-type.
6.2. The Application/ODA content-type
The "ODA" subtype of application profile. FTBP is used
to indicate that
a body contains carry various pieces of 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 associated with an
attribute/value pair that indicates the document
application profile (DAP), using the
attachment. The key word "profile",
and the document class, using the keyword "class".
For mapping will be to correctly convert
the keyword "class", contents of the values "formatted",
"processable" and "formatted-processable" are legal
values. attachment. This specification also
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=3DQ112;
class=3Dformatted
Consult the ODA standard [ODA] for further information.
The Base64 content-transfer-encoding is appropriate
provides a mechanism for
carrying ODA.
7. Equivalence Definitions
7.1. IA5Text - text/plain
X.400 Body Part: IA5Text
MIME Content-type: text/plain; charset=3DUS-ASCII
Conversion Type: Byte copy
Comments:
When mapping from X.400 to MIME, the "repertoire"
parameter is ignored.
When mapping from MIME parameters which EMA
have recommended to X.400, be used in version 1.4 of the "repertoire"
parameter
specification. A BNF is set to IA5 (5).
NOTE: The MIME Content-type headers defined below:
ftbp-field =3D "FTBP-Object-Size" ":" integer
/ "FTBP-Creation-Date" ":" date-time
/ "FTBP-Modification-Date" ":" date-time
"FTBP-Read-Date" ":" date-time
Some parameters are omitted, when
mapping from X.400 encoded as graphical strings. To
map these to MIME, if ASCII, those characters that map directly are
mapped, and only if the IA5Text
body part others are translated to "?". This simple
non-reversible mapping is seen as appropriate for the only body part
application, and in line with the IPMS.Body sequence.
NOTE: IA5Text specifies spirit of the "currency" symbol in position
2/4. EMA
profile.
Editor's note
Is the refusal to consider extended characters
appropriate? Can RFC 1521 be used instead?
Mapping of the data will be dependent on the
attachment, its encoding, and the MIME
representation. These cannot be specified here.
Other FTBP Parameters are mapped as follows:
FileTransferParameters.environment.user-visible-string
This is converted without comment mapped to the "dollar"
symbol, since the author "Content-Description:" header.
The following elements of this document has seen many
documents in which the position was intended FileTransferParameters.file-
attributes are mapped as follows:
pathname
Mapped to indicate
"dollar" while he has not yet seen one "Content-Dispostion:", as defined in which the
"currency" symbol is intended.
(For reference: RFC
1806 [33]. The T.50 (1988) recommendation, which
defines IA5, talks about ISO registered EBNF.disposition-type is set number 2,
while ASCII, using to
"attachment", and the "dollar" symbol, filename is ISO registered
set number 6. There are no other differences.) included as a
parameter. For example:
Content-Disposition: attachment; filename=3D/var/joe=
/dodo.doc
It is expected that only the incomplete option will
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=3DISO-8859-(1-9)
Conversion Type: Byte copy
Comments:
When
be found, but the mapping from X.400 is used for either variant.
The separator between multiple components is "/".
date-and-time-of-creation
Mapped to MIME, the character-set chosen
from table below according "FTBP-Creation-Date:".
date-and-time-of-last-modification
Mapped to the value of
Parameters.CharacterSets.
When mapping from MIME "FTBP-Modification-Date:".
date-and-time-of-last-read-access
Mapped to X.400, GeneralText "FTBP-Read-Date:".
object-size
Mapped to "FTBP-Object-Size:".
6.3. Encapsulation in X.400
Where no mapping is an
Extended Body Part, hence it requires an OID. The OID for possible, the gateway may choose to
discard the GeneralText body is defined in [MOTIS], part 8, annex
D, as {2 6 1 4 11}. The OID for or to reject the parameters is {2 6 1
11 11}.
The Parameters.CharacterSets message. This will
depend on gateway policy, and configuration knowledge.
Another option is set from table below
according to "tunnel" the value of "charset"
NOTE: The GeneralText body part is defined part, by
encapsulating it in ISO 10021-8
[MOTIS], X.400. This section defines an
extended body part, based on body part 15, which may be
used to hold any MIME content.
mime-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS MimeParameters
IDENTIFIED BY id-mime-body-part-parameters
DATA OCTET STRING
::=3D id-mime-body-part
MimeParameters ::=3D
SEQUENCE {
content-type IA5String,
content-parameters SEQUENCE OF
SEQUENCE {
parameter IA5String,
parameter-value IA5String
}
other-header-fields RFC822FieldList
Alvestrand, Thompson Exp Jan 96 [Page 15]
draft X.400/MIME body equivalences July 95
}
The OBJECT IDENTIFIERS id-mime-body-part and NOT id-mime-body-
part-parameters are defined in Appendix D. A MIME content
is mapped onto this body part. The MIME headers of the corresponding CCITT
recommendation. Its parameters were heavily modified in
body part are mapped as follows:
Content-Type:
The "type/subtype" string is mapped to
MimeParameters.content-type.
For each "parameter=3Dvalue" string create a
defect report,
MimeParameters.content-parameters element. The
MimeParameters.content-Parameters.parameter field is
set to the parameter and will be a SET OF INTEGER (indicating the ISO registry numbers of MimeParameters.content-
parameters.parameter-value field is set to the value.
Other
Take all other headers and create
MimeParameters.other-header-fields, by concatenating
them together.
Convert the used sets) MIME body part into its canonical form, as
specified in the next
version Appendix H of MIME [9]. This canonical form
is used to generate the standard. mime-body-part.data octet string.
The following table lists Parameter mapping may be used independently of
the body part mapping (e.g., in order to use a different
encoding for a mapped MIME character sets and the
corresponding ISO registry numbers. If no correspondence
is found, this conversion fails, and the generic body part).
This body part
approach is used. contains all of the 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, information,
and so can be mapped back to MIME without loss of
information.
The OID id-mime-body-part is added to the Encoded
Information Types of the envelope.
Alvestrand, Thompson Exp Jan 96 [Page 16]
draft X.400/MIME body equivalences July 95
6.4. Tunnelling X.400 Body Parts
This section specifies a generic mechanism to map X.400
body parts to a MIME content. This allows for the body
part to be tunnelled through MIME. It may also be used
directly by an appropriately configured MIME UA.
This content-type is defined to carry any X.400
extended body part. The mapping of all standard X.400
body parts is defined in RFC1494bis. The content-type
field is "application/x400-bp". The parameter is defined
by the EBNF:
mime-parameter =3D "bp-type=3D" object-identifier
The EBNF.object-identifier is set to the OBJECT
IDENTIFIER from IPMS.body.externally-defined.data.direct-
reference .
For example, a Videotex body part will have
Content-type=3Dapplication/x400-bp; bp-type=3D2.6.1.4.5
The body contains the raw ASN.1 IPM.body octet
stream, including the initial tag octet. The content may
use a content- transfer-encoding of either base64 or
quoted-printable when carried in 7-bit MIME. It is
recommended to use the one which gives the more compact
encoding of the data. If this cannot be determined,
Base64 is recommended. No attempt is made to turn the
parameters of Extended Body Parts into MIME parameters, as
this cannot be done in a general manner.
Standard X.400 body parts may not be encoded directly
by this mechanism, but may be encoded indirectly by first
translating to the extended representation.
7. The Equivalence Table
7.1. IA5Text - text/plain
X.400 Body Part: IA5Text
MIME Content-type: text/plain; charset=3DUS-ASCII
Alvestrand, Thompson Exp Jan 96 [Page 17]
draft X.400/MIME body equivalences July 95
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.)
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, "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 behaviour is not required for MIXER conformance,
since it is only needed when the base standards are
violated.
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=3DISO-8859-(1-9)
Conversion Type: Text conversion without character change
Comments:
Alvestrand, Thompson Exp Jan 96 [Page 18]
draft X.400/MIME body equivalences July 95
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 capabilities exists.
The changes, such as normalizing escape sequences, should
not be done 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 nondelivered
with an appropriate nondelivery reason.
When mapping from X.400 to MIME, the character-set is
chosen from 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
may be encoded as x-iso-nnn-nnn-nnn, where "nnn" is the
numbers of the Parameters.CharacterSets, sorted in numeric
order.
Editor's note
This is a new idea. It gives you a fallback for all
cases, but is it useful?
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 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. The rules for
Alvestrand, Thompson Exp Jan 96 [Page 19]
draft X.400/MIME body equivalences July 95
ISO-2022-JP are given in RFC 1468, 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 all escape and shift
sequences.
Editor's note
I would like to have an appendix of 30 or so lines of
C code that do this state machine walk. Does anyone
have code lying around? (If it is 200 lines, it is
too much to include...)
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.
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 ASCI=
I"
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 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 languag=
es
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
Alvestrand, Thompson Exp Jan 96 [Page 20]
draft X.400/MIME body equivalences July 95
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.
Editor note
We need to describe the complete string for at least
one example of this.
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, they are
removed.
DISCUSSION:
The parameters "name" "type" and "conversions" are
advisory; name and conversions are depreciated in RFC
1521.
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 nondeliver
the body part. The "padding" parameter is rarely used
with MIME.
Editor note:
Is it better to recommend using FTBP with a bit-
oriented encoding when the "padding" parameter is
encountered? Do we care?
Alvestrand, Thompson Exp Jan 96 [Page 21]
draft X.400/MIME body equivalences July 95
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. 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. FTBP EMA Unknown Attachment -
application/octet-stream
X.400 Body Part: FTBP EMA Unknown Attachment
MIME Content-Type: Application/Octet-Stream
Conversion Type: Byte copy
NOTE: At the time of this writing (Sept 1995), support for
BilaterallyDefined is MUCH more widespead than support for
the FTBP body part, and definitely more widespread than
support for the EMA FTBP Unknown Attachment. Gateways
should only choose to generate this body part from
Application/OctetStream when it is believed that the
recipient is able to handle this body part.
The OID for the Unknown Attachment is { 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 for short.
The parameters for this type must be mapped according to
chapter <<<n>>>, with the following extensions for the
parameters of the application/octet-stream:
(1) 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 1521 recommends not using
the "name" parameter.
The "type", "conversions" and "padding" attributes
are ignored; "type" is for human consumption;
"conversions" are discouraged in RFC 1521.
Editor note:
Does there exist a bit-aligned storage to be used
Alvestrand, Thompson Exp Jan 96 [Page 15] 22]
draft X.400/MIME body equivalences July 95
When converting from MIME to X.400, generate the correct
OIDs for use in
when the message envelope's Encoded Information
Types "padding" parameter is present? This is not
recommended 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 EMA; do we want to designate and invoke have it?
Should the relevant
character sets in their proper positions must "type" parameter be added mapped into the FTBP
FileTransferParameters.Environment.UserVisibleString?
It seems to be more or less the front same kind of thing,
according to EMA.
The body mapping is just copying the GeneralText character string.
7.3. BilaterallyDefined bytes in both
directions.
7.5. MessageBodyPart - application/octet-stream message/rfc822
X.400 Body Part: BilaterallyDefined body part: MessageBodyPart
MIME Content-Type: Application/Octet-Stream (no parameters) message/rfc822
Conversion Type: Byte copy
Comments:
When mapping from MIME to X.400, if there are parameters
present in Special
NOTE: If the Content-Type: header field, headers of the conversion
fails since X.400 MessageBodyPart contains 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
"multipart-message" heading extension with the expected handling of isAMessage bit set
(either explicitly or implicitly), the file. The parameter
"conversions" is not fully defined, but it is expected
that it will mapping should be useful, so we cannot drop it and expect
people to be satisfied.
The parameter "padding" changes
multipart/*.
To map an IPMS.MessageBodyPart, the interpretation of full X.400 -> RFC 822
mapping is recursively applied, to generate an RFC 822 Message.
If present, the
last byte of IPMS.MessageBodyPart.parameters.delivery-envelope
is used for the data, and so cannot be deleted.
An option 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 prepend an IA5 body part IPMS.MessageBodyPart according to MIXER.
specification. Any mappings that contains the
parameter text; this will aid unmodified readers, and can
probably be would have been 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 the MTS
Abstract Service are placed in
IPMS.MessageBodyPart.parameters.delivery-envelope.
7.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 solid enough
yet contain the
"multipart-message" heading extension with the "isAMessage" flag FALSE=
,
the mapping should be to exploit as a solution for this problem. message/rfc822.
Alvestrand, Thompson Exp Jan 96 [Page 16] 23]
draft X.400/MIME body equivalences July 95
7.4. ODA - application/oda
X.400 Body Part: ODA
A MIME Content-Type: application/oda
Conversion Type: Byte copy
Comments:
The ODA body part multipart is defined in a set of content-types and not a message with
a set of content types. When the CCITT document T.411
[T.411], appendix E, section E.2, "ODA identification in multipart is at the P2 protocol outermost
MIME header and is either multipart/digest or multipart/mixed,
elements of MHS"
An abbreviated version the multipart are mapped directly onto IPMS.BodyPart.
In other cases, a MIME multipart is mapped to an
IPMS.MessageBodyPart containing an IPMS.BodyPart for each element
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 the multipart.
When a nested IPMS.Message is generated from X.400 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 MIME, 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 following is done:
The Parameters.document-application-profile is mapped onto multipart subtype shall
be included in the MIME parameter "profile" according to subject line.
For each multipart, 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 following IPMS.HeadingExtension
shall be generated, with the MIME parameter "class" value set according to the table below
String Integer
formatted formatted(0)
processable processable(1)
subtype:
multipart-message HEADING-EXTENSION
VALUE MultipartType
::=3D id-hex-multipart-message
MultipartType ::=3D SEQUENCE {
Alvestrand, Thompson Exp Jan 96 [Page 17] 24]
draft X.400/MIME body equivalences July 95
formatted-processable formatted-processable(2)
NOTE: This parameter is not defined in RFC 1341.
subtype IA5String,
isAMessage BOOLEAN DEFAULT TRUE }
The body of MultipartType contains the MIME content-type subtype, for example
"digest". If this heading is the Data part of the
ODA body part.
When present when mapping from MIME
X.400 to X.400, MIME, the following steps are
done: appropriate multipart may be generated.
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 isAMessage flag is an option for the gateway implementor to try to
access them from inside needed because of the document, case where they are
defined as
document-profile.document-characteristics.document-architecture-class
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,
message contains a ForwardedIPMessage, which itself was
generated from a MIME message that was a Multipart; it simply uses the defaulting rules defined
above.
The OBJECT IDENTIFIERs for is
set whenever the document application
profile and for ODA {2 8 0 0} must be added to multipart is the Encoded
Information Types parameter outermost level of the message envelope.
7.5. g3-facsimile - image/g3fax
nesting inside a Message/RFC822.
7.7. ia5 <- message/external-body
X.400 Body body part: g3-facsimile ia5 MIME Content-Type: image/g3fax message/external-
body Conversion Type: nearly Byte copy
Comments: Special
The Parameters message/external-body part points to an object that
can be retrieved using Internet protocols.
There are three cases to consider for the recipient's
capabilities:
(1) The user has no Internet access. In this case, the
user might be grateful if the gateway fetches the
body part and inserts it into the message. If the
body part is large or dynamic, it might not be
appropriate.
(2) The user has Internet access, but no UA support for
fetching external-body objects.
(3) The user has Internet access and UA support for
fetching external-body objects, based on an
understanding of this document.
Some access-types, like anonymous FTP, are easy to
resolve. Others, like the X.400 G3Fax body part Mailserver access-type, are mapped
almost impossible to resolve at a gateway.
To support the corresponding Parameters on second case above, the MIME Image/G3Fax body
part and vice versa. Note that: tunneling method
Alvestrand, Thompson Exp Jan 96 [Page 18] 25]
draft X.400/MIME body equivalences July 95
(1) If fineResolution
chosen is not specified, pixels will be
twice as tall to represent the body part as they are wide an IA5 body part,
inserting the string "MIME-Version: 1.0 (generated by
gateway)" at the beginning of the body part. (The part in
parentheses can be changed at will)
This will:
(1) Maximize the chance that the user will see the
message
(2) If any bit not corresponding Give the user hints that will enable him to fetch
the message using other Internet tools
(3) Identify the message (in a specially named
option is set fashion compatible with
RFC 1496, HARPOON) as a MIME object in a reliable
fashion, allowing UAs to support the G3Fax NonBasicParameters, fetching of
the
"DCS" parameter must be used.
(3) Interworking object if the UA implementor desires.
The gateway MAY support a configuration option to
retrieve; it MUST support the tunneling in IA5 when
retrieval is not guaranteed if any bit apart
from those specially named are used desired or not possible.
This points to an external body part. As this will not in
general be accessible to the
NonBasicParameters
From X.400 to G3Fax, recipient, the body
part shall be resolved at the gateway, unless it is created
already included in a multipart/alternative or the following
way:
(1) Any trailing EOL markers on each bitstring is
removed. The bit order
recipient UA is changed to conform known to be capable of handling a
message/external tunnelled body part. The gateway shall
obtain the
most common Internet encoding (highest bit body part and then map it as if it had been
included. If the expiration date of first
byte =3D first bit the external body
part has expired, the gateway may tunnel the body part.
Editor's Note:
There has been comment that this dereference should
be made more optional or the text changed in some
way. Input is solicited.
Alvestrand, Thompson Exp Jan 96 [Page 26]
draft X.400/MIME body equivalences July 95
7.8. ??? - message/partial
Editor's note: This specification seems incomplete, since
it does not specify what to do with the content of the G3Fax).
body part. Input solicited!
The bitstring following heading extension is
padded added, derived from the
message/partial parameters, in order to a byte boundary.
(2) 6 consecutive EOL markers are appended facilitate MIME
capable X.400 UAs to each
bitstring.
(3) The padded bitstrings are concatenated together
An EOL marker handle messages of this type:
partial-message HEADING-EXTENSION
VALUE PartialMessage
::=3D id-hex-partial-message
PartialMessage ::=3D
SEQUENCE {
number INTEGER,
total INTEGER,
id IA5String
}
7.9. ???? - multipart/appledouble
A specific mapping for multipart/appledouble is defined.
Noting that the bit sequence 000000000001 (11 zeroes
and fileTransferData component of an FTBP is a one).
From G3Fax to X.400,
SEQUENCE of EXTERNAL, the body is created in file data component of the following
way:
(1) The body
multipart is split into bitstrings at each
occurrence mapped onto the first of two elements of 6 consecutive EOL markers. Trailing
EOLs must NOT be removed, since the X.400
Implementor Guide recommends that each page should
end with 6 consecutive EOLs. (This
SEQUENCE, and the application/applefile component (the
finder and resource info) is a change mapped onto the second
element of the sequence. Applications which don't care
about the finder and resource info can, therefore, simply
ignore the second element and extract the data from RFC 1494).
(2) Each bitstring is made into an ASN.1 BITSTRING,
reversing the order
first element. The direct reference component of bits within each byte to
conforom the
first element is set to reflect the X.400 Implementors Guide
recommendation for bit order in original type/subtype
of the G3Fax body
part. MIME data component, according the OID's defined in
RFC1494bis.
Editor's Note:
This specification is clearly useful and needed.
Does it
belong in MIXER? Comments solicited.
Alvestrand, Thompson Exp Jan 96 [Page 19] 27]
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.
7.6.
7.10. Teletex - Text/Plain (Teletex)
X.400 Body Part: Teletex
MIME Content-Type: text/plain; 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 28]
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. image/jpeg - jpeg-body-part
X.400 Body Part: Extended Body Part, OID jpeg-body-part
MIME Content-Type: image/jpeg
Conversion Type: Byte Copy
7.9. image/gif - gif-body-part
X.400 Body Part: Extended Body Part, OID gif-body-part the MIME Content-Type: image/gif
Conversion Type: Byte Copy recipient can actually read the message.
Alvestrand, Thompson Exp Jan 96 [Page 21] 29]
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] 30]
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(1988), chapter 31.2 and Table
6/X.208.
The rules for encoding the datatype can be found in CCITT
recommendation 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]
Alvestrand, Thompson Exp Jan 96 [Page 23] 31]
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] 32]
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:
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. This has been
moved to a separate, Experimental document.
(3) All but the essential translations were moved to
separate documents.
(4) Description of tunneling, multipart and FTBP
parameters were moved here from MIXER.
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)
Alvestrand, Thompson Exp Jan 96 [Page 33]
draft X.400/MIME body equivalences July 95
[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
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] 34]
draft X.400/MIME body equivalences July 95
Table of Contents
Status of this Memo ................................ 1
1 Introduction ...................................... 3 2 Equivalence Table Definition ...................... 4
1.1 Philosophy of body part conversion .............. 3
1.2 Describing an equivalence ....................... 4
2 Generic conversions ............................... 5
3.1
2.1 Byte copy ....................................... 5
3.2
2.2 Text Conversion ................................. 5
3.3
2.3 Image Conversion ................................ 5
4 Conversion
3 Equivalence Table for known X.400 and MIME Types
................................................ 6
4.1 7
3.1 Equivalence Table format ........................ 7
3.2 MIME to X.400 Table ............................. 6
4.2 7
3.3 X.400 to MIME Table ............................. 6
5 Newly defined X.400 Body Parts .................... 8
5.1
4 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
5 Ground rules for generating the IPM Body from
MIME ........................................... 11
6 Newly defined Ground rules for generating the MIME content-types .................. Body from
the IPMS.Body .................................. 11
6.1 The image/g3fax content-type .................... 11
6.1.1 G3Fax Parameters .............................. 11
6.1.2 Content Encoding .............................. 13 Information that is lost when mapping ........... 12
6.2 The Application/ODA content-type ................ Mapping the EMA FTBP parameters ................. 12
6.2.1 Parameter mapping MIME to X.400 ............... 13
6.2.2 Parameter mapping X.400 to MIME ............... 13
6.3 Encapsulation in X.400 .......................... 15
6.4 Tunnelling X.400 Body Parts ..................... 17
7 The Equivalence Definitions ........................... 14 Table ............................. 17
7.1 IA5Text - text/plain ............................ 14 17
7.2 GeneralText - text/plain (ISO-8859) ............. 15 18
7.3 BilaterallyDefined - application/octet-stream
................................................ 16 21
7.4 ODA FTBP EMA Unknown Attachment - application/oda ........................... 17 applica=AD
tion/octet-stream .............................. 22
7.5 g3-facsimile MessageBodyPart - image/g3fax ...................... 18 message/rfc822 ................ 23
7.6 Teletex MessageBodyPart - Text/Plain (Teletex) .................. 20 multipart/* ................... 23
7.7 application/postscript - postscript-body-part
................................................ 21 ia5 <- message/external-body .................... 25
7.8 image/jpeg ??? - jpeg-body-part ..................... 21 message/partial ........................... 27
7.9 image/gif ???? - gif-body-part ....................... 21 multipart/appledouble .................... 27
7.10 Teletex - Text/Plain (Teletex) ................. 28
8 OID Assignments ................................... 22 30
9 Registration information for the Teletex charac=AD
ter set ........................................ 23 31
10 IANA Registration form for new mappings .......... 24 32
11 Changes from RFC 1494 ............................ 25 33
Alvestrand, Thompson Exp Jan 96 [Page 35]
draft X.400/MIME body equivalences July 95
12 References ....................................... 25 33
Alvestrand, Thompson Exp Jan 96 [Page 27] 36]
----