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
Content-type: message/external-body; access-
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
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.