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