Connected: An Internet Encyclopedia
RFC 1521 - 7.3.3. The Message/External-Body subtype

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1521
Up: 7. The Predefined Content-Type Values
Up: 7.3. The Message Content-Type
Prev: 7.3.2. The Message/Partial subtype
Next: 7.3.3.1. The "ftp" and "tftp" access-types

### 7.3.3. The Message/External-Body subtype

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: <id42@guppylake.bellcore.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.

7.3.3.1. The "ftp" and "tftp" access-types
7.3.3.2. The "anon-ftp" access-type
7.3.3.3. The "local-file" and "afs" access-types
7.3.3.4. The "mail-server" access-type
7.3.3.5. Examples and Further Explanations

Next: 7.3.3.1. The "ftp" and "tftp" access-types

Connected: An Internet Encyclopedia
RFC 1521 - 7.3.3. The Message/External-Body subtype