------ next message ------
------ main boundary ------
5.1.6. Parallel Subtype
This document defines a "parallel" subtype of the "multipart"
Content-Type. This type is syntactically identical to
"multipart/mixed", but the semantics are different. In particular,
RFC 2046 Media Types November 1996
in a parallel entity, the order of body parts is not significant.
A common presentation of this type is to display all of the parts
simultaneously on hardware and software that are capable of doing so.
However, composing agents should be aware that many mail readers will
lack this capability and will show the parts serially in any event.
5.1.7. Other Multipart Subtypes
Other "multipart" subtypes are expected in the future. MIME
implementations must in general treat unrecognized subtypes of
"multipart" as being equivalent to "multipart/mixed".
5.2. Message Media Type
It is frequently desirable, in sending mail, to encapsulate another
mail message. A special media type, "message", is defined to
facilitate this. In particular, the "rfc822" subtype of "message" is
used to encapsulate RFC 822 messages.
NOTE: It has been suggested that subtypes of "message" might be
defined for forwarded or rejected messages. However, forwarded and
rejected messages can be handled as multipart messages in which the
first part contains any control or descriptive information, and a
second part, of type "message/rfc822", is the forwarded or rejected
message. Composing rejection and forwarding messages in this manner
will preserve the type information on the original message and allow
it to be correctly presented to the recipient, and hence is strongly
encouraged.
Subtypes of "message" often impose restrictions on what encodings are
allowed. These restrictions are described in conjunction with each
specific subtype.
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.
These operations are explicitly forbidden for the encapsulated
headers embedded in the bodies of messages of type "message."
5.2.1. RFC822 Subtype
A media type of "message/rfc822" indicates that the body contains an
encapsulated message, with the syntax of an RFC 822 message.
However, unlike top-level RFC 822 messages, the restriction that each
"message/rfc822" body must include a "From", "Date", and at least one
destination header is removed and replaced with the requirement that
at least one of "From", "Subject", or "Date" must be present.
RFC 2046 Media Types November 1996
It should be noted that, despite the use of the numbers "822", a
"message/rfc822" entity isn't restricted to material in strict
conformance to RFC822, nor are the semantics of "message/rfc822"
objects restricted to the semantics defined in RFC822. More
specifically, a "message/rfc822" message could well be a News article
or a MIME message.
No encoding other than "7bit", "8bit", or "binary" is permitted for
the body of a "message/rfc822" entity. The message header fields are
always US-ASCII in any case, and data within the body can still be
encoded, in which case the Content-Transfer-Encoding header field in
the encapsulated message will reflect this. Non-US-ASCII text in the
headers of an encapsulated message can be specified using the
mechanisms described in RFC 2047.
5.2.2. Partial Subtype
The "partial" subtype is defined to allow large entities to be
delivered as several separate pieces of mail and automatically
reassembled by a receiving user agent. (The concept is similar to IP
fragmentation and reassembly in the basic Internet Protocols.) This
mechanism can be used when intermediate transport agents limit the
size of individual messages that can be sent. The media type
"message/partial" thus indicates that the body contains a fragment of
a larger entity.
=16= |