X.400 has attachments, Internet Mail has attachments
X.400 attachments
X.400 (1984) defined several types of message contents (body parts),
including G3Fax images, simple ASCII text and a couple of others. More
than one of these could be present in each message.
X.400 (1988) extended that to an extensible mechanism - "body part
15", which allowed more or less anything that could be represented
using ASN.1 and identified by an object identifier.
The X.400 (1984) implementations had, in the interim, settled on using
the "Bilaterally defined" body part (body part 14) as a means of
sending around "attachments" as unlabelled, unstructured sequences of
bytes.
The latest wrinkle in the X.400 attachments game is the definition of
the "File Transfer Body Part", which gives you (roughly) the ability
to carry around any unstructured sequence of bytes, with object
identifiers on them to identify the file format, and a lot of standard
header fields (like "filename") that might be useful independent of
the filetype; the driving force of this is the Electronic Mail
Association "file attachment group".
Internet Mail attachments
Internet Mail (RFC 822, 1982) defined only that messages could contain
ASCII text. The MIME extensions (first defined in RFC 1341, 1992)
defined how to format the ASCII text body in such a way that it was
possible to use it to carry multiple well-defined objects, where each
object could be represented as a sequence of bytes, and its format
identified by a short ASCII string registered with the Internet naming
authority, IANA.
Each attachment can have text-formatted headers, some of which are
standardized to indicate things like content language (RFC 1766), content
description, filename (RFC 1806), or whether it should be displayed as
an attachment or together with the "main body".
The basic functionality of these mechanisms is roughly equivalent; one
trifle that is different is that MIME defines objects that can contain
other objects (multiparts) with various possible semantics like
"should be presented at the same time" or "are alternative versions of
the same real content", while the only construct that allows this
in X.400 is the forwarded message.
(Translation between the two types of attachments is defined in RFC
1494; this work has been hampered by a lack of registration and data
input from both communities. It is being revised; input is welcome!)
Implementation of attachments
Most or all X.400 user agents, and quite a few of the gateways to
other mail systems, handle the "bilaterally defined" attachment,
offering to save it to a file or attempt to figure out what is inside
it and start the appropriate program.
The Body Part 15 attachments have (as far as I know) been little used;
I do not know if any released product uses the FTBP attachment format.
All MIME mailers implement the possibility of saving attachments to a
file; many also use the type field to trigger appropriate display
programs; mailing GIF files is not uncommon. Most also offer
configuration files where you can specify a display program for use
with types that were not defined by the mailer vendor.
Standalone public-domain programs (metamail, for instance) exist for
non-MIME mailers to allow them to extract MIME data from messages;
this is made easier by the fact that there is only one canonical
representation for all MIME-defined objects: The octet string.
This corresponds well with the objects common on Unix or DOS file
systems; stuff from the Mac with its "two-forked" files has a bit more
trouble fitting in - see RFC 1740 for standards on how to do it.
Last modified: Fri Jul 21 06:53:31 1995