7.3.3. The Message/External-Body subtype (original) (raw)

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

Up: 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.

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

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