1 - 2 - 7 - 8 - A - B - C - D - E - F - G - H - I - J - L - M - N - O - P - Q - R - S - T - U - V - W - X
encapsulation
Click on the red underlined text to get to the source
... top-level") message being transferred on a network, or
a message encapsulated in a body of type "message".
The term "body part", in this document, means one of the parts of the
...
... type "message".
message -- an encapsulated message. A body of
Content-Type "message" is itself all or part of a
...
... quoted-printable encoded body in a multipart entity, to ensure that
the encapsulation boundary does not appear anywhere in the encoded
body. (A good strategy is to choose a boundary that includes a
character sequence ...
...
NOTE: There is no need to worry about quoting apparent
encapsulation boundaries within base64-encoded parts of multipart
entities because no hyphen characters are used in the base64
encoding ...
... 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 ...
... 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 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 ...
... Content-Type:
message", and its body (after the blank line) must be the
encapsulated message, with its own "Content-Type: image" header
field ...
... 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
...
... 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 ...
... 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 Content-Type field for multipart entities requires one parameter,
"boundary", which is used to specify the encapsulation boundary. The
encapsulation boundary is defined as a line consisting entirely of
...
... "boundary", which is used to specify the encapsulation boundary. The
encapsulation boundary is defined as a line consisting entirely of
two hyphen characters ("-", decimal code 45) followed by the boundary
parameter value ...
... 934 method of message encapsulation, and for ease of searching for
the boundaries in some implementations. However, it should be
noted that multipart messages are NOT completely compatible with
...
... noted that multipart messages are NOT completely compatible with
RFC 934 encapsulations; in particular, they do not obey RFC 934
quoting conventions for embedded lines that begin with hyphens.
...
... --gc0p4Jq0M:2Yt08jU534c0p
Note that the encapsulation boundary must occur at the beginning of a
line, i.e., following a CRLF, and that the initial CRLF ...
... CRLF, and that the initial CRLF is considered
to be attached to the encapsulation boundary rather than part of the
preceding part. The boundary must be followed immediately either by
another CRLF ...
...
NOTE: The CRLF preceding the encapsulation line is conceptually
attached to the boundary so that it is possible to have a part
that does not end with a CRLF ...
... be considered to end with line breaks, therefore, must have two
CRLFs preceding the encapsulation line, the first of which is part
of the preceding body part, and the second of which is part of the
encapsulation ...
... encapsulation line, the first of which is part
of the preceding body part, and the second of which is part of the
encapsulation boundary.
Encapsulation ...
... encapsulation boundary.
Encapsulation boundaries must not appear within the encapsulations,
and must be no longer than 70 characters, not counting the two
...
...
Encapsulation boundaries must not appear within the encapsulations,
and must be no longer than 70 characters, not counting the two
leading hyphens.
...
... leading hyphens.
The encapsulation boundary following the last body part is a
distinguished delimiter that indicates that no further body parts
will follow. Such a delimiter is identical to the previous
...
...
There appears to be room for additional information prior to the
first encapsulation boundary and following the final boundary. These
areas should generally be left blank, and implementations must ignore
anything that appears before the first boundary or after the last
...
... MIME-compliant software.
NOTE: Because encapsulation boundaries must not appear in the body
parts being encapsulated, a user agent ...
... NOTE: Because encapsulation boundaries must not appear in the body
parts being encapsulated, a user agent must exercise care to
choose a unique boundary. The boundary in the example above could
...
... boundaries with a very low probability of already existing in the
data to be encapsulated without having to prescan the data.
Alternate algorithms might result in more 'readable' boundaries
...
... user agent, but would require more
attention to the possibility that the boundary might appear in the
encapsulated part. The simplest boundary possible is something
like "---", with a closing boundary of "-----".
...
... follows:
multipart-body := preamble 1*encapsulation
close-delimiter epilogue
...
... close-delimiter epilogue
encapsulation := delimiter body-part CRLF
...
...
It is frequently desirable, in sending mail, to encapsulate another
mail message. For this common operation, a special Content-Type ...
... case the Content-Transfer-Encoding header field in the encapsulated
message will reflect this. Non-ASCII text in the headers ...
... Non-ASCII text in the headers of an
encapsulated message can be specified using the mechanisms described
in [RFC-1522].
...
... remove, or reorder header fields.
Such alterations are explicitly forbidden for the encapsulated
headers embedded in the bodies of messages of type "message."
...
... A Content-Type of "message/rfc822" indicates that the body contains
an encapsulated message, with the syntax of an RFC 822std11(-> 2822prop) message.
However, unlike top-level ...
... and still have it appear to the recipient as a simple audio message
rather than as an encapsulated message containing an audio message.
That is, the encapsulation ...
... encapsulated message containing an audio message.
That is, the encapsulation of the message is considered to be
"transparent".
...
... When generating and reassembling the parts of a message/partial
message, the headers of the encapsulated message must be merged with
the headers of the enclosing entities. In this process the following
...
... Note on encoding of MIME entities encapsulated inside message/partial
entities: Because data of type "message" may never be encoded in
base64 ...
... 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 ...
... 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
...
... 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:
...
... in the sections that follow.
The encapsulated headers in ALL message/external-body entities MUST
...
... entity will contain the header fields of the encapsulated message.
The body itself is to be found in the external location. This means
that if the body of the "message/external-body ...
...
-- Recognize and display at least the
primary (822) encapsulation.
Multipart:
...
... message has five parts to be displayed serially: two introductory
plain text parts, an embedded multipart message, a richtext part, and
a closing encapsulated text message in a non-ASCII character set ...
... message-type := "message" "/" message-subtype
multipart-body :=preamble 1*encapsulation close-delimiter epilogue
multipart-subtype := "mixed" / "parallel" / "digest"
...
... Rose, M., and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC 934, Delaware and NMA, January 1985. ...