The external-body subtype indicates that the actual body data are not included, but merely referenced. In this case, the parameters describe a mechanism for accessing the external data.
When an entity is of type "message/external-body", it consists of a header, two consecutive CRLFs, and the message header for the encapsulated message. If another pair of consecutive CRLFs appears, this of course ends the message header for the encapsulated message. However, since the encapsulated message's body is itself external, it does NOT appear in the area that follows. For example, consider the following message:
Content-type: message/external-body; access- type=local-file; name="/u/nsb/Me.gif" Content-type: image/gif Content-ID: <email@example.com> Content-Transfer-Encoding: binary THIS IS NOT REALLY THE BODY!
The area at the end, which might be called the "phantom body", is ignored for most external-body messages. However, it may be used to contain auxiliary information for some such messages, as indeed it is when the access-type is "mail-server". Of the access-types defined by this document, the phantom body is used only when the access-type is "mail-server". In all other cases, the phantom body is ignored.
The only always-mandatory parameter for message/external-body is "access-type"; all of the other parameters may be mandatory or optional depending on the value of access-type.
ACCESS-TYPE -- A case-insensitive word, indicating the supported access mechanism by which the file or data may be obtained. Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP", "AFS", "LOCAL-FILE", and "MAIL-SERVER". Future values, except for experimental values beginning with "X-" must be registered with IANA, as described in Appendix E .
In addition, the following three parameters are optional for ALL access-types:
EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as extended by RFC 1123 to permit 4 digits in the year field) after which the existence of the external data is not guaranteed. SIZE -- The size (in octets) of the data. The intent of this parameter is to help the recipient decide whether or not to expend the necessary resources to retrieve the external data. Note that this describes the size of the data in its canonical form, that is, before any Content- Transfer-Encoding has been applied or after the data have been decoded. PERMISSION -- A case-insensitive field that indicates whether or not it is expected that clients might also attempt to overwrite the data. By default, or if permission is "read", the assumption is that they are not, and that if the data is retrieved once, it is never needed again. If PERMISSION is "read-write", this assumption is invalid, and any local copy must be considered no more than a cache. "Read" and "Read-write" are the only defined values of permission.
The precise semantics of the access-types defined here are described in the sections that follow.
The encapsulated headers in ALL message/external-body entities MUST include a Content-ID header field to give a unique identifier by which to reference the data. This identifier may be used for cacheing mechanisms, and for recognizing the receipt of the data when the access-type is "mail-server".
Note that, as specified here, the tokens that describe external-body data, such as file names and mail server commands, are required to be in the US-ASCII character set. If this proves problematic in practice, a new mechanism may be required as a future extension to MIME, either as newly defined access-types for message/external-body or by some other mechanism.
As with message/partial, it is specified that MIME entities of type message/external-body must always have a content-transfer-encoding of 7-bit (the default). In particular, even in environments that support binary or 8-bit transport, the use of a content-transfer- encoding of "8bit" or "binary" is explicitly prohibited for entities of type message/external-body.