7.2. The Multipart Content-Type (original) (raw)

Connected: An Internet Encyclopedia
7.2. The Multipart Content-Type

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1521
Up: 7. The Predefined Content-Type Values

Prev: 7.1.2. The Text/plain subtype
Next: 7.2.1. Multipart: The common syntax

7.2. The Multipart Content-Type

7.2. The Multipart Content-Type

In the case of multiple part entities, in which one or more different sets of data are combined in a single body, a "multipart" Content- Type field must appear in the entity's header. The body must then contain one or more "body parts," each preceded by an encapsulation boundary, and the last one followed by a closing boundary. Each part starts with an encapsulation boundary, and then contains a body part consisting of header area, a blank line, and a body area. Thus a body part is similar to an RFC 822 message in syntax, but different in meaning.

A body part is NOT to be interpreted as actually being an RFC 822 message. To begin with, NO header fields are actually required in body parts. A body part that starts with a blank line, therefore, is allowed and is a body part for which all default values are to be assumed. In such a case, the absence of a Content-Type header field implies that the corresponding body is plain US-ASCII text. The only header fields that have defined meaning for body parts are those the names of which begin with "Content-". All other header fields are generally to be ignored in body parts. Although they should generally be retained in mail processing, they may be discarded by gateways if necessary. Such other fields are permitted to appear in body parts but must not be depended on. "X-" fields may be created for experimental or private purposes, with the recognition that the information they contain may be lost at some gateways.

  NOTE: The distinction between an RFC 822 message and a body part
  is subtle, but important. A gateway between Internet and X.400
  mail, for example, must be able to tell the difference between a
  body part that contains an image and a body part that contains an
  encapsulated message, the body of which is an image.  In order to
  represent the latter, the body part must have "Content-Type:
  message", and its body (after the blank line) must be the
  encapsulated message, with its own "Content-Type: image" header
  field.  The use of similar syntax facilitates the conversion of
  messages to body parts, and vice versa, but the distinction
  between the two must be understood by implementors.  (For the
  special case in which all parts actually are messages, a "digest"
  subtype is also defined.)

As stated previously, each body part is preceded by an encapsulation boundary. The encapsulation boundary MUST NOT appear inside any of the encapsulated parts. Thus, it is crucial that the composing agent be able to choose and specify the unique boundary that will separate the parts.

All present and future subtypes of the "multipart" type must use an identical syntax. Subtypes may differ in their semantics, and may impose additional restrictions on syntax, but must conform to the required syntax for the multipart type. This requirement ensures that all conformant user agents will at least be able to recognize and separate the parts of any multipart entity, even of an unrecognized subtype.

As stated in the definition of the Content-Transfer-Encoding field, no encoding other than "7bit", "8bit", or "binary" is permitted for entities of type "multipart". The multipart delimiters and header fields are always represented as 7-bit ASCII in any case (though the header fields may encode non-ASCII header text as per [RFC-1522]), and data within the body parts can be encoded on a part-by-part basis, with Content-Transfer-Encoding fields for each appropriate body part.

Mail gateways, relays, and other mail handling agents are commonly known to alter the top-level header of an RFC 822 message. In particular, they frequently add, remove, or reorder header fields. Such alterations are explicitly forbidden for the body part headers embedded in the bodies of messages of type "multipart."

• 7.2.1. Multipart: The common syntax
• 7.2.2. The Multipart/mixed (primary) subtype
• 7.2.3. The Multipart/alternative subtype
• 7.2.4. The Multipart/digest subtype
• 7.2.5. The Multipart/parallel subtype
• 7.2.6. Other Multipart subtypes

Next: 7.2.1. Multipart: The common syntax

Connected: An Internet Encyclopedia
7.2. The Multipart Content-Type