< draft-ietf-822ext-mime-imt-02.txt   draft-ietf-822ext-mime-imt-03.txt >
Network Working Group Nathaniel Borenstein Network Working Group Nathaniel Borenstein
Internet Draft Ned Freed Internet Draft Ned Freed
<draft-ietf-822ext-mime-imt-02.txt> <draft-ietf-822ext-mime-imt-03.txt>
Multipurpose Internet Mail Extensions Multipurpose Internet Mail Extensions
(MIME) Part Two: (MIME) Part Two:
Media Types Media Types
December 1995 January 1996
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 3, line 32 skipping to change at page 3, line 32
6.5.1 Octet-Stream Subtype .............................. 15 6.5.1 Octet-Stream Subtype .............................. 15
6.5.2 PostScript Subtype ................................ 15 6.5.2 PostScript Subtype ................................ 15
6.5.3 Other Application Subtypes ........................ 19 6.5.3 Other Application Subtypes ........................ 19
7 Composite Media Type Values ........................... 19 7 Composite Media Type Values ........................... 19
7.1 Multipart Media Type ................................ 19 7.1 Multipart Media Type ................................ 19
7.1.1 Common Syntax ..................................... 21 7.1.1 Common Syntax ..................................... 21
7.1.2 Handling Nested Messages and Multiparts ........... 27 7.1.2 Handling Nested Messages and Multiparts ........... 27
7.1.3 Mixed Subtype ..................................... 28 7.1.3 Mixed Subtype ..................................... 28
7.1.4 Alternative Subtype ............................... 28 7.1.4 Alternative Subtype ............................... 28
7.1.5 Digest Subtype .................................... 30 7.1.5 Digest Subtype .................................... 30
7.1.6 Parallel Subtype .................................. 31 7.1.6 Parallel Subtype .................................. 32
7.1.7 Other Multipart Subtypes .......................... 32 7.1.7 Other Multipart Subtypes .......................... 32
7.2 Message Media Type .................................. 32 7.2 Message Media Type .................................. 32
7.2.1 RFC822 Subtype .................................... 32 7.2.1 RFC822 Subtype .................................... 33
7.2.2 Partial Subtype ................................... 33 7.2.2 Partial Subtype ................................... 33
7.2.2.1 Message Fragmentation and Reassembly ............ 34 7.2.2.1 Message Fragmentation and Reassembly ............ 35
7.2.2.2 Fragmentation and Reassembly Example ............ 35 7.2.2.2 Fragmentation and Reassembly Example ............ 36
7.2.3 External-Body Subtype ............................. 37 7.2.3 External-Body Subtype ............................. 38
7.2.4 Other Message Subtypes ............................ 46 7.2.4 Other Message Subtypes ............................ 46
8 Experimental Media Type Values ........................ 46 8 Experimental Media Type Values ........................ 46
9 Summary ............................................... 47 9 Summary ............................................... 47
10 Security Considerations .............................. 47 10 Security Considerations .............................. 47
11 Authors' Addresses ................................... 48 11 Authors' Addresses ................................... 48
A Collected Grammar ..................................... 49 A Collected Grammar ..................................... 49
3. Introduction 3. Introduction
The first document in this set, RFC MIME-IMB, defines a number The first document in this set, RFC MIME-IMB, defines a number
of header fields, including Content-Type. The Content-Type of header fields, including Content-Type. The Content-Type
skipping to change at page 6, line 8 skipping to change at page 6, line 8
character set. Other subtypes are to be used for character set. Other subtypes are to be used for
enriched text in forms where application software may enriched text in forms where application software may
enhance the appearance of the text, but such software enhance the appearance of the text, but such software
must not be required in order to get the general idea must not be required in order to get the general idea
of the content. Possible subtypes thus include any of the content. Possible subtypes thus include any
word processor format that can be read without word processor format that can be read without
resorting to software that understands the format. In resorting to software that understands the format. In
particular, formats that employ embeddded binary particular, formats that employ embeddded binary
formatting information are not considered directly formatting information are not considered directly
readable. A very simple and portable subtype, readable. A very simple and portable subtype,
"richtext", was defined in RFC 1341 [RFC-1341], with a "richtext", was defined in RFC 1341, with a further
further revision in RFC 1563 [RFC-1563] under the name revision in RFC 1563 under the name "enriched".
"enriched".
(2) image -- image data. Image requires a display device (2) image -- image data. Image requires a display device
(such as a graphical display, a graphics printer, or a (such as a graphical display, a graphics printer, or a
FAX machine) to view the information. An initial FAX machine) to view the information. An initial
subtype is defined for the widely-used image format subtype is defined for the widely-used image format
JPEG. JPEG.
(3) audio -- audio data. Audio requires an audio output (3) audio -- audio data. Audio requires an audio output
device (such as a speaker or a telephone) to "display" device (such as a speaker or a telephone) to "display"
the contents. An initial subtype "basic" is defined in the contents. An initial subtype "basic" is defined in
skipping to change at page 7, line 41 skipping to change at page 7, line 38
6. Discrete Media Type Values 6. Discrete Media Type Values
Five of the seven initial media type values refer to discrete Five of the seven initial media type values refer to discrete
bodies. The content of these types must be handled by non-MIME bodies. The content of these types must be handled by non-MIME
mechanisms; they are opaque to MIME processors. mechanisms; they are opaque to MIME processors.
6.1. Text Media Type 6.1. Text Media Type
The text media type is intended for sending material which is The text media type is intended for sending material which is
principally textual in form. A "charset" parameter may be principally textual in form. A "charset" parameter may be
used to indicate the character set of the body text for some used to indicate the character set of the body text for text
text subtypes, notably including the subtype "text/plain", subtypes, notably including the subtype "text/plain", which
which indicates plain (unformatted) text. indicates plain (unformatted) text.
Beyond plain text, there are many formats for representing Beyond plain text, there are many formats for representing
what might be known as "extended text" -- text with embedded what might be known as "extended text" -- text with embedded
formatting and presentation information. An interesting formatting and presentation information. An interesting
characteristic of many such representations is that they are characteristic of many such representations is that they are
to some extent readable even without the software that to some extent readable even without the software that
interprets them. It is useful, then, to distinguish them, at interprets them. It is useful, then, to distinguish them, at
the highest level, from such unreadable data as images, audio, the highest level, from such unreadable data as images, audio,
or text represented in an unreadable form. In the absence of or text represented in an unreadable form. In the absence of
appropriate interpretation software, it is reasonable to show appropriate interpretation software, it is reasonable to show
skipping to change at page 20, line 19 skipping to change at page 20, line 19
actually being an RFC 822 message. To begin with, NO header actually being an RFC 822 message. To begin with, NO header
fields are actually required in body parts. A body part that fields are actually required in body parts. A body part that
starts with a blank line, therefore, is allowed and is a body starts with a blank line, therefore, is allowed and is a body
part for which all default values are to be assumed. In such part for which all default values are to be assumed. In such
a case, the absence of a Content-Type header usually indicates a case, the absence of a Content-Type header usually indicates
that the corresponding body has a content-type of "text/plain; that the corresponding body has a content-type of "text/plain;
charset=US-ASCII". charset=US-ASCII".
The only header fields that have defined meaning for body The only header fields that have defined meaning for body
parts are those the names of which begin with "Content-". All parts are those the names of which begin with "Content-". All
other header fields are generally to be ignored in body parts. other header fields may be ignored in body parts. Although
Although they should generally be retained if at all possible, they should generally be retained if at all possible, they may
they may be discarded by gateways if necessary. Such other be discarded by gateways if necessary. Such other fields are
fields are permitted to appear in body parts but must not be permitted to appear in body parts but must not be depended on.
depended on. "X-" fields may be created for experimental or "X-" fields may be created for experimental or private
private purposes, with the recognition that the information purposes, with the recognition that the information they
they contain may be lost at some gateways. contain may be lost at some gateways.
NOTE: The distinction between an RFC 822 message and a body NOTE: The distinction between an RFC 822 message and a body
part is subtle, but important. A gateway between Internet and part is subtle, but important. A gateway between Internet and
X.400 mail, for example, must be able to tell the difference X.400 mail, for example, must be able to tell the difference
between a body part that contains an image and a body part between a body part that contains an image and a body part
that contains an encapsulated message, the body of which is a that contains an encapsulated message, the body of which is a
JPEG image. In order to represent the latter, the body part JPEG image. In order to represent the latter, the body part
must have "Content-Type: message/rfc822", and its body (after must have "Content-Type: message/rfc822", and its body (after
the blank line) must be the encapsulated message, with its own the blank line) must be the encapsulated message, with its own
"Content-Type: image/jpeg" header field. The use of similar "Content-Type: image/jpeg" header field. The use of similar
syntax facilitates the conversion of messages to body parts, syntax facilitates the conversion of messages to body parts,
and vice versa, but the distinction between the two must be and vice versa, but the distinction between the two must be
understood by implementors. (For the special case in which understood by implementors. (For the special case in which
most parts actually are messages, a "digest" subtype is also parts actually are messages, a "digest" subtype is also
defined.) defined.)
As stated previously, each body part is preceded by a boundary As stated previously, each body part is preceded by a boundary
delimiter line that contains the boundary delimiter. The delimiter line that contains the boundary delimiter. The
boundary delimiter MUST NOT appear inside any of the boundary delimiter MUST NOT appear inside any of the
encapsulated parts, on a line by itself or as the prefix of encapsulated parts, on a line by itself or as the prefix of
any line. This implies that it is crucial that the composing any line. This implies that it is crucial that the composing
agent be able to choose and specify a unique boundary agent be able to choose and specify a unique boundary
parameter value that does not contain the boundary parameter parameter value that does not contain the boundary parameter
value of an enclosing multipart as a prefix. value of an enclosing multipart as a prefix.
skipping to change at page 26, line 30 skipping to change at page 26, line 30
delimiter := CRLF dash-boundary delimiter := CRLF dash-boundary
close-delimiter := delimiter "--" close-delimiter := delimiter "--"
preamble := discard-text preamble := discard-text
epilogue := discard-text epilogue := discard-text
discard-text := *(*text CRLF) *text discard-text := *(*text CRLF) *text
; To be ignored upon receipt. ; May be ignored or discarded.
body-part := MIME-part-headers [CRLF *OCTET] body-part := MIME-part-headers [CRLF *OCTET]
; Lines in a body-part must not start ; Lines in a body-part must not start
; with the specified dash-boundary and ; with the specified dash-boundary and
; the delimiter must not appear anywhere ; the delimiter must not appear anywhere
; in the body part. Note that the ; in the body part. Note that the
; semantics of a body-part differ from ; semantics of a body-part differ from
; the semantics of a message, as ; the semantics of a message, as
; described in the text. ; described in the text.
skipping to change at page 31, line 6 skipping to change at page 31, line 6
This document defines a "digest" subtype of the multipart This document defines a "digest" subtype of the multipart
Content-Type. This type is syntactically identical to Content-Type. This type is syntactically identical to
multipart/mixed, but the semantics are different. In multipart/mixed, but the semantics are different. In
particular, in a digest, the default Content-Type value for a particular, in a digest, the default Content-Type value for a
body part is changed from "text/plain" to "message/rfc822". body part is changed from "text/plain" to "message/rfc822".
This is done to allow a more readable digest format that is This is done to allow a more readable digest format that is
largely compatible (except for the quoting convention) with largely compatible (except for the quoting convention) with
RFC 934. RFC 934.
Note: Though it is possible to specify a Content-Type value
for a body part in a digest which is other than
"message/rfc822", such as a text/plain part containing a
description of the material in the digest, actually doing so
is undesireble. The "multipart/digest" Content-Type is
intended to be used to send collections of messages. If a
"text/plain" part is needed, it should be included as a
seperate part of a "multipart/mixed" message.
A digest in this format might, then, look something like this: A digest in this format might, then, look something like this:
From: Moderator-Address From: Moderator-Address
To: Recipient-List To: Recipient-List
Date: Mon, 22 Mar 1994 13:34:51 +0000 Date: Mon, 22 Mar 1994 13:34:51 +0000
Subject: Internet Digest, volume 42 Subject: Internet Digest, volume 42
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="---- main boundary ----"
------ main boundary ----
...Introductory text or table of contents...
------ main boundary ----
Content-Type: multipart/digest; Content-Type: multipart/digest;
boundary="---- next message ----" boundary="---- next message ----"
------ next message ---- ------ next message ----
From: someone-else From: someone-else
Date: Fri, 26 Mar 1993 11:13:32 +0200 Date: Fri, 26 Mar 1993 11:13:32 +0200
Subject: my opinion Subject: my opinion
...body goes here ... ...body goes here ...
skipping to change at page 31, line 34 skipping to change at page 32, line 7
------ next message ---- ------ next message ----
From: someone-else-again From: someone-else-again
Date: Fri, 26 Mar 1993 10:07:13 -0500 Date: Fri, 26 Mar 1993 10:07:13 -0500
Subject: my different opinion Subject: my different opinion
... another body goes here ... ... another body goes here ...
------ next message ------ ------ next message ------
------ main boundary ------
7.1.6. Parallel Subtype 7.1.6. Parallel Subtype
This document defines a "parallel" subtype of the multipart This document defines a "parallel" subtype of the multipart
Content-Type. This type is syntactically identical to Content-Type. This type is syntactically identical to
multipart/mixed, but the semantics are different. In multipart/mixed, but the semantics are different. In
particular, in a parallel entity, the order of body parts is particular, in a parallel entity, the order of body parts is
not significant. not significant.
A common presentation of this type is to display all of the A common presentation of this type is to display all of the
parts simultaneously on hardware and software that are capable parts simultaneously on hardware and software that are capable
skipping to change at page 32, line 36 skipping to change at page 33, line 12
allow it to be correctly presented to the recipient, and hence allow it to be correctly presented to the recipient, and hence
is strongly encouraged. is strongly encouraged.
Subtypes of message often impose restrictions on what Subtypes of message often impose restrictions on what
encodings are allowed. These restrictions are described in encodings are allowed. These restrictions are described in
conjunction with each specific subtype. conjunction with each specific subtype.
Mail gateways, relays, and other mail handling agents are Mail gateways, relays, and other mail handling agents are
commonly known to alter the top-level header of an RFC 822 commonly known to alter the top-level header of an RFC 822
message. In particular, they frequently add, remove, or message. In particular, they frequently add, remove, or
reorder header fields. Such alterations are explicitly reorder header fields. These operations are explicitly
forbidden for the encapsulated headers embedded in the bodies forbidden for the encapsulated headers embedded in the bodies
of messages of type "message." of messages of type "message."
7.2.1. RFC822 Subtype 7.2.1. RFC822 Subtype
A media type of "message/rfc822" indicates that the body A media type of "message/rfc822" indicates that the body
contains an encapsulated message, with the syntax of an RFC contains an encapsulated message, with the syntax of an RFC
822 message. However, unlike top-level RFC 822 messages, the 822 message. However, unlike top-level RFC 822 messages, the
restriction that each message/rfc822 body must include a restriction that each message/rfc822 body must include a
"From", "Date", and at least one destination header is removed "From", "Date", and at least one destination header is removed
and replaced with the requirement that at least one of "From", and replaced with the requirement that at least one of "From",
"Subject", or "Date" must be present. "Subject", or "Date" must be present.
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. Such entities can also include enhanced
information as defined in this document. In other words, a
message/rfc822 message could well be a News article or a MIME
message.
No encoding other than "7bit", "8bit", or "binary" is No encoding other than "7bit", "8bit", or "binary" is
permitted for the body of a "message/rfc822" entity. The permitted for the body of a "message/rfc822" entity. The
message header fields are always US-ASCII in any case, and message header fields are always US-ASCII in any case, and
data within the body can still be encoded, in which case the data within the body can still be encoded, in which case the
Content-Transfer-Encoding header field in the encapsulated Content-Transfer-Encoding header field in the encapsulated
message will reflect this. Non-US-ASCII text in the headers message will reflect this. Non-US-ASCII text in the headers
of an encapsulated message can be specified using the of an encapsulated message can be specified using the
mechanisms described in RFC MIME-HEADERS. mechanisms described in RFC MIME-HEADERS.
It should be noted that, despite the use of the numbers "822",
a message/rfc822 entity can include enhanced information as
defined in this document. In other words, a message/rfc822
message may be a MIME message.
7.2.2. Partial Subtype 7.2.2. Partial Subtype
The "partial" subtype is defined to allow large entities to be The "partial" subtype is defined to allow large entities to be
delivered as several separate pieces of mail and automatically delivered as several separate pieces of mail and automatically
reassembled by a receiving user agent. (The concept is reassembled by a receiving user agent. (The concept is
similar to IP fragmentation and reassembly in the basic similar to IP fragmentation and reassembly in the basic
Internet Protocols.) This mechanism can be used when Internet Protocols.) This mechanism can be used when
intermediate transport agents limit the size of individual intermediate transport agents limit the size of individual
messages that can be sent. The media type "message/partial" messages that can be sent. The media type "message/partial"
thus indicates that the body contains a fragment of a larger thus indicates that the body contains a fragment of a larger
entity. entity.
Because data of type "message" may never be encoded in base64
or quoted-printable, a problem might arise if message/partial
entities are constructed in an environment that supports
binary or 8bit transport. The problem is that the binary data
would be split into multiple message/partial messages, each of
them requiring binary transport. If such messages were
encountered at a gateway into a 7bit transport environment,
there would be no way to properly encode them for the 7bit
world, aside from waiting for all of the fragments,
reassembling the inner message, and then encoding the
reassembled data in base64 or quoted-printable. Since it is
possible that different fragments might go through different
gateways, even this is not an acceptable solution. For this
reason, it is specified that entities of type message/partial
must always have a content-transfer-encoding of 7bit (the
default). In particular, even in environments that support
binary or 8bit transport, the use of a content-transfer-
encoding of "8bit" or "binary" is explicitly prohibited for
MIME entities of type message/partial. This in turn implies
that the inner message must not use "8bit" or "binary"
encoding.
Because some message transfer agents may choose to
automatically fragment large messages, and because such agents
may use very different fragmentation thresholds, it is
possible that the pieces of a partial message, upon
reassembly, may prove themselves to comprise a partial
message. This is explicitly permitted.
Three parameters must be specified in the Content-Type field Three parameters must be specified in the Content-Type field
of type message/partial: The first, "id", is a unique of type message/partial: The first, "id", is a unique
identifier, as close to a world-unique identifier as possible, identifier, as close to a world-unique identifier as possible,
to be used to match the fragments together. (In general, the to be used to match the fragments together. (In general, the
identifier is essentially a message-id; if placed in double identifier is essentially a message-id; if placed in double
quotes, it can be ANY message-id, in accordance with the BNF quotes, it can be ANY message-id, in accordance with the BNF
for "parameter" given earlier in this specification.) The for "parameter" given earlier in this specification.) The
second, "number", an integer, is the fragment number, which second, "number", an integer, is the fragment number, which
indicates where this fragment fits into the sequence of indicates where this fragment fits into the sequence of
fragments. The third, "total", another integer, is the total fragments. The third, "total", another integer, is the total
skipping to change at page 36, line 33 skipping to change at page 37, line 35
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail Subject: Audio mail
Message-ID: <anotherid@foo.com> Message-ID: <anotherid@foo.com>
MIME-Version: 1.0 MIME-Version: 1.0
Content-type: audio/basic Content-type: audio/basic
Content-transfer-encoding: base64 Content-transfer-encoding: base64
... first half of encoded audio data goes here ... ... first half of encoded audio data goes here ...
... second half of encoded audio data goes here ... ... second half of encoded audio data goes here ...
Because data of type "message" may never be encoded in base64
or quoted-printable, a problem might arise if message/partial
entities are constructed in an environment that supports
binary or 8bit transport. The problem is that the binary data
would be split into multiple message/partial messages, each of
them requiring binary transport. If such messages were
encountered at a gateway into a 7bit transport environment,
there would be no way to properly encode them for the 7bit
world, aside from waiting for all of the fragments,
reassembling the inner message, and then encoding the
reassembled data in base64 or quoted-printable. Since it is
possible that different fragments might go through different
gateways, even this is not an acceptable solution. For this
reason, it is specified that entities of type message/partial
must always have a content-transfer-encoding of 7bit (the
default). In particular, even in environments that support
binary or 8bit transport, the use of a content-transfer-
encoding of "8bit" or "binary" is explicitly prohibited for
MIME entities of type message/partial.
Because some message transfer agents may choose to
automatically fragment large messages, and because such agents
may use very different fragmentation thresholds, it is
possible that the pieces of a partial message, upon
reassembly, may prove themselves to comprise a partial
message. This is explicitly permitted.
The inclusion of a "References" field in the headers of the The inclusion of a "References" field in the headers of the
second and subsequent pieces of a fragmented message that second and subsequent pieces of a fragmented message that
references the Message-Id on the previous piece may be of references the Message-Id on the previous piece may be of
benefit to mail readers that understand and track references. benefit to mail readers that understand and track references.
However, the generation of such "References" fields is However, the generation of such "References" fields is
entirely optional. entirely optional.
Finally, it should be noted that the "Encrypted" header field Finally, it should be noted that the "Encrypted" header field
has been made obsolete by Privacy Enhanced Messaging (PEM) has been made obsolete by Privacy Enhanced Messaging (PEM)
[RFC1421, RFC1422, RFC1423, and RFC1424], but the rules above [RFC1421, RFC1422, RFC1423, and RFC1424], but the rules above
skipping to change at page 46, line 34 skipping to change at page 46, line 34
In particular, anything before the first consecutive pair of In particular, anything before the first consecutive pair of
CRLFs is header information, while anything after it is body CRLFs is header information, while anything after it is body
information, which is ignored for most access-types. information, which is ignored for most access-types.
7.2.4. Other Message Subtypes 7.2.4. Other Message Subtypes
MIME implementations must in general treat unrecognized MIME implementations must in general treat unrecognized
subtypes of message as being equivalent to subtypes of message as being equivalent to
"application/octet-stream". "application/octet-stream".
Future subtypes of message intended for use with email should
be restricted to "7bit" encoding. A type other than message
should be used if restriction to "7bit" is not possible.
8. Experimental Media Type Values 8. Experimental Media Type Values
A media type value beginning with the characters "X-" is a A media type value beginning with the characters "X-" is a
private value, to be used by consenting systems by mutual private value, to be used by consenting systems by mutual
agreement. Any format without a rigorous and public agreement. Any format without a rigorous and public
definition must be named with an "X-" prefix, and publicly definition must be named with an "X-" prefix, and publicly
specified values shall never begin with "X-". (Older versions specified values shall never begin with "X-". (Older versions
of the widely used Andrew system use the "X-BE2" name, so new of the widely used Andrew system use the "X-BE2" name, so new
systems should probably choose a different name.) systems should probably choose a different name.)
In general, the use of "X-" top-level types is strongly In general, the use of "X-" top-level types is strongly
discouraged. Implementors should invent subtypes of the discouraged. Implementors should invent subtypes of the
existing types whenever possible. In many cases, a subtype of existing types whenever possible. In many cases, a subtype of
application will be more appropriate than a new top-level application will be more appropriate than a new top-level
type. type.
9. Summary 9. Summary
The five discrete media types provide provide a standardized The five discrete media types provide provide a standardized
mechanism for tagging entities as audio, image, or several mechanism for tagging entities as audio, image, or several
skipping to change at page 49, line 43 skipping to change at page 49, line 43
close-delimiter := delimiter "--" close-delimiter := delimiter "--"
dash-boundary := "--" boundary dash-boundary := "--" boundary
; boundary taken from the value of ; boundary taken from the value of
; boundary parameter of the ; boundary parameter of the
; Content-Type field. ; Content-Type field.
delimiter := CRLF dash-boundary delimiter := CRLF dash-boundary
discard-text := *(*text CRLF) discard-text := *(*text CRLF)
; To be ignored upon receipt. ; May be ignored or discarded.
encapsulation := delimiter transport-padding encapsulation := delimiter transport-padding
CRLF body-part CRLF body-part
epilogue := discard-text epilogue := discard-text
multipart-body := [preamble CRLF] multipart-body := [preamble CRLF]
dash-boundary transport-padding CRLF dash-boundary transport-padding CRLF
body-part *encapsulation body-part *encapsulation
close-delimiter transport-padding close-delimiter transport-padding
 End of changes. 21 change blocks. 
57 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/