view Side-By-Side changes
draft X.400/MIME body equivalences July 95
Equivalences between X.400 and RFC-822 Message Bodies
Fri Sep 15 18:10:48 WET DST
Wed Oct 11 15:27:45 MET 1995
Harald Tveit Alvestrand
UNINETT
Harald.T.Alvestrand@uninett.no
Status of this Memo
The name of this draft is draft-ietf-mixer-bodymap-02.txt. draft-ietf-mixer-bodymap-03.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.
Please send comments to the MIXER mailing list:
<ietf-mixer@innosoft.com>
Alvestrand, Thompson
Alvestrand Exp Jan 96 [Page 1]
draft X.400/MIME body equivalences July 95
1. Introduction
This document is a companion to [MIXER], which defines the
principles behind and translation of headers for 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
[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 how to
minimize redundancy and promote interoperability.
In addition, this document describes the basic functions
used for manipulating multipart structures and tunneling map 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,
messages into MIME entities and vice versa, including the term "body part" is used to refer to
either.
Alvestrand, Thompson
handling of multipart messages and forwarded messages.
Alvestrand Exp Jan 96 [Page 2]
draft X.400/MIME body equivalences July 95
1.1. Philosophy of body part conversion
At the moment (Sept 1995) both the MIME and the X.400
worlds Glossary
The following terms are defined in a state of flux with regards to carrying
stuff that is not text around.
In such a situation, there is little chance this document:
Body part
Part of defining a
mapping between them message that is the best for all people, all
of has an unique type. This term
comes from X.400; the time.
For this reason, this specification allows a gateway
considerable latitude corresponding term in deciding exactly what conversion MIME (RFC
1521) is limited to apply.
The decision taken by use in parts of a multipart
message; the gateway term "body" may be based on various correspond better.
Content-type
Type information sources:
(1) If the gateway knows indicating what body parts or the content
types of a
body part actually is. This term comes from MIME; the recipient
corresponding X.400 term is able to handle, or has
registered a particular set "body part type".
Mapping
(noun): A description of preferences for an
user, and knows how to convert the message
reasonably to those body parts, the gateway may
choose to convert body parts in the message to
those types only.
(2) If the gateway gets a message with bad typing
information (like transform an X.400 BP14 or FTAM "just
body part into a
file", it may apply heuristics like looking at
content MIME body part, or looking at filenames to figure out how to deal with the message.
(3) If the gateway gets indications (via special
headers or heading-extensions defined for the
purpose) transform
a MIME body part into an X.400 body part.
Equivalence
A set of two mappings that the sender wanted taken together provide a particular
representation on the "other side",
lossless conversion between an X.400 body part and a
MIME body part
0 The process of encapsulating something from one of
the gateway
is able to satisfy mail systems in such a way that it can be carried
inside the request, other mail system. When tunneling, it may do so.
(4) If is
not expected that the other mail system can make
reasonable sense of the body part, but a gateway knows that back
into the next hop for first system will always be able to convert
the
message has limited capabilities (like X.400/84),
it may choose body part without loss back to perform conversions appropriate
for that medium. its original
format.
HARPOON mapping
The rest mapping of this document will, in most instances,
document the action that should be taken a MIME body part by putting it inside
an IA5 body with all headers and encoding intact.
First described in RFC 1496.
2. Basic rules for body part conversion
At the case where
the gateway knows nothing more about moment (Sept 1995) both the recipient than MIME and the fact that its next hop is Internet SMTP or X.400/88;
in some cases, special actions that can be applied X.400
worlds are in a state of flux with regards to
Alvestrand, Thompson carrying
stuff that is not text around.
In such a situation, there is little chance of defining a
Alvestrand 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
mapping between them that is used, the following information must be
given:
(1) X.400 Object Identifier for Data
(2) X.400 Object Identifier best for Parameters
(3) X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART-
TYPE macro)
Conversion algorithm. If it fits within one all people, all
of the
categories listed under "Generic conversions", time.
For this should
be referred; if not, the expected effect of "Conversion
prohibited" and "Conversion with loss prohibited" should
be noted.
The reason, this specification allows a gateway
considerable latitude in deciding exactly what 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
2. Generic conversions
2.1. Byte copy
This is the trivial case, that is, no conversion at all. apply.
The byte stream is simply copied between MIME and X.400.
This is the preferred conversion, since it is decision taken by the
simplest.
Implementors and vendors will gateway may be registering OBJECT
IDENTIFIERs and MIME content-types for their based on various
objects. They are STRONGLY ENCOURAGED to specify their
content formats such that a
information sources:
(1) If the gateway can use Byte Copy to
map between them.
Note that in some cases, it knows what body parts or content
types the recipient is necessary able to define exactly
which ASN.1 construct handle, or has
registered a particular set of preferences for an
user, and knows how to replace with convert the content of message
reasonably to those body parts, the
MIME object.
In this case, conversion can be performed even if
"conversion prohibited" is set gateway may
choose to convert body parts in the X.400 message.
2.2. Text Conversion
This type of conversion applies message to text objects
those types only.
(2) If the gateway gets indications (via special
headers or heading-extensions defined for the
purpose) that
cannot be mapped using the sender wanted a simple Byte Copy. Conversion
involves scanning particular
representation on the "other side", and reformatting the object. For
example, gateway
is able to satisfy the MIME and X.400 objects might differ request, it may do so. Such
a mechanism is defined in their
encoding chapter 4 of nonstandard characters, or line or page
breaks.
In this case, "conversion prohibited" will prohibit
document.
(3) If the
conversion, while "conversion gateway gets a message with loss prohibited" will
not.
2.3. Image Conversion
This conversion type applies to raster images, like Group
3 Facsimile bad typing
information (like an X.400 BP14 or JPEG. Again, it differs from Byte Copy in
that FTAM "just a
file", it involves scanning reformatting may apply heuristics like looking at
content or looking at filenames to figure out how
to deal with the byte stream.
It differs from Text Conversion in message.
(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.
(5) Where no mapping 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 known by the
conversion, while "conversion with loss prohibited" will
not.
Alvestrand, Thompson gateway, it may
choose to drop the body part, reject the message,
or encapsulate the body part in a mechanism which
can be used for any extended body part (tunneling),
as described in chapter 3. The choice may be
configurable, but a conformant MIXER gateway MUST
be able to be configured for tunneling.
Alvestrand Exp Jan 96 [Page 6] 4]
draft X.400/MIME body equivalences July 95
3. Equivalence Table for known X.400 and MIME Types
In many cases, a message that goes SMTP->X.400->SMTP will
arrive without loss of information.
In some cases, the reverse translation may not be
possible, or two gateways may choose to apply different
translations, based on the criteria above, leading to an
apparently inconsistent service.
In addition, service will vary because some gateways will
have implemented conversions not implemented by other
gateways.
This section itemizes is believed to be unavoidable.
The conformance requirements in chapter 7 describe what
the equivalences minimum conformance for all currently
known MIME content-types and X.400 body parts.
3.1. Equivalence Table format
For each MIME content-type/X.400 a MIXER gateway is with
respect to body part pair, conversion.
2.1. Generating the
Equivalence Table will IPM Body from MIME
If the header does not contain an entry a 822.MIME-Version field,
then generate a IPMS.Body with a single IPMS.BodyPart of
type IPMS.IA5TextBodyPart with
IPMS.IA5TextBodyPart.parameters.repertoire set to the following
sections:
X.400 Body Part
This section identifies
default (IA5) containing the X.400 Body Part governed
by this Table entry. It includes any OBJECT
IDENTIFIERs or other parameters necessary to uniquely
identify body of the Body Part.
MIME Content-Type
This section identifies RFC 822 message.
If 822.MIME-Version is present, the body is analyzed as a
MIME content-type
governed by this Table entry. The MIME content-type
named here must be registered with message and the IANA.
Section/document reference
Reference to section of this document, or body is converted according to the
other document that describes this mapping.
The initial Equivalence Table entries
mappings configured and implemented in this document are
described using this convention.
Further registrations the gateway.
2.2. Ground rules for generating the MIME Body from the
IPMS.Body
First, to support X.400(1984) mappings of equivalences should Internet
Messages, the following procedure shall be submitted followed.
If there is more than one body part, and the first body
part is IA5 starts with the string "RFC-822-Headers:" as
the first line, then the remainder of this body part shall
be appended to the IANA after a public review, using RFC 822 header. This relies upon the example form
given at
theory that this body part has been generated according to
Appendix B of MIXER. A gateway shall check the end
consistency and syntax of this document.
3.2. MIME body part, 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 ensure that
the resulting message is conformant with RFC 822.
Alvestrand Exp Jan 96 [Page 7] 5]
draft X.400/MIME body equivalences July 95
text/richtext no mapping defined Tunnel
application/oda EBP - ODA 7.4
application/octet-stream bilaterally-defined 7.3
application/postscript EBP - mime-postscript-body [POSTSCRIPT]
image/g3fax g3-facsimile [IMAGES]
image/jpeg EBP - mime-jpeg-body [IMAGES]
image/gif EBP - mime-gif-body [IMAGES]
audio/basic no mapping defined Tunnel
video/mpeg no mapping defined Tunnel
message/rfc822 ForwardedIPMessage n.n
multipart/* ForwardedIPMessage n.n
Abbreviation: EBP - Extended Body Part
3.3. X.400
If the remaining IPMS.Body consists of a single
IPMS.Bodypart, there are three possibilities.
(1) If it is of type IPMS.IA5Text, and the first line
is "MIME-Version: 1.0", it is assumed 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 Tunnel
g3-facsimile image/g3fax [IMAGES]
g4-class1 no mapping defined Tunnel
teletex text/plain;charset=3Dteletex n.n
videotex no mapping defined Tunnel
encrypted no mapping defined Tunnel
bilaterally-defined application/octet-stream n.n
nationally-defined no mapping defined Tunnel
externally-defined See Extended Body Parts below
ForwardedIPMessage message/rfc822 or multipart n.n
X.400 Extended Body Part MIME content-type Section
------------------------- -------------------- -------
GeneralText text/plain;charset=3Diso-8859-x 7.2
ODA application/oda [ODA]
mime-postscript-body application/postscript [POSTSCRIPT]
mime-jpeg-body image/jpeg [IMAGES]
mime-gif-body image/gif [IMAGES]
Alvestrand, Thompson Exp Jan 96 [Page 8]
draft X.400/MIME be a
HARPOON-mapped message. The complete body equivalences July 95
4. Use content
is then appended to the headers; the separating
blank line is inside the message. If an RFC 822
syntax error is discovered inside the message, it
may be mapped directly as described below instead.
(2) If it is of OBJECT IDENTIFIERs type IPMS.IA5Text, then this is mapped
directly and ASN.1 MACROS
When one wants no MIME encoding is used.
(3) All other parts are mapped according to define new BP15 the
mappings configured and implemented in the gateway.
If the IPMS.Body contains multiple IPMS.Bodypart fields,
then a MIME message of content type multipart is
generated. If all of the body parts for use with
equivalences, are messages, then
this is multipart/digest. Otherwise it is important to know that X.420 dictates
that Extended Body Parts shall:
(1) use OBJECT IDENTIFIERs (OIDs)
multipart/mixed. The components of the multipart are
generated in the same order as in the IPMS.Body.
Each component is mapped according to uniquely identify the contents, mappings
configured and
(2) be defined by using implemented in 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
mixer-bodies
defined in [MIXER], as gateway; any IA5 body
parts are checked to see if they are HARPOON mappings.
2.3. Mapping the root OID for X.400 Extended
Body Parts EMA FTBP parameters
EMA has defined a profile for MIME interworking.
Each Extended use of the File Transfer
Body Part contains Data and optional
Parameters, each being named by an OID. To this end, two
OID subtrees (FTBP). [28]
New mappings are defined under mixer-bodies, one for Data,
and expected to use this as the other mechanism 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
carrying body parts submitted parts, and since it is important to the IANA have a
consistent mapping for registration must use the Extended Body Part Type
macro for special FTBP parameters, these
are defined here.
The mapping of the definition. See body will depend on the next section for an
example.
Alvestrand, Thompson content-type in
Alvestrand Exp Jan 96 [Page 9] 6]
draft X.400/MIME body equivalences July 95
Lastly, the IANA will use
MIME and on the mixer-bp-data application-reference in FTBP, and mixer-bp-
parameter OIDs is not
specified here.
The following new RFC-822 headers are defined to support
this mapping:
ftbp-field =3D "FTBP-Object-Size" ":" integer
/ "FTBP-Creation-Date" ":" date-time
/ "FTBP-Modification-Date" ":" date-time
"FTBP-Read-Date" ":" date-time
Some parameters of the EMA Profile are encoded as root OIDs for ASN.1
GraphicStrings, which are troublesome because they can
contain any new MIME content-
type/subtypes that aren't otherwise ISO registered graphic character set.
To map these to ASCII for use in mail headers, the
Equivalence Table.
NOTE: The ASN.1 for an ExternallyDefinedBodyPart is
ExternallyDefinedBodyPart ::=3D SEQUENCE {
parameters [0] ExternallyDefinedParameters OPTIONAL,
data ExternallyDefinedData }
ExternallyDefinedParameters ::=3D EXTERNAL
ExternallyDefinedData ::=3D EXTERNAL
The ASN.1 for EXTERNAL is (from X.208):
EXTERNAL ::=3D [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 [UNIVERSAL 7] IMPLICIT GraphicString
There are a bit too many choices here; the common X.400
usage is to: gateway
may either:
(1) Always use direct-reference
(2) Omit indirect-reference and data-value-descriptor
(3) Use the single-ASN1-type RFC 1522 encoding only
Unfortunately, some implementations have chosen mechanism to use create
appropriate encoded-words for the
octet-aligned choice when constructing values where headers involved.
Note that in some cases, such as within Content-
Disposition filenames, the
ASN.1 type is OCTET STRING, encoded-words must be in
quotes, which is not the normal usage of course caused
interoperability problems.
An attempt to specify that X.420 only allowed encoded-
words.
(2) Apply the single-
ASN1-type choice normalization procedure given in Appendix
<n> to identify the 1996 versions ASCII characters of the string,
and replace all non-ASCII characters with the
question mark (?).
Both procedures are valid for MIXER gateways; the
simplified procedure of ignoring escape sequences and bit-
stripping the result is still (Sept 1995)
being debated NOT valid.
The following parameters are mapped in ISO; both directions:
Content-ID:
The mapping of this element is complex.
The Content-ID is encoded as an IPM.MessageIdentifier
and entered into the end result seems to be that all
Alvestrand, Thompson
FTBP.FileTransferParameters.related-stored-file.
file-identifier.cross-reference.message-reference.
FTBP.FileTransferParameters.related-stored-file.
Alvestrand Exp Jan 96 [Page 10] 7]
draft X.400/MIME body equivalences July 95
agree in principle that single-ASN1-type should be used,
but that one has
relationship.descriptive-relationship is set to allow the generation of the octet-
aligned choice as being conformant.
5. Ground rules for generating the IPM Body from
string "Internet MIME
X.400 and MIME define extensible approaches for body
parts, and the ability Body Part".
FTBP.FileTransferParameters.related-stored-file.
file-identifier.cross-reference.application-
crossreference is set to map a specific body part depends
on the gateway's knowledge.
Where no null OCTET STRING.
The reverse mapping is known by the gateway, it may choose to
drop only performed if the body part, or reject
FTBP.FileTransferParameters.related-stored-file.
relationship.descriptive-relationship has the message. It may also
encapsulate string
value "Internet MIME Body Part".
Content-Description
This is mapped to and from the body part first string in a mechanism which can be used
for any extended X.400 body part.
FTBP.FileTransferParameters.environment.user-visible-
string.
Content-Disposition
This field is specified
below. defined in [RFC 1806].
It is mapped to and from FileTransferParameters.file-
attributes.pathname.
The option will depend on EBNF.disposition-type is ignored when creating
the gateway
configuration FTBP pathname, and its knowledge of always set to "attachment"
when creating the recipient
capabilities. Content-Disposition header. For
example:
Content-Disposition: attachment; filename=3D/var/joe=
/dodo.doc
If the header does not contain a 822.MIME-Version field,
then generate a IPMS.Body filename starts with a single IPMS.BodyPart of
type IPMS.IA5TextBodyPart leading "/" character,
it generates an FTBP complete-pathname. If it starts
with
IPMS.IA5TextBodyPart.parameters.repertoire set to any other character, it generates an FTBP
incomplete-pathname.
It is expected that only the
default (ia5) containing incomplete option will
be found, but the mapping is used for either variant.
The separator between multiple components is "/".
Alvestrand Exp Jan 96 [Page 8]
draft X.400/MIME body of the RFC 822 message. equivalences July 95
FTBP-Creation-Date:
Mapped to and from FileTransferParameters.file-
attributes.date-and-time-of-creation
FTBP-Modification-Date:
Mapped to and from FileTransferParameters.file-
attributes.date-and-time-of-last-modification
FTBP-Read-Date:
Mapped to and from FileTransferParameters.file-
attributes.date-and-time-of-last-read-access
FTBP-Object-Size:
Mapped to and from FileTransferParameters.file-
attributes.object-size. If 822.MIME-Version is present, then the body part value is
analysed as a MIME message and "no-value-
available", the body header is converted
according NOT generated.
Other RFC-822 headers
Mapped to the Equivalence Table.
6. Ground rules for generating the MIME Body from the
IPMS.Body
First, to support X.400(1984) mappings second and subsequent elements of Internet
Messages,
FTBP.FileTransferParameters.environment.user-visible-
string. Headers are unfolded so that each header fits
within one user-visible-string component
(GraphicString does not allow CRLFs within the following procedure shall be followed.
string)
If there no content-disposition header is more than one body part, and present, the
first body
part element is IA5 starts with the string "RFC-822-Headers:" as
the first line, then the remainder of this body part shall
be appended set to an empty string.
On reverse mapping, all headers that conform to the
RFC 822 header. This relies upon the
theory that this body part has been generated according grammar are mapped to
Appedix B of MIXER. A gateway shall check headers in the consistency
Alvestrand, Thompson
bodypart.
Editor's note
This is new. I think it is a simple thing to do, does
Alvestrand Exp Jan 96 [Page 11] 9]
draft X.400/MIME body equivalences July 95
not cause damage, and syntax preserves information.
Comments?
2.3.1. Summary of this body part, to ensure that the resulting
message FTBP elements generated
This is conformant with RFC 822.
If a summary of the remaining IPMS.Body consists preceding section, and does not
add new information.
The following elements of a single
IPMS.Bodypart, there the FTBP parameters are two possibilities.
(1) If it is of type IPMS.IA5Text, then this is mapped
directly and no MIME encoding is used.
(2)
or used:
FileTransferParameters M/M
Related-Stored-File O/O
file-identifier
cross-reference
application-crossreference NULL
message-reference Content-ID
descriptive-relationship Used as marker
contents-type Must be unstructured-binary M/M
environment M/M
application-reference Selects mapping M/M
user-visible-string Content-description R/M
file-attributes
pathname Content-Disposition R/M
date-and-time-of-creation FTBP-Creation-Date O/O
date-and-time-of-last-modification FTBP-Modification-Date =
R/M
date-and-time-of-last-read-access FTBP-Read-Date O/O
object-size FTBP-Object-Size R/M
All other parts are mapped according to the
Equivalence Table.
If the IPMS.Body contains multiple IPMS.BodyPart fields,
then a MIME message of content type multipart is
generated. If all elements of the body parts FTBP parameters are messages, then
this is multipart/digest. Otherwise it discarded.
NOTE: There is
multipart/mixed. The components ongoing work on defining a more complete
mapping between FTBP headers and a set of RFC-822 headers.
A gateway MAY choose to support the multipart are
generated in the same order as in the IPMS.Body.
Each component is mapped according to the Equivalence
Table.
6.1. larger set once it is
available, but MUST support this limited set.
2.4. 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 "Content-ID", and "Content-Description". "Content-
Description", but MIME allows new entities to be defined
at any time.
Alvestrand Exp Jan 96 [Page 10]
draft X.400/MIME body equivalences July 95
When mapping, this information must be discarded, unless
the specific body part 15 mapping allows it to be
retained.
6.2. Mapping
3. Encapsulation of body parts
Where no mapping is possible, the EMA FTBP parameters
EMA has defined a profile for use gateway may choose any
of the File Transfer
Body Part (FTBP). [28]
New mappings are expected to use this as following alternatives:
Discard the mechanism for
carrying body parts, and since part, leaving a "marker" saying what
happened
Reject the message
"Tunnel" the body part, by encapsulating it is important to have in a
Alvestrand, Thompson Exp Jan 96 [Page 12]
draft X.400/MIME body equivalences July 95
consistent mapping
part defined for that purpose in the special FTBP parameters, these
are defined here. other mail
system
The mapping of choice to be made should be configurable in the body will
gateway, and may depend on the attachment
being mapped, and so cannot be defined here. The MIME
headers are mapped as follows.
6.2.1. Parameter mapping MIME to X.400
Content-ID:
If this is present, create an element
FTBP.FileTransferParameters.related-stored-file.
file-identifier.cross-reference.message-reference both policy and
set it to the IPM.MessageIdentifier derived from the
"Content-ID:".
FTBP.FileTransferParameters.related-stored-file.
relationship.descriptive-relationship is set to knowledge of
the
string "Internet recipient's capabilities.
3.1. Encapsulation of MIME Body Part".
FTBP.FileTransferParameters.related-stored-file.
file-identifier.cross-refernce.application-
crossreference is set to a null OCTET STRING.
Content-Description
This is mapped to the first string in
FTBP.FileTransferParameters.environment.user-visible-
string.
6.2.2. Parameter mapping X.400
Two body parts are defined here to tunnel MIME
X.400 specifies a file transfer body part (FTBP). Generic
mapping of FTBP is beyond parts
through X.400, one based on BP15 directly and the scope of MIXER. EMA have
defined a profile of FTBP to carry attachments [28].
MIXER defines a mapping of FTBP to MIME, which other
based on FTBP.
The BP15 body part is intended
for use in conjunction backwards compatible with this profile. RFC 1494.
The FTBP body part is used
to carry various pieces of information associated compatible with the EMA MAWG
document [MAWG].
3.1.1. BP15 tunneling body part
This section defines an
attachment. The key mapping will extended body part, based on body
part 15, which may be used to correctly convert
the contents of the attachment. This specification also
Alvestrand, Thompson 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
Alvestrand Exp Jan 96 [Page 13] 11]
draft X.400/MIME body equivalences July 95
provides a mechanism for mapping the parameters which EMA
have recommended to be used in version 1.4 of the
specification. A BNF is 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 encoded as graphical strings. To
map these to ASCII, those characters that map directly are
mapped,
MimeParameters ::=3D
SEQUENCE {
content-type IA5String,
content-parameters SEQUENCE OF
SEQUENCE {
parameter IA5String,
parameter-value IA5String
}
other-header-fields RFC822FieldList
}
The OBJECT IDENTIFIERS id-mime-body-part and others id-mime-body-
part-parameters are translated to "?". This simple
non-reversible mapping is seen as appropriate for the
application, and defined in line with the spirit of the 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 Appendix D. A MIME
representation. These cannot be specified here.
Other FTBP Parameters are mapped as follows:
FileTransferParameters.environment.user-visible-string
This content
is mapped to the "Content-Description:" header. onto this body part. The following elements MIME headers of FileTransferParameters.file-
attributes the
body part are mapped as follows:
pathname
Mapped to "Content-Dispostion:", as defined in RFC
1806 [33].
Content-Type:
The EBNF.disposition-type is set to
"attachment", and the filename is 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
be found, but the mapping is used for either variant.
The separator between multiple components is "/".
date-and-time-of-creation
Mapped to "FTBP-Creation-Date:".
date-and-time-of-last-modification
Mapped to "FTBP-Modification-Date:".
date-and-time-of-last-read-access
Mapped to "FTBP-Read-Date:".
object-size
Mapped to "FTBP-Object-Size:".
6.3. Encapsulation in X.400
Where no mapping is possible, the gateway may choose to
discard the body part or to reject the message. This will
depend on gateway policy, and configuration knowledge.
Another option is to "tunnel" the body part, by
encapsulating it in 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 id-mime-body-
part-parameters are defined in Appendix D. A MIME content
is mapped onto this body part. The MIME headers of the
body part are mapped as follows:
Content-Type:
The "type/subtype" string "type/subtype" string is mapped to
MimeParameters.content-type.
For each "parameter=3Dvalue" string create a
MimeParameters.content-parameters element. The
MimeParameters.content-Parameters.parameter field is
set to the parameter and the 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 MIME body part into its canonical form, as
specified in Appendix H of MIME [9]. This canonical form
is used to generate the mime-body-part.data octet string.
The Parameter mapping may be used independently of
the body part mapping (e.g., in order to use a different
encoding for a mapped MIME body part).
This body part contains all of the MIME information,
and so can be mapped back to MIME without loss of
information.
Alvestrand Exp Jan 96 [Page 12]
draft X.400/MIME body equivalences July 95
The OID id-mime-body-part is added to the Encoded
Information Types of the envelope.
Alvestrand, Thompson
This body part is completely compatible with RFC 1494.
3.1.2. FTBP tunneling body part
This body part utilizes the fundamental assumption in MIME
that all message content can be legally and completely
represented by a single octet stream, the "canonical
format".
The FTBP tunneling body part is defined by the
application-reference id-mime-ftbp-body; all headers are
mapped to the FTBP headers, including putting the
"Content-type:" header inside the UserVisibleString.
Translation from the MIME body part is done by:
Undoing the content-transfer-encoding
Setting the "FileTransferData.FTdata.value.octet-
aligned" to the resulting string of octets
Putting the appropriate parameters into the headers.
Reversing the translation is done by:
Extracting the headers
Applying an appropriate content-transfer-encoding to
the body. If this is for some reason different from
the content-transfer-encoding: header retrieved from
the headers, the old one must be deleted.
This mapping is lossless, and therefore counts as "no
conversion".
3.1.3. Tunneling using IA5
This approach is the one taken in RFC 1496 - HARPOON - for
tunneling any MIME body part through X.400/84 networks. It
Alvestrand Exp Jan 96 [Page 13]
draft X.400/MIME body equivalences July 95
has proven rather unhelpful for bringing information to
X.400 users, but preserves all the information of a MIME
body part.
The following IA5Text body part is made:
- Content =3D IA5String
- First bytes of content: (the description is in US
ASCII, with C escape sequences used to represent
control characters):
MIME-version: <version>\r\n
Content-type: <the proper MIME content type>\r\n
Content-transfer-encoding: <quoted-printable or base64>\r\n
<Possibly other Content headings here, terminated by\r\n>
\r\n
<Here follows the bytes of the content, encoded
in the proper encoding>
All implementations MUST place the MIME-version: header
first in the body part. Headers that are placed by [MIXER]
into other parts of the message MUST NOT be placed in the
MIME body part.
3.1.4. Tunneling using BP14
This is described in this section because it is at the
same conceptual level as tunneling. It is a lossy
transformation; it is impossible to reconstruct the MIME
type information from it.
Nevertheless, there is a demand for such functionality.
This tunneling simply strips off all headers, undoes the
content-transfer-encoding, and creates a
BilaterallyDefined body part (BP14) from the resulting
octet stream.
Alvestrand Exp Jan 96 [Page 14]
draft X.400/MIME body equivalences July 95
3.2. Tunneling X.400 Body Parts in MIME
This section specifies a generic mechanism to map X.400
body parts to a MIME content. This allows for the body
part to be tunneled 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.
3.3. Tunneling FTBP body parts in MIME
The File Transfer Body Part is believed to be important in
the future as "the" means of carrying well-identified data
in X.400 networks.
They also share the property (at lest when limited to the
Alvestrand Exp Jan 96 [Page 15]
draft X.400/MIME body equivalences July 95
EMA MAWG functional profile) of having a well-defined data
part that is always representable as a sequence of bytes.
This conversion will have to fail, and the x400-bp
encapsulation used instead, if:
FileTransferData has more than one element
Contents-type is not unstructured-binary
Parameters that are not mappable, but important, are
present (like Compression, which EMA doesn't
recommend).
Otherwise, it can be encapsulated in X.400 by:
Creating the "content-type" value by forming the
string "application/x-ftbp." and appending the
numbers of the OID
Mapping all other parameters according to the
standard FTBP parameter mapping
Applying an appropriate content-transfer-encoding
The choice of the somewhat strange, and by necessity
unregistered, MIME type "application/x-ftbp.n.n.n.n" is
because for any concrete example of this usage, it will be
easy to configure any MIME reader to take advantage of the
identification. If the MIME type registration rules are
ever changed to allow the registration of a namespace,
rather than just of names, the "x-" can be deleted, and
the types can be "application/ftbp.n.n.n.n".
4. User control over the gateway choice
In some cases, the gateway may make an inappropriate
choice when deciding what to do about a particular body
part.
To allow an escape clause, the following defines a way in
which the user can signal the gateway what action it finds
Alvestrand Exp Jan 96 [Page 16]
draft X.400/MIME body equivalences July 95
most appropriate.
The headers given here override any "conversion
prohibited" and "conversion with loss prohibited" on the
message.
It is still the gateway's responsibility that the
generated messages conform to the destination domain's
syntax rules.
4.1. Conversion from MIME to X.400
This header field specifies explicit MIXER conversion.
Comments are allowed within the field according to the
usual RFC 822 convention.
If "x400-object-id" is omitted, "tunnel" is assumed.
mime-to-x400 =3D "Wanted-X400-Conversion" ":"
[ mime-from ] [ x400-object-id ]
"in" x400-encoding
x400-object-id =3D "to" ( object-identifier-2 / "tunnel" )
x400-encoding =3D "bp14" / "bp15" / "ftbp" / "ia5"
mime-from =3D "from" mime-type
mime-type =3D word
There is no way to ask for a different conversion based on
MIME parameters or bodypart content.
Examples:
Wanted-X400-Conversion: from application/msword
to 1.2.840.113556.4.2 (Microsoft defined ms-word)
in ftbp
This uses the MAWG definitions, and leads to an FTBP encoding.
Wanted-X400-Conversion: from application/msword
to tunnel in bp14
This leads to a Body Part 14 encoding for all body parts of
application/msword.
Alvestrand Exp Jan 96 [Page 17]
draft X.400/MIME body equivalences July 95
Wanted-X400-Conversion: in bp14
This requests that this specific body part be encoded in Body Part 14.
This field may be used in two places:
(1) In the heading of an unstructured MIME body part.
In this case the EBNF.mime-from is omitted, and the
requested conversion applies to the body part.
(2) In a multipart. In this case, the body part type
to which the conversion applies is defined by
EBNF.mime-from, and the conversion applies to all
body parts of this MIME type contained in the
multipart, including those contained in nested
messages and multiparts. If a contained body part
has its own heading, this takes precedence. Note
that the "from" parameter is mandatory when used in
a multipart.
The EBNF.x400-object-id shall be present when "bp15" or
"ftbp" encoding is selected.
The value "tunnel" implies tunneling as defined in Chapter
3.
4.2. Conversion from X.400 to MIME
This IPM heading shall be present in the heading of a
message. It defines the mapping for all body parts of the
specified types, including those in nested messages.
wanted-MIME-conversion HEADING-EXTENSION
VALUE WantedMIMEConversions
::=3D id-wanted-MIME-conversions
WantedMIMEConversions ::=3D SEQUENCE OF X400toMIMEConversion
Alvestrand Exp Jan 96 [Page 18]
draft X.400/MIME body equivalences July 95
X400toMIMEConversion ::=3D SEQUENCE {
x400-type X400Type,
mime-type MIMEType }
X400Type ::=3D CHOICE {
standard [0] INTEGER, -- standard body part
extended [1] OBJECT IDENTIFIER, -- BP 15
ftbp [2] OBJECT IDENTIFIER} -- FTBP application-refere=
nce
MIMEType ::=3D SEQUENCE {
type IA5String, -- type (e.g., application/ms-word)
encoding [1] IA5String OPTIONAl -- e.g. quoted-printable
parameters [2] IA5String OPTIONAL } -- MIME Parameters
The heading extension includes all requested conversions,
with explicit information as to how each body part type is
encoded in MIME.
FTBP is identified as a separate body part type, as there
will be a need for different encodings, dependent on what
is being carried.
Tunneling is requested by asking for "application/x400-bp"
or "application/ftbp" as the destination type.
For FTAM body parts, only the parameters where an explicit
mapping is defined will survive the gatewaying process.
For other body parts, there are three alternatives:
(1) The gateway knows a defined mapping for this
particular body part. It will be used, and
parameters mapped accordingly.
(2) The gateway knows how to extract an OCTET STRING
from the body part, and the destination is a simple
MIME body part. All information outside the OCTET
STRING is lost, but the basis survives. (This may
be the case for a BP14 that should end up in an
application/xyzzy, for instance).
(3) The gateway knows of no relevant mapping, and does
not know how to simplify the X.400 body part. The
gateway will then proceed as if the mapping control
field had not been present.
Alvestrand Exp Jan 96 [Page 19]
draft X.400/MIME body equivalences July 95
5. The equivalence registry
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) Object Identifier for X.400 BP15 Data
(2) Object Identifier for X.400 BP15 Parameters
(3) X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART-
TYPE macro)
If the FTBP is used, the following information must be
given:
(1) Object Identifier for the FTAM
Environment.application-reference
(2) Object Identifier for the FTAM Contents-type, if
unstructured-binary is not used
(3) Any other special considerations
In all cases, the following must be given:
Conversion algorithms. 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.
An equivalence can be registered with IANA using the form
Alvestrand Exp Jan 96 [Page 20]
draft X.400/MIME body equivalences July 95
at the end of this document. The purpose of the
registration is to achieve a greater uniformity among
gateways implementing the same translation; there is no
requirement that a gateway must support all of the
translations that are registered with IANA. Specific
conformance requirements for MIXER are given at the end of
this document.
5.1. 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.
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.
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.
Alvestrand Exp Jan 96 [Page 21]
draft X.400/MIME body equivalences July 95
5.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
text/richtext no mapping defined Tunnel
application/oda EBP - ODA 7.4
application/octet-stream bilaterally-defined 7.3
application/postscript EBP - mime-postscript-body [POSTSCRIPT]
image/g3fax g3-facsimile [IMAGES]
image/jpeg EBP - mime-jpeg-body [IMAGES]
image/gif EBP - mime-gif-body [IMAGES]
audio/basic no mapping defined Tunnel
video/mpeg no mapping defined Tunnel
message/RFC822 ForwardedIPMessage n.n
multipart/* ForwardedIPMessage n.n
Abbreviation: EBP - Extended Body Part
5.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 Tunnel
g3-facsimile image/g3fax [IMAGES]
g4-class1 no mapping defined Tunnel
teletex text/plain;charset=3Dteletex n.n
videotex no mapping defined Tunnel
encrypted no mapping defined Tunnel
bilaterally-defined application/octet-stream n.n
nationally-defined no mapping defined Tunnel
externally-defined See Extended Body Parts below
ForwardedIPMessage message/RFC822 or multipart n.n
X.400 Extended Body Part MIME content-type Section
------------------------- -------------------- -------
GeneralText text/plain;charset=3DISO-8859-x 7.2
ODA application/oda [ODA]
mime-postscript-body application/postscript [POSTSCRIPT]
mime-jpeg-body image/jpeg [IMAGES]
Alvestrand Exp Jan 96 [Page 22]
draft X.400/MIME body equivalences July 95
mime-gif-body image/gif [IMAGES]
Alvestrand Exp Jan 96 [Page 16] 23]
draft X.400/MIME body equivalences July 95
6.4. Tunnelling X.400 Body Parts
This section specifies a generic mechanism
5.4. Use of OBJECT IDENTIFIERs and ASN.1 MACROS
When one wants to map X.400 define new BP15 body parts to a MIME content. This allows for the body
part 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 tunnelled through MIME. It may also be used
directly defined by an appropriately configured MIME UA.
This content-type is 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
mixer-bodies
defined to carry any in [MIXER], as the root OID for X.400
extended body part. The mapping Extended
Body Parts defined for MIME interworking.
Each Extended Body Part contains Data and optional
Parameters, each being named by an OID. To this end, two
OID subtrees are defined under 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 all standard X.400 body parts is defined 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 Exp Jan 96 [Page 24]
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 RFC1494bis. The content-type
field is "application/x400-bp". the
Equivalence Table.
NOTE: The parameter ASN.1 for an ExternallyDefinedBodyPart is defined
by the EBNF:
mime-parameter =3D "bp-type=3D" object-identifier
ExternallyDefinedBodyPart ::=3D SEQUENCE {
parameters [0] ExternallyDefinedParameters OPTIONAL,
data ExternallyDefinedData }
ExternallyDefinedParameters ::=3D EXTERNAL
ExternallyDefinedData ::=3D EXTERNAL
The EBNF.object-identifier ASN.1 for EXTERNAL is set to the (from X.208):
EXTERNAL ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE
{direct-reference OBJECT IDENTIFIER from IPMS.body.externally-defined.data.direct-
reference .
For example, 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 [UNIVERSAL 7] IMPLICIT GraphicString
There are 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 bit too many choices here; 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 common X.400
usage for BP15 encoding is
recommended to to:
(1) Always use direct-reference
(2) Omit indirect-reference and data-value-descriptor
(3) Use the one which gives the more compact single-ASN1-type encoding of only
Unfortunately, some implementations have chosen to use the data. If this cannot be determined,
Base64
octet-aligned choice when constructing values where the
ASN.1 type is recommended. No OCTET STRING, which of course caused
interoperability problems.
An attempt is made to turn specify that X.420 only allowed the
parameters of Extended Body Parts into MIME parameters, as
this cannot be done single-
ASN1-type choice in a general manner.
Standard X.400 the 1996 versions is still (Sept 1995)
being debated in ISO; the end result seems to be that all
Alvestrand Exp Jan 96 [Page 25]
draft X.400/MIME body parts may not equivalences July 95
agree in principle that single-ASN1-type should be encoded directly
by this mechanism, used,
but may be encoded indirectly by first
translating that one has to allow the extended representation.
7. The Equivalence Table
7.1. generation of the octet-
aligned choice as being conformant.
6. Defined Equivalences
6.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.
Alvestrand Exp Jan 96 [Page 26]
draft X.400/MIME body equivalences July 95
This behaviour behavior is not required for MIXER conformance, since
it is only needed when the base standards are violated.
7.2.
6.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 non-delivered
with an appropriate nondelivery non-delivery reason.
When mapping from X.400 to MIME, the character-set is
chosen from the table below according to the value of
Parameters.CharacterSets. If no match is found, and the
gateway does not support a conversion, the character set
may
shall 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"
Alvestrand Exp Jan 96 [Page 27]
draft X.400/MIME body equivalences July 95
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...)
Appendix <n> gives pseudocode for such a conversion.
NOTE: In 1988, the GeneralText body part was defined in
ISO 10021-8 [MOTIS], and NOT in the corresponding CCITT
recommendation; this was added later. Also, the
parameters have been heavily modified; they should be a
SET OF INTEGER in the currently valid text. Use the
latest version of the standard that you can get hold of.
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" 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 languag=
es languages
ISO-2022-JP 6, 14, 42, 87 Japanese
When converting from MIME to X.400, generate the correct
OIDs for use in the message envelope's Encoded Information
Types by looking up the ISO IR
Alvestrand, Thompson number in the above table,
Alvestrand Exp Jan 96 [Page 20] 28]
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
For ISO 8859-1, the complete string for at least
one example of this.
7.3. relevant escape sequence will be:
ESC 28 42
ASCII in G0
ESC 2D 41
ISO-IR-100 in G1
ESC 21 41
High control character set in C1
ESC 7E
Locking shift 1 Right
6.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 non-deliver
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
Alvestrand Exp Jan 96 [Page 21] 29]
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.
6.4. FTBP EMA Unknown Attachment -
application/octet-stream
X.400 Body Part: FTBP EMA Unknown Attachment
MIME Content-Type: Application/Octet-Stream
Conversion Type: Byte copy
NOTE: At the time of this writing (Sept 1995), support for
BilaterallyDefined is MUCH more widespead widespread 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
Alvestrand Exp Jan 96 [Page 22] 30]
draft X.400/MIME body equivalences July 95
when the "padding" parameter is present? This is not
recommended by EMA; do we want to have it?
Should the "type" parameter be mapped into the FTBP
FileTransferParameters.Environment.UserVisibleString?
It seems to be more or less the same kind of thing,
according to EMA.
The body mapping is just copying the bytes in both
directions.
7.5.
6.5. MessageBodyPart - message/rfc822 message/RFC822
X.400 body part: MessageBodyPart
MIME Content-Type: message/rfc822 message/RFC822
Conversion Type: Special
NOTE: If the headers of the X.400 MessageBodyPart contains the
"multipart-message" heading extension with the isAMessage bit set
(either explicitly or implicitly), the mapping should be to
multipart/*.
To map an IPMS.MessageBodyPart, the full X.400 -> RFC 822
mapping is recursively applied, to generate an RFC 822 Message.
If present, the IPMS.MessageBodyPart.parameters.delivery-envelope
is used for the MTS Abstract Service Mappings. If present, the
IPMS.MessageBodyPart.parameters.delivery-time is mapped to the
extended RFC 822 field "Delivery-Date:".
When a message/rfc822 message/RFC822 is contained within a MIME message, it is
mapped to an IPMS.MessageBodyPart according to MIXER.
specification. Any mappings that would have been made to the MTS
Abstract Service are placed in
IPMS.MessageBodyPart.parameters.delivery-envelope.
7.6.
6.6. MessageBodyPart - multipart/*
X.400 body part: MessageBodyPart
MIME Content-Type: multipart/*
Conversion Type: Special
NOTE: If the headers of the X.400 MessageBodyPart do not contain the
"multipart-message" heading extension with the "isAMessage" flag FALSE=
,
the mapping should be to message/rfc822.
Alvestrand, Thompson message/RFC822.
Alvestrand Exp Jan 96 [Page 23] 31]
draft X.400/MIME body equivalences July 95
A MIME multipart is a set of content-types and not a message with
a set of content types. When the multipart is at the outermost
MIME header and is either multipart/digest or multipart/mixed,
elements of the multipart are mapped directly onto IPMS.BodyPart. IPMS.Bodypart.
In other cases, a MIME multipart is mapped to an
IPMS.MessageBodyPart containing an IPMS.BodyPart IPMS.Bodypart for each element
of the multipart.
When a nested IPMS.Message is generated from a multipart, an
IPMS.heading shall always be generated. The only mandatory field
is the IPMS.Heading.this-IPM message id, which shall be generated
by the gateway. An IPMS.Heading.subject field shall also be
generated, in order to provide useful information to non-MIME
capable X.400(88) UAs and to all X.400(84) UAs. The subject
field is set as follows according to the multipart subtype:
mixed:
"Multipart Message"
alternative:
"Alternative Body Parts containing multipart subtype:
mixed:
"Multipart Message"
alternative:
"Alternative Body Parts containing the same
information"
digest:
"Message Digest"
parallel:
"Body Parts interpreted in parallel"
other:
"Multipart Message (<subtype>)"
For other types of multipart, the multipart subtype shall
be included in the subject line.
For each multipart, the following IPMS.HeadingExtension
shall be generated, with the value set according to the
subtype:
multipart-message HEADING-EXTENSION
VALUE MultipartType
::=3D id-hex-multipart-message
MultipartType ::=3D SEQUENCE {
Alvestrand Exp Jan 96 [Page 32]
draft X.400/MIME body equivalences July 95
subtype IA5String,
isAMessage BOOLEAN DEFAULT TRUE }
The MultipartType contains the subtype, for example
"digest". If this heading is present when mapping from
X.400 to MIME, the appropriate multipart may be generated.
The isAMessage flag is needed because of the case where a
message contains a ForwardedIPMessage, which itself was
generated from a MIME message that was a Multipart; it is
set whenever the multipart is the outermost level of
nesting inside a Message/RFC822.
6.7. 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 same
information"
digest:
"Message Digest"
parallel:
"Body Parts interpreted pages in parallel"
other:
"Multipart Message (<subtype>)"
For other types the "data" part of multipart, the multipart subtype shall
be included
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 subject line.
For each multipart, body of the following IPMS.HeadingExtension
Text/Plain.
The character set shall be generated, with the value set according to the
subtype:
multipart-message HEADING-EXTENSION
VALUE MultipartType
::=3D id-hex-multipart-message
MultipartType ::=3D SEQUENCE {
Alvestrand, Thompson "Teletex", which is especially
registered for this purpose. Its definition is shown in an
appendix.
The parameters are discarded.
Alvestrand Exp Jan 96 [Page 24] 33]
draft X.400/MIME body equivalences July 95
subtype IA5String,
isAMessage BOOLEAN DEFAULT TRUE }
The MultipartType contains the subtype, for example
"digest". If this heading is present when mapping from
X.400
From RFC-822 to MIME, X.400, the appropriate multipart may be generated. conversion shall split the
content at each occurrence 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 isAMessage flag TeletexParameters may, but need not, contain the
number-of-pages component.
NOTE: It is needed because of recommended, but not mandated, that the case where data
be converted into a
message contains more widespread character set like
ISO-8859-1 or ISO-2022-JP (if applicable) if possible.
This will result in the reverse translation giving a ForwardedIPMessage,
GeneralText body part, which itself was
generated from will have to be dealt with
appropriately at the X.400/88 to X.400/84 downgrading
boundary, if possible, but will give a MIME message much greater chance
that was a Multipart; it is
set whenever the multipart is MIME recipient can actually read the outermost level of
nesting inside a Message/RFC822.
7.7. ia5 <- message.
Alvestrand Exp Jan 96 [Page 34]
draft X.400/MIME body equivalences July 95
7. Body parts where tunneling is recommended
Some body parts are MIME constructs, and their
functionality will be severely damaged if they are coerced
into an X.400 framework.
Special care needs to be taken with these; they are
described below.
7.1. message/external-body
X.400 body part: ia5 MIME Content-Type: message/external-
body Conversion Type: Special
The 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 Mailserver access-type, are
almost impossible to resolve at a gateway.
To support the second case above, the tunneling method
Alvestrand, Thompson Exp Jan 96 [Page 25]
draft X.400/MIME body equivalences July 95
chosen is to represent the body part as HARPOON encapsulation described in section
3.1.3, using an IA5 body part, inserting the string "MIME-Version: "MIME-
Version: 1.0 (generated by gateway)" at the beginning of
the body part. (The part in parentheses can be changed at will)
Alvestrand Exp Jan 96 [Page 35]
draft X.400/MIME body equivalences July 95
will).
This will:
(1) Maximize the chance that the user will see the
message
(2) Give the user hints that will enable him to fetch
the message using other Internet tools
(3) Identify the message (in a fashion compatible with
RFC 1496, HARPOON) as a MIME object in a reliable
fashion, allowing UAs to support a MIME object in a reliable
fashion, allowing UAs to support the fetching of
the object if the UA implementor desires.
The gateway MAY support a configuration option to
retrieve; it MUST support the HARPOON tunneling when
retrieval is not desired or not possible.
7.2. message/partial
This represents part of a larger message, where it is only
possible to parse the complete message after getting all
the pieces.
The gateway's choices are:
(1) Wait until all the pieces arrive at the gateway,
reassemble the message, and use normal processing
(2) Encapsulate the message, using any encapsulation
method
The choice of what to do, and which encapsulation
to use, is left up to the gateway, but it MUST be
possible to configure it to do encapsulation,
possibly after a configurable wait.
Alvestrand Exp Jan 96 [Page 36]
draft X.400/MIME body equivalences July 95
7.3. multipart/signed
Gatewaying security is a problem. The gateway can
basically take three approaches:
- Strip the multipart/signed, leaving the bare body
part unsecured, possibly with a comment that the
signature was stripped
- Attempt to check the signature and re-signing the
message using X.400 security functions, then
stripping as above
- Encapsulate the fetching of message. This is the object if only approach
that allows end to end security, but requires MIME
functionality at the UA implementor desires. recipient.
All these are valid options for a MIXER gateway. The
gateway MAY support a configuration option to
retrieve; it MUST support implement the tunneling in IA5 when
retrieval is not desired or not possible.
This points to third alternative. The
encapsulation shall be done using HARPOON style
encapsulation: Prefixing the data with "MIME-version: 1.0"
and putting the whole multipart/signed, headers and all,
into an external IA5 body part. As
7.4. multipart/encrypted
There are two basic cases for a gateway:
- The gateway is trusted with the user's keys. In this will not in
general be accessible to
case, the X.400 recipient, gateway can decrypt the body
part shall be resolved at message, possibly
add a note that it has done so, and gateway the gateway,
unencrypted form. This does nothing to protect the
transfer from gateway to recipient, unless it suitable
X.400-native security is
already included in a multipart/alternative or applied.
- The gateway is not trusted with the
recipient UA recipient's keys.
In this case, tunneling is known to be capable of handling a
message/external tunnelled the only approach that
preserves any information at all.
Alvestrand Exp Jan 96 [Page 37]
draft X.400/MIME body part. equivalences July 95
The valid options for a MIXER gateway shall
obtain are therefore:
- Decrypt the body part and then map it as if it had been
included. If the expiration date of
- Tunnel the external body part has expired,
- Drop the body part
A MIXER compliant gateway may MUST implement the second
option, using an IA5 tunnel in the body part.
Editor's Note:
There has been comment that this dereference should HARPOON style.
8. Conformance requirements
In order to be made more optional or called MIXER conformant, a gateway must
implement:
- Encapsulation of MIME content in the FTBP tunneling
body part
- Encapsulation of X.400 body parts in the text changed x400-bp body
part
- Encapsulation of FTBP body parts in some
way. Input is solicited.
Alvestrand, Thompson the
application/x-oid.n.n.n body part
- Text/plain <-> IA5Text
- Text/plain; charset=3Diso-8859-* <-> GeneralText
- Multipart/* <-> ForwardedIPMessage
- message/RFC822 <-> ForwardedIPMessage
- application/octet-stream <-> FTBP unknown
- application/octet-stream <-> BilaterallyDefined
- A configuration choice of which application/octet-
stream translation to use
Alvestrand Exp Jan 96 [Page 26] 38]
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
All other parts of this specification MAY be implemented
by the
body part. Input solicited!
The following heading extension is added, derived from the
message/partial parameters, in order to facilitate MIME
capable X.400 UAs gateway. If they are implemented at all, they MUST
be implemented conformant to 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 fileTransferData component of an FTBP specification.
In this context, a feature is "implemented" in a
SEQUENCE of EXTERNAL, the file data component of the
multipart product
if it is mapped onto the first of two elements of the
SEQUENCE, and possible to configure the application/applefile component (the
finder and resource info) product in such a way
that this feature is mapped onto the second
element of the sequence. Applications which don't care
about used. This specification does not
restrict the finder and resource info can, therefore, simply
ignore product to only be configured in such a
fashion.
References
[RFC-822]
D.H. Crocker, Standard for the second element Format of ARPA
Internet Text Messages. Request for Comments 822,
(August, 1982).
[MIME]
N. Borenstein, N. Freed, MIME: Mechanisms for
Specifying and extract the data from Describing the
first element. The direct reference component Format of the
first element is set to reflect the original type/subtype 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 the MIME data component, according the OID's defined Group 3
Facsimile Apparatus for Document Transmission (1988)
[T.30]
CCITT Recommendation T.30, Procedures For Document
Facsimile Transmission in
RFC1494bis.
Editor's Note:
This specification is clearly useful the General Switched
Telephone Network (1988)
[T.411]
CCITT Recommendation T.411 (1988), Open Document
Architecture (ODA) and needed.
Does it
belong in MIXER? Comments solicited.
Alvestrand, Thompson Interchange Format,
Introduction and General Principles
[MOTIS]
ISO/IEC International Standard 10021, Information
technology - Text Communication - Message-Oriented
Alvestrand Exp Jan 96 [Page 27] 39]
draft X.400/MIME body equivalences July 95
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 Interchange Systems (MOTIS) (Parts 1 to map this onto
Text/Plain; however, since this is not plain text, the
conversion must be specified.
From 8)
[X.400]
CCITT, Data Communication Networks - Message Handling
Systems - Recommendations X.400 to RFC-822, the conversion shall take the bytes - X.420 (1988
version)
[X.420]
CCITT Recommendation X.420 (1988), Interpersonal
Messaging System
[RFC-X400USE]
Harald Tveit Alvestrand, X.400 use of all the pages extended
Character Sets, Internet Draft, June 1992
[MAWG]
Electronic Messaging Association Message Attachment
Working Group (MAWG): File Transfer Body Part
Feasibility Project Guide - version 1.5 - September
1995
9. Authors' address
Harald Tveit Alvestrand
UNINETT
P.O.box 6883 Elgeseter
N-7002 Trondheim
NORWAY
Harald.T.Alvestrand@uninett.no
APPENDIXES
Appendix A: Escape code normalization
The algorithm given here in the "data" part of the
TeletexBodyPart, add pseudocode will reduce a FF character (0x0C, control-L)
GeneralString ISO-2022 unlimited use of shifts sequence to
each part
a pure 8-bit sequence that does not already end in one, and
concatenate them together use shift sequences,
if possible.
Some error conditions, like EOF, are not tested for. It
crashes if asked to form the do something it cannot. Control
Alvestrand Exp Jan 96 [Page 40]
draft X.400/MIME body of the
Text/Plain.
The equivalences July 95
character set shall be "Teletex", which switching is especially
registered missing.
A similar routine, albeit more complex, can be written for this purpose. Its definition is shown in an
appendix.
The parameters are discarded.
From RFC-822
normalizing to X.400, the conversion shall split the
content at each occurence of the FF character (0x0C),
delete the ISO-2022-JP 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, set.
BEGIN: (from X.209)
g0 =3D 6 (should be 2, but need not, contain ignore the
number-of-pages component.
NOTE: It is recommended, but not mandated, that difference)
g1 =3D NULL
g2 =3D NULL
g3 =3D NULL
c0 =3D 1 (ASCII control)
c1 =3D NULL
leftset =3D &g0 (current input set, low)
rightset =3D &g1 (current input set, high)
lowset =3D 6 (output set, low)
highset =3D NULL (output set, high)
charset =3D US-ASCII
(Init for the data
be converted into a more widespread character set like
ISO-8859-1 or ISO-2022-JP (if applicable) if possible.
This will result in tables)
chartoid[{2D,2E,2F}, 41] =3D 100
.....
idtoname[100] =3D "ISO-8859-1"
.....
WHILE (more data)
CASE head of input
{These are the reverse translation giving a
GeneralText body part, which will have to be dealt with
appropriately at locking shift sequences}
INCASE "00/14": (LS0, SO)
leftset =3D &g0;
INCASE "00/15": (LS1, SI)
leftset =3D &g
INCASE "ESC 07/14": (LS1R)
rightset =3D &g1;
INCASE "ESC 07/13": (LS2R)
rightset =3D &g2;
INCASE "ESC 07/12": (LS3R)
rightset =3D &g3;
{There is missing code for handling the X.400/88 to X.400/84 downgrading
Alvestrand, Thompson single shift function}
{These are the changes of graphic character sets}
{Note that G0 can contain only 94-character charsets}
INCASE "ESC 28"
g0 =3D chartoid[lastchar, next character]
sethiset(g0)
INCASE "ESC 2D", "ESC 29"
g1 =3D chartoid[lastchar, next character]
Alvestrand Exp Jan 96 [Page 28] 41]
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.
Alvestrand, Thompson
sethiset(g1)
INCASE "ESC 2E", "ESC 2A"
g2 =3D chartoid[lastchar, next character]
sethiset(g2)
INCASE "ESC 2F", "ESC 2B"
g3 =3D chartoid[lastchar, next character]
sethiset(g3)
{control characters. There is missing code for changing these}
INCASE 00/00-01/15 {normal control}
write(char)
INCASE 08/00-09/15 {upper control}
write(char)
{Normal characters}
INCASE 02/00-07/15 (Left)
IF (*leftset =3D=3D lowset)
write(char)
ELSIF (*leftset =3D=3D highset)
write(char+80)
ELSE
ERROR "Shift error"
ENDIF
INCASE 10/00-15/15
IF (*rightset =3D=3D highset)
write(char)
ELSIF (*rightset =3D=3D lowset)
write(char-80)
ELSE
ERROR "Shift error"
ENDIF
ENDCASE
ENDWHILE
SUBROUTINE sethighset(g1)
IF (highset =3D=3D NULL)
charset =3D idtoname[g1]
highset =3D g1
ELSIF (highset =3D=3D g1)
(it's OK)
ELSE
ERROR "Too many charsets encountered"
ENDIF
ENDROUTINE
Alvestrand Exp Jan 96 [Page 29] 42]
draft X.400/MIME body equivalences July 95
8.
Appendix B: 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
id-mime-bp-data OBJECT IDENTIFIER ::=3D
{ mixer-bp-data 1};
mime-generic-parameters
id-mime-bp-parameters OBJECT IDENTIFIER ::=3D
{ mixer-bp-parameter 1};
Alvestrand, Thompson
-- the following assignments were done in RFC 1494, using
-- slightly different names, but the same numbers.
-- their defining text is now is now in other documents
id-mime-postscript-body OBJECT IDENTIFIER ::=3D
{ mixer-bp-data 2}
id-mime-jpeg-body OBJECT IDENTIFIER ::=3D
{ mixer-bp-data 3}
id-mime-gif-body OBJECT IDENTIFIER ::=3D
{ mixer-bp-data 4};
-- This is a new definition, and defines an FTAM application reference=
,
-- not a BP15 data OID.
id-mime-ftbp-data OBJECT IDENTIFIER ::=3D
{ mixer-bp-data 5 }
Alvestrand Exp Jan 96 [Page 30] 43]
draft X.400/MIME body equivalences July 95
9.
Appendix C: 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 non-spacing 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 data type 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
Non-Latin coded character sets for telematic services
T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95]
Alvestrand, Thompson
Alvestrand Exp Jan 96 [Page 31] 44]
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.
Appendix D: 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 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 macro, or reference to
a Basic body part type)
Conversion algorithm:
(must be defined completely enough for Comments 1341, (June,
1992).
[MIXER]
S.E. Hardcastle-Kille, Mapping between X.400(1988) /
ISO 10021 and RFC-822. (in preparation)
Alvestrand, Thompson independent
Alvestrand Exp Jan 96 [Page 33] 45]
draft X.400/MIME body equivalences July 95
[T.4]
CCITT Recommendation T.4, Standardization of Group 3
Facsimile Apparatus
implementation. It may be defined by reference to RFCs).
Person & email address to contact for Document Transmission (1988)
[T.30]
CCITT Recommendation T.30, Procedures For Document
Facsimile Transmission further information:
INFORMATION TO THE SUBMITTER:
The accepted registrations will be listed 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 "Assigned
Numbers" series of extended
Character Sets, Internet Draft, June 1992
Alvestrand, Thompson RFCs. The information in the
registration form is freely distributable.
Alvestrand Exp Jan 96 [Page 34] 46]
draft X.400/MIME body equivalences July 95
Table of Contents
Status of this Memo ................................ 1
1 Introduction ...................................... 2
1.1 Philosophy of body part conversion .............. 3
1.2 Describing an equivalence ....................... 4
2 Generic conversions ............................... 5
2.1 Byte copy ....................................... 5
2.2 Text Conversion ................................. 5
2.3 Image Conversion ................................ 5
3 Equivalence Table for known X.400 and MIME Types
................................................ 7
3.1 Equivalence Table format ........................ 7
3.2 MIME to X.400 Table ............................. 7
3.3 X.400 to MIME Table ............................. 8
4 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ........ 9
5 Ground Memo ................................ 1
1 Introduction ...................................... 2
1.1 Glossary ........................................ 3
2 Basic rules for generating body part conversion .............. 3
2.1 Generating the IPM Body from MIME ........................................... 11
6 ............... 5
2.2 Ground rules for generating the MIME Body from
the IPMS.Body .................................. 11
6.1 Information that is lost when mapping ........... 12
6.2 5
2.3 Mapping the EMA FTBP parameters ................. 12
6.2.1 Parameter 6
2.3.1 Summary of FTBP elements generated ............ 10
2.4 Information that is lost when mapping ........... 10
3 Encapsulation of body parts ....................... 11
3.1 Encapsulation of MIME to in X.400 ............... .................. 11
3.1.1 BP15 tunneling body part ...................... 11
3.1.2 FTBP tunneling body part ...................... 13
6.2.2 Parameter mapping X.400 to MIME ...............
3.1.3 Tunneling using IA5 ........................... 13
6.3 Encapsulation in X.400
3.1.4 Tunneling using BP14 .......................... 15
6.4 Tunnelling 14
3.2 Tunneling X.400 Body Parts ..................... in MIME .............. 15
3.3 Tunneling FTBP body parts in MIME ............... 15
4 User control over the gateway choice .............. 16
4.1 Conversion from MIME to X.400 ................... 17
7
4.2 Conversion from X.400 to MIME ................... 18
5 The equivalence registry .......................... 20
5.1 Equivalence Table for known X.400 and MIME
Types .......................................... 21
5.2 MIME to X.400 Table ............................. 17
7.1 22
5.3 X.400 to MIME Table ............................. 22
5.4 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ...... 24
6 Defined Equivalences .............................. 26
6.1 IA5Text - text/plain ............................ 17
7.2 26
6.2 GeneralText - text/plain (ISO-8859) ............. 18
7.3 27
6.3 BilaterallyDefined - application/octet-stream
................................................ 21
7.4 29
6.4 FTBP EMA Unknown Attachment - applica=AD
tion/octet-stream .............................. 22
7.5 30
6.5 MessageBodyPart - message/rfc822 message/RFC822 ................ 23
7.6 31
6.6 MessageBodyPart - multipart/* ................... 23
7.7 ia5 <- message/external-body .................... 25
7.8 ??? - message/partial ........................... 27
7.9 ???? - multipart/appledouble .................... 27
7.10 31
6.7 Teletex - Text/Plain (Teletex) ................. 28 .................. 33
7 Body parts where tunneling is recommended ......... 35
7.1 message/external-body ........................... 35
7.2 message/partial ................................. 36
7.3 multipart/signed ................................ 37
7.4 multipart/encrypted ............................. 37
Alvestrand Exp Jan 96 [Page 47]
draft X.400/MIME body equivalences July 95
8 Conformance requirements .......................... 38
References ......................................... 39
9 Authors' address .................................. 40
APPENDIXES ......................................... 40
Appendix A: Escape code normalization .............. 40
Appendix B: OID Assignments ................................... 30
9 ........................ 43
Appendix C: Registration information for the
Teletex charac=AD
ter character set ........................................ 31
10 .......................... 44
Appendix D: IANA Registration form for new mappings .......... 32
11 Changes from RFC 1494 ............................ 33
Alvestrand, Thompson Exp Jan 96 [Page 35]
draft X.400/MIME body equivalences July 95
12 References ....................................... 33
Alvestrand, Thompson map=AD
pings .......................................... 45
Alvestrand Exp Jan 96 [Page 36] 48]
----