The message/external-body Type
If you want to send an email message but are afraid that the content won’t be desired by some recipients, you might try using the message/external-body media type.
At the time this book was written, the most common solution to this problem is to email a uniform resource locator (URL) to a remote recipient. The URL is commonly represented in plain 7-bit US-ASCII text and embedded somewhere in a message body or body part. Some modern MUAs even note the presence of a URL within body text and allow its intended action as a hyperlink via a Web browser. This works well if the recipient is a human being, capable of easily parsing the text to find the hyperlink. The message/external-body form, however, may be more appropriate if the recipient is a computing process.
RFC 2046 describes this media type in detail and any implementors should look there to get a complete description. However, here is a brief overview:
Since the major media type is message (a composite type), any message/external-body message is nested by definition.
The message parts exist somewhere out on the network, not in the message body, so a Content-ID header must be used to reference each object.
The Content-Type header must include a parameter for access-type, which can be any of the following: FTP, ANON-FTP, TFTP, LOCAL-FILE, or MAIL-SERVER.
Optional parameters to the Content-Type header are expiration (the expiration date of the information, after which it should not be downloaded), size (the size of the information in octets), and permission (either “read” or “read-write”).
Each access-type may have its own required and optional parameters.
Since the body of the message part referenced is not present, any text that appears after the part’s MIME part headers is not really the body. This information may be used by some implementations, however, in a very local way.
For example, consider the following ANON-FTP access-type. This is a structured and easily parsable manner in which to reference an external document available anonymously by the file transfer protocol.
Content-type: message/external-body;
access-type=anon-ftp;
site="ftp.uu.net";
directory="pub/images";
name="truck.gif";
mode="image"
Content-type: image/gif
Content-ID: <[email protected]>
Content-Transfer-Encoding: binary
This is bogus data - there is no body here! Local
implementations (i.e., custom code) can parse it if they wish, in
order to pass extra information. However, for use by automated
receivers, extra information should probably go into a custom
header (e.g., X-Content-Extra: "Some more info").In this example, an image called truck.gif is available to be downloaded from ftp.uu.net. All of the information needed to retrieve the file is in the message, properly delimited for easy parsing, including the directory name and the mode type to use when using FTP to retrieve the file. Of course, the user could opt not to bother retrieving the file, and network resources will have been saved.
If the FTP access-type had been used, instead of the anonymous version, the MUA receiving this message would have been responsible for asking the user for a username and password. Usernames and passwords are not sent in the messages for obvious security reasons.
The FTP, ANON-FTP, and TFTP access-types require that parameters for name (the filename to retrieve, with or without directory information in the string) and site (the FTP server to download from) be named. Use of the directory and mode parameters is optional. The default for mode is “ASCII”.
The LOCAL-FILE access-type is used if the data is available on a local filesystem. This could be used for information on a multi-user host or on a LAN with networked filesystem availability. The name parameter is mandatory, and the optional site parameter names the domains from where the data should be visible.
The MAIL-SERVER access-type can be used to retrieve messages from a mail server at a later time. This is one case where the “phantom” body of a message/external-body message part is put to use. The body holds direct mail server commands needed to retrieve the message. The server parameter names the mail server to use, and the optional subject parameter names the contents of the Subject header of the message to be retrieved.