< draft-ietf-822ext-mime-imt-00.txt   draft-ietf-822ext-mime-imt-01.txt >
Network Working Group Nathaniel Borenstein Network Working Group Nathaniel Borenstein
Internet Draft Ned Freed Internet Draft Ned Freed
<draft-ietf-822ext-mime-imt-00.txt> <draft-ietf-822ext-mime-imt-01.txt>
Multipurpose Internet Mail Extensions Multipurpose Internet Mail Extensions
(MIME) Part Two: (MIME) Part Two:
Media Types Media Types
April 11, 1995 May 5, 1995
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 19 skipping to change at page 3, line 19
3 Introduction .......................................... 4 3 Introduction .......................................... 4
4 Definition of a Top-Level Media Type .................. 5 4 Definition of a Top-Level Media Type .................. 5
5 Overview Of The Initial Top-Level Media Types ......... 5 5 Overview Of The Initial Top-Level Media Types ......... 5
6 Discrete Media Type Values ............................ 7 6 Discrete Media Type Values ............................ 7
6.1 Text Media Type ..................................... 7 6.1 Text Media Type ..................................... 7
6.1.1 Representation of Line Breaks ..................... 8 6.1.1 Representation of Line Breaks ..................... 8
6.1.2 Charset Parameter ................................. 8 6.1.2 Charset Parameter ................................. 8
6.1.3 Plain Subtype ..................................... 12 6.1.3 Plain Subtype ..................................... 12
6.1.4 Unrecognized Subtypes ............................. 12 6.1.4 Unrecognized Subtypes ............................. 12
6.2 Image Media Type .................................... 12 6.2 Image Media Type .................................... 12
6.3 Audio Media Type .................................... 12 6.3 Audio Media Type .................................... 13
6.4 Video Media Type .................................... 13 6.4 Video Media Type .................................... 13
6.5 Application Media Type .............................. 14 6.5 Application Media Type .............................. 14
6.5.1 Octet-Stream Subtype .............................. 14 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 ..................................... 27 7.1.3 Mixed Subtype ..................................... 27
7.1.4 Alternative Subtype ............................... 27 7.1.4 Alternative Subtype ............................... 28
7.1.5 Digest Subtype .................................... 29 7.1.5 Digest Subtype .................................... 30
7.1.6 Parallel Subtype .................................. 30 7.1.6 Parallel Subtype .................................. 31
7.1.7 Other Multipart Subtypes .......................... 31 7.1.7 Other Multipart Subtypes .......................... 32
7.2 Message Media Type .................................. 31 7.2 Message Media Type .................................. 32
7.2.1 RFC822 Subtype .................................... 32 7.2.1 RFC822 Subtype .................................... 32
7.2.2 Partial Subtype ................................... 32 7.2.2 Partial Subtype ................................... 33
7.2.2.1 Message Fragmentation and Reassembly ............ 33 7.2.2.1 Message Fragmentation and Reassembly ............ 34
7.2.2.2 Fragmentation and Reassembly Example ............ 34 7.2.2.2 Fragmentation and Reassembly Example ............ 35
7.2.3 External-Body Subtype ............................. 36 7.2.3 External-Body Subtype ............................. 37
7.2.3.1 General External-Body Parameters ................ 37 7.2.4 Other Message Subtypes ............................ 46
7.2.3.2 The 'ftp' and 'tftp' Access-Types ............... 39 8 Experimental Media Type Values ........................ 46
7.2.3.3 The 'anon-ftp' Access-Type ...................... 39 9 Summary ............................................... 47
7.2.3.4 The 'local-file' Access-Type .................... 40 10 Security Considerations .............................. 47
7.2.3.5 The 'mail-server' Access-Type ................... 40 11 Authors' Addresses ................................... 48
7.2.3.6 External-Body Security Issues ................... 41 A Collected Grammar ..................................... 49
7.2.3.7 Examples and Further Explanations ............... 42
7.2.4 Other Message Subtypes ............................ 45
8 Experimental Media Type Values ........................ 45
9 Summary ............................................... 46
10 Security Considerations .............................. 46
11 Authors' Addresses ................................... 46
A Collected Grammar ..................................... 48
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
field is used to specify the nature of the data in the body of field is used to specify the nature of the data in the body of
an entity, by giving media type and subtype identifiers, and an entity, by giving media type and subtype identifiers, and
by providing auxiliary information that may be required for by providing auxiliary information that may be required for
certain media types. After the type and subtype names, the certain media types. After the type and subtype names, the
remainder of the header field is simply a set of parameters, remainder of the header field is simply a set of parameters,
specified in an attribute/value notation. The ordering of specified in an attribute/value notation. The ordering of
skipping to change at page 8, line 32 skipping to change at page 8, line 32
6.1.1. Representation of Line Breaks 6.1.1. Representation of Line Breaks
The canonical form of any MIME text type MUST represent a line The canonical form of any MIME text type MUST represent a line
break as a CRLF sequence. Similarly, any occurrence of CRLF break as a CRLF sequence. Similarly, any occurrence of CRLF
in text MUST represent a line break. Use of CR and LF outside in text MUST represent a line break. Use of CR and LF outside
of line break sequences is also forbidden. of line break sequences is also forbidden.
This rule applies regardless of format or character set or This rule applies regardless of format or character set or
sets involved. sets involved.
NOTE: The proper interpretation of line breaks when a body is
displayed depends on the media type. In particular, while it
is appropriate to treat a line break as a transition to a new
line when displaying a text/plain body, this treatment is
actually incorrect for other subtypes of text like
text/enriched [RFC-1563].
6.1.2. Charset Parameter 6.1.2. Charset Parameter
A critical parameter that may be specified in the Content-Type A critical parameter that may be specified in the Content-Type
field for text/plain data is the character set. This is field for text/plain data is the character set. This is
specified with a "charset" parameter, as in: specified with a "charset" parameter, as in:
Content-type: text/plain; charset=iso-8859-1 Content-type: text/plain; charset=iso-8859-1
Unlike some other parameter values, the values of the charset Unlike some other parameter values, the values of the charset
parameter are NOT case sensitive. The default character set, parameter are NOT case sensitive. The default character set,
skipping to change at page 9, line 13 skipping to change at page 9, line 20
parameter, and may possibly restrict its values as well. When parameter, and may possibly restrict its values as well. When
used with a particular body, the semantics of the "charset" used with a particular body, the semantics of the "charset"
parameter should be identical to those specified here for parameter should be identical to those specified here for
"text/plain", i.e., the body consists entirely of characters "text/plain", i.e., the body consists entirely of characters
in the given charset. In particular, definers of future text in the given charset. In particular, definers of future text
subtypes should pay close attention to the implications of subtypes should pay close attention to the implications of
multioctet character sets for their subtype definitions. multioctet character sets for their subtype definitions.
This RFC specifies the definition of the charset parameter for This RFC specifies the definition of the charset parameter for
the purposes of MIME to be the name of a character set, as the purposes of MIME to be the name of a character set, as
"character set" as defined in Section 4 of this document. The "character set" as defined in MIME-IMB. The rules regarding
rules regarding line breaks detailed in the previous section line breaks detailed in the previous section must also be
must also be observed -- a character set whose definition does observed -- a character set whose definition does not conform
not conform to these rules cannot be used in a MIME text type. to these rules cannot be used in a MIME text type.
An initial list of predefined character set names can be found An initial list of predefined character set names can be found
at the end of this section. Additional character sets may be at the end of this section. Additional character sets may be
registered with IANA as described in RFC MIME-REG. registered with IANA as described in RFC MIME-REG.
Note that if the specified character set includes 8-bit data, Note that if the specified character set includes 8-bit data,
a Content-Transfer-Encoding header field and a corresponding a Content-Transfer-Encoding header field and a corresponding
encoding on the data are required in order to transmit the encoding on the data are required in order to transmit the
body via some mail transfer protocols, such as SMTP. body via some mail transfer protocols, such as SMTP.
skipping to change at page 26, line 4 skipping to change at page 26, line 18
; padding, but receivers MUST ; padding, but receivers MUST
; be able to handle padding ; be able to handle padding
; added by message transports. ; added by message transports.
encapsulation := delimiter transport-padding encapsulation := delimiter transport-padding
CRLF body-part CRLF body-part
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. ; To be ignored upon receipt.
body-part := <"message" as defined in RFC 822, with all body-part := <"message" as defined in RFC 822, with all
header fields optional, not starting with the header fields optional, not starting with the
specified dash-boundary, and with the specified dash-boundary, and with the
delimiter not occurring anywhere in the delimiter not occurring anywhere in the
message body. Note that the semantics of a body part. Note that the semantics of a
part differ from the semantics of a message, part differ from the semantics of a message,
as described in the text.> as described in the text.>
IMPORTANT NOTE: The free insertion of linear-white-space and IMPORTANT NOTE: The free insertion of linear-white-space and
RFC 822 comments between the elements shown in this BNF is NOT RFC 822 comments between the elements shown in this BNF is NOT
allowed since this BNF does not specify a structured header allowed since this BNF does not specify a structured header
field. field.
NOTE: In certain transport enclaves, RFC 822 restrictions NOTE: In certain transport enclaves, RFC 822 restrictions
such as the one that limits bodies to printable US-ASCII such as the one that limits bodies to printable US-ASCII
skipping to change at page 32, line 4 skipping to change at page 32, line 39
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. Such alterations 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.
No encoding other than "7bit", "8bit", or "binary" is No encoding other than "7bit", "8bit", or "binary" is
permitted for parts of type "message/rfc822". The message permitted for body parts of type "message/rfc822". The
header fields are always US-ASCII in any case, and data within message header fields are always US-ASCII in any case, and
the body can still be encoded, in which case the Content- data within the body can still be encoded, in which case the
Transfer-Encoding header field in the encapsulated message Content-Transfer-Encoding header field in the encapsulated
will reflect this. Non-US-ASCII text in the headers of an message will reflect this. Non-US-ASCII text in the headers
encapsulated message can be specified using the mechanisms of an encapsulated message can be specified using the
described in RFC MIME-HEADERS. mechanisms described in RFC MIME-HEADERS.
It should be noted that, despite the use of the numbers "822", It should be noted that, despite the use of the numbers "822",
a message/rfc822 entity can include enhanced information as a message/rfc822 entity can include enhanced information as
defined in this document. In other words, a message/rfc822 defined in this document. In other words, a message/rfc822
message may be a MIME message. 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
message. entity.
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 parts 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 part number, which second, "number", an integer, is the fragment number, which
indicates where this part fits into the sequence of fragments. indicates where this fragment fits into the sequence of
The third, "total", another integer, is the total number of fragments. The third, "total", another integer, is the total
parts. This third subfield is required on the final part, and number of fragments. This third subfield is required on the
is optional (though encouraged) on the earlier parts. Note final fragment, and is optional (though encouraged) on the
also that these parameters may be given in any order. earlier fragments. Note also that these parameters may be
given in any order.
Thus, part 2 of a 3-part message may have either of the Thus, the second piece of a 3-piece message may have either of
following header fields: the following header fields:
Content-Type: Message/Partial; number=2; total=3; Content-Type: Message/Partial; number=2; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com" id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
Content-Type: Message/Partial; Content-Type: Message/Partial;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
number=2 number=2
But part 3 MUST specify the total number of parts: But the third piece MUST specify the total number of
fragments:
Content-Type: Message/Partial; number=3; total=3; Content-Type: Message/Partial; number=3; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com" id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
Note that part numbering begins with 1, not 0. Note that fragment numbering begins with 1, not 0.
When the parts of a message broken up in this manner are put When the fragments of an entity broken up in this manner are
together, the result is a complete MIME entity, which may have put together, the result is a complete MIME entity, which may
its own Content-Type header field, and thus may contain any have its own Content-Type header field, and thus may contain
other data type. any other data type.
7.2.2.1. Message Fragmentation and Reassembly 7.2.2.1. Message Fragmentation and Reassembly
The semantics of a reassembled partial message must be those The semantics of a reassembled partial message must be those
of the "inner" message, rather than of a message containing of the "inner" message, rather than of a message containing
the inner message. This makes it possible, for example, to the inner message. This makes it possible, for example, to
send a large audio message as several partial messages, and send a large audio message as several partial messages, and
still have it appear to the recipient as a simple audio still have it appear to the recipient as a simple audio
message rather than as an encapsulated message containing an message rather than as an encapsulated message containing an
audio message. That is, the encapsulation of the message is audio message. That is, the encapsulation of the message is
considered to be "transparent". considered to be "transparent".
When generating and reassembling the parts of a When generating and reassembling the pieces of a
message/partial message, the headers of the encapsulated message/partial message, the headers of the encapsulated
message must be merged with the headers of the enclosing message must be merged with the headers of the enclosing
entities. In this process the following rules must be entities. In this process the following rules must be
observed: observed:
(1) All of the header fields from the initial enclosing (1) All of the header fields from the initial enclosing
entity (part one), except those that start with message, except those that start with "Content-" and
"Content-" and the specific header fields "Subject", the specific header fields "Subject", "Message-ID",
"Message-ID", "Encrypted", and "MIME-Version", must be "Encrypted", and "MIME-Version", must be copied, in
copied, in order, to the new message. order, to the new message.
(2) The header fields in the enclosed message which start (2) The header fields in the enclosed message which start
with "Content-", plus the "Subject", "Message-ID", with "Content-", plus the "Subject", "Message-ID",
"Encrypted", and "MIME-Version" fields, must be "Encrypted", and "MIME-Version" fields, must be
appended, in order, to the header fields of the new appended, in order, to the header fields of the new
message. Any header fields in the enclosed message message. Any header fields in the enclosed message
which do not start with "Content-" (except for the which do not start with "Content-" (except for the
"Subject", "Message-ID", "Encrypted", and "MIME- "Subject", "Message-ID", "Encrypted", and "MIME-
Version" fields) will be ignored and dropped. Version" fields) will be ignored and dropped.
(3) All of the header fields from the second and any (3) All of the header fields from the second and any
subsequent messages are discarded by the reassembly subsequent enclosing messages are discarded by the
process. reassembly process.
7.2.2.2. Fragmentation and Reassembly Example 7.2.2.2. Fragmentation and Reassembly Example
If an audio message is broken into two parts, the first part If an audio message is broken into two pieces, the first piece
might look something like this: might look something like this:
X-Weird-Header-1: Foo X-Weird-Header-1: Foo
From: Bill@host.com From: Bill@host.com
To: joe@otherhost.com To: joe@otherhost.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 1 of 2) Subject: Audio mail (part 1 of 2)
Message-ID: <id1@host.com> Message-ID: <id1@host.com>
MIME-Version: 1.0 MIME-Version: 1.0
Content-type: message/partial; id="ABC@host.com"; Content-type: message/partial; id="ABC@host.com";
skipping to change at page 48, line 28 skipping to change at page 49, line 28
bchars := bcharsnospace / " " bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
"+" / "_" / "," / "-" / "." / "+" / "_" / "," / "-" / "." /
"/" / ":" / "=" / "?" "/" / ":" / "=" / "?"
body-part := <"message" as defined in RFC 822, with all body-part := <"message" as defined in RFC 822, with all
header fields optional, not starting with the header fields optional, not starting with the
specified dash-boundary, and with the specified dash-boundary, and with the
delimiter not occurring anywhere in the delimiter not occurring anywhere in the
message body. Note that the semantics of a body part. Note that the semantics of a
part differ from the semantics of a message, part differ from the semantics of a message,
as described in the text.> as described in the text.>
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.
 End of changes. 24 change blocks. 
63 lines changed or deleted 67 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/