7.3.3.5. Examples and Further Explanations

7.3.3.5. Examples and Further Explanations

With the emerging possibility of very wide-area file systems, it
becomes very hard to know in advance the set of machines where a file
will and will not be accessible directly from the file system.
Therefore it may make sense to provide both a file name, to be tried
directly, and the name of one or more sites from which the file is
known to be accessible. An implementation can try to retrieve remote
files using FTP or any other protocol, using anonymous file retrieval
or prompting the user for the necessary name and password. If an
external body is accessible via multiple mechanisms, the sender may
include multiple parts of type message/external-body within an entity
of type multipart/alternative.

However, the external-body mechanism is not intended to be limited to
file retrieval, as shown by the mail-server access-type. Beyond
this, one can imagine, for example, using a video server for external
references to video clips.

If an entity is of type "message/external-body", then the body of the
entity will contain the header fields of the encapsulated message.
The body itself is to be found in the external location. This means
that if the body of the "message/external-body" message contains two
consecutive CRLFs, everything after those pairs is NOT part of the
message itself. For most message/external-body messages, this
trailing area must simply be ignored. However, it is a convenient
place for additional data that cannot be included in the content-type
header field. In particular, if the "access-type" value is "mail-
server", then the trailing area must contain commands to be sent to
the mail server at the address given by the value of the SERVER
parameter.

The embedded message header fields which appear in the body of the
message/external-body data must be used to declare the Content-type
of the external body if it is anything other than plain ASCII text,
since the external body does not have a header section to declare its
type. Similarly, any Content-transfer-encoding other than "7bit"
must also be declared here. Thus a complete message/external-body
message, referring to a document in PostScript format, might look
like this:

Note that in the above examples, the default Content-transfer-
encoding of "7bit" is assumed for the external postscript data.

Like the message/partial type, the message/external-body type is
intended to be transparent, that is, to convey the data type in the
external body rather than to convey a message with a body of that
type. Thus the headers on the outer and inner parts must be merged
using the same rules as for message/partial. In particular, this
means that the Content-type header is overridden, but the From and
Subject headers are preserved.

Note that since the external bodies are not transported as mail, they
need not conform to the 7-bit and line length requirements, but might
in fact be binary files. Thus a Content-Transfer-Encoding is not
generally necessary, though it is permitted.

Note that the body of a message of type "message/external-body" is
governed by the basic syntax for an RFC 822 message. In particular,
anything before the first consecutive pair of CRLFs is header
information, while anything after it is body information, which is
ignored for most access-types.

The formal grammar for content-type header fields for data of type
message is given by: