When the external-body mechanism is used in conjunction with the
   "multipart/alternative" media type it extends the functionality of
   "multipart/alternative" to include the case where the same entity is
   provided in the same format but via different accces mechanisms.
   When this is done the originator of the message must order the parts
   first in terms of preferred formats and then by preferred access
   mechanisms.  The recipient's viewer should then evaluate the list
   both in terms of format and access mechanisms.

   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 entities of type "message/external-body" within the
   body parts of an enclosing "multipart/alternative" entity.

   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.





 
RFC 2046                      Media Types                  November 1996


   The embedded message header fields which appear in the body of the
   "message/external-body" data must be used to declare the media type
   of the external body if it is anything other than plain US-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 an object in PostScript
   format, might look like this:

     From: Whomever
     To: Someone
     Date: Whenever
     Subject: whatever
     MIME-Version: 1.0
     Message-ID: <id1@host.com>
     Content-Type: multipart/alternative; boundary=42
     Content-ID: <id001@guppylake.bellcore.com>

     --42
     Content-Type: message/external-body; name="BodyFormats.ps";
                   site="thumper.bellcore.com"; mode="image";
                   access-type=ANON-FTP; directory="pub";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

     Content-type: application/postscript
     Content-ID: <id42@guppylake.bellcore.com>

     --42
     Content-Type: message/external-body; access-type=local-file;
                   name="/u/nsb/writing/rfcs/RFC-MIME.ps";
                   site="thumper.bellcore.com";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

     Content-type: application/postscript
     Content-ID: <id42@guppylake.bellcore.com>

     --42
     Content-Type: message/external-body;
                   access-type=mail-server
                   server="listserv@bogus.bitnet";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

     Content-type: application/postscript
     Content-ID: <id42@guppylake.bellcore.com>

     get RFC-MIME.DOC

     --42--




 
RFC 2046                      Media Types                  November 1996


   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" media
   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 and Subject fields are overridden,
   but the From field is preserved.