< draft-ietf-822ext-mime-imb-05.txt   draft-ietf-822ext-mime-imb-06.txt >
Network Working Group Nathaniel Borenstein Network Working Group Nathaniel Borenstein
Internet Draft Ned Freed Internet Draft Ned Freed
<draft-ietf-822ext-mime-imb-05.txt> <draft-ietf-822ext-mime-imb-06.txt>
Multipurpose Internet Mail Extensions Multipurpose Internet Mail Extensions
(MIME) Part One: (MIME) Part One:
Format of Internet Message Bodies Format of Internet Message Bodies
January 1996 March 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 2, line ? skipping to change at page 2, line ?
STD 11, RFC 822, defines a message representation protocol STD 11, RFC 822, defines a message representation protocol
specifying considerable detail about US-ASCII message headers, specifying considerable detail about US-ASCII message headers,
and leaves the message content, or message body, as flat US- and leaves the message content, or message body, as flat US-
ASCII text. This set of documents, collectively called the ASCII text. This set of documents, collectively called the
Multipurpose Internet Mail Extensions, or MIME, redefines the Multipurpose Internet Mail Extensions, or MIME, redefines the
format of messages to allow for format of messages to allow for
(1) textual message bodies in character sets other than (1) textual message bodies in character sets other than
US-ASCII, US-ASCII,
(2) non-textual message bodies, (2) an extensible set of different formats for non-textual
message bodies,
(3) multi-part message bodies, and (3) multi-part message bodies, and
(4) textual header information in character sets other than (4) textual header information in character sets other than
US-ASCII. US-ASCII.
These documents are based on earlier work documented in RFC These documents are based on earlier work documented in RFC
934, STD 11, and RFC 1049, but extends and revises them. 934, STD 11, and RFC 1049, but extends and revises them.
Because RFC 822 said so little about message bodies, these Because RFC 822 said so little about message bodies, these
documents are largely orthogonal to (rather than a revision documents are largely orthogonal to (rather than a revision
of) RFC 822. of) RFC 822.
In particular, these documents are designed to provide
facilities to include multiple parts in a single message, to
represent body and header text in character sets other than
US-ASCII, to represent formatted multi-font text messages, to
represent non-textual material such as images and audio clips,
and generally to facilitate later extensions defining new
types of Internet mail for use by cooperating mail agents.
This initial document specifies the various headers used to This initial document specifies the various headers used to
describe the structure of MIME messages. The second document, describe the structure of MIME messages. The second document,
RFC MIME-IMT, defines the general structure of the MIME media RFC MIME-IMT, defines the general structure of the MIME media
typing system and defines an initial set of media types. The typing system and defines an initial set of media types. The
third document, RFC MIME-HEADERS, describes extensions to RFC third document, RFC MIME-HEADERS, describes extensions to RFC
822 to allow non-US-ASCII text data in Internet mail header 822 to allow non-US-ASCII text data in Internet mail header
fields. The fourth document, RFC MIME-REG, specifies various fields. The fourth document, RFC MIME-REG, specifies various
IANA registration procedures for MIME-related facilities. The IANA registration procedures for MIME-related facilities. The
fifth and final document, RFC MIME-CONF, describes MIME fifth and final document, RFC MIME-CONF, describes MIME
conformance criteria as well as providing some illustrative conformance criteria as well as providing some illustrative
skipping to change at page 3, line 28 skipping to change at page 3, line 28
4.8 8bit Data ........................................... 9 4.8 8bit Data ........................................... 9
4.9 Binary Data ......................................... 9 4.9 Binary Data ......................................... 9
4.10 Lines .............................................. 9 4.10 Lines .............................................. 9
5 MIME Header Fields .................................... 9 5 MIME Header Fields .................................... 9
6 MIME-Version Header Field ............................. 10 6 MIME-Version Header Field ............................. 10
7 Content-Type Header Field ............................. 12 7 Content-Type Header Field ............................. 12
7.1 Syntax of the Content-Type Header Field ............. 14 7.1 Syntax of the Content-Type Header Field ............. 14
7.2 Content-Type Defaults ............................... 16 7.2 Content-Type Defaults ............................... 16
8 Content-Transfer-Encoding Header Field ................ 17 8 Content-Transfer-Encoding Header Field ................ 17
8.1 Content-Transfer-Encoding Syntax .................... 17 8.1 Content-Transfer-Encoding Syntax .................... 17
8.2 Content-Transfer-Encodings Sematics ................. 17 8.2 Content-Transfer-Encodings Semantics ................ 17
8.3 New Content-Transfer-Encodings ...................... 19 8.3 New Content-Transfer-Encodings ...................... 19
8.4 Interpretation and Use .............................. 19 8.4 Interpretation and Use .............................. 19
8.5 Translating Encodings ............................... 21 8.5 Translating Encodings ............................... 21
8.6 Canonical Encoding Model ............................ 22 8.6 Canonical Encoding Model ............................ 22
8.7 Quoted-Printable Content-Transfer-Encoding .......... 22 8.7 Quoted-Printable Content-Transfer-Encoding .......... 22
8.8 Base64 Content-Transfer-Encoding .................... 26 8.8 Base64 Content-Transfer-Encoding .................... 26
9 Content-ID Header Field ............................... 29 9 Content-ID Header Field ............................... 29
10 Content-Description Header Field ..................... 30 10 Content-Description Header Field ..................... 30
11 Additional MIME Header Fields ........................ 30 11 Additional MIME Header Fields ........................ 30
12 Summary .............................................. 30 12 Summary .............................................. 30
skipping to change at page 7, line 37 skipping to change at page 7, line 37
of converting a sequence of octets into a sequence of of converting a sequence of octets into a sequence of
characters. Note that unconditional and unambiguous characters. Note that unconditional and unambiguous
conversion in the other direction is not required, in that not conversion in the other direction is not required, in that not
all characters may be representable by a given character set all characters may be representable by a given character set
and a character set may provide more than one sequence of and a character set may provide more than one sequence of
octets to represent a particular sequence of characters. octets to represent a particular sequence of characters.
This definition is intended to allow various kinds of This definition is intended to allow various kinds of
character encodings, from simple single-table mappings such as character encodings, from simple single-table mappings such as
US-ASCII to complex table switching methods such as those that US-ASCII to complex table switching methods such as those that
use ISO 2022's techniques. However, the definition associated use ISO 2022's techniques, to be used as character sets.
with a MIME character set name must fully specify the mapping However, the definition associated with a MIME character set
to be performed. In particular, use of external profiling name must fully specify the mapping to be performed. In
information to determine the exact mapping is not permitted. particular, use of external profiling information to determine
the exact mapping is not permitted.
NOTE: The term "character set" was originally used in MIME NOTE: The term "character set" was originally used in MIME
with specifications such as US-ASCII and other 7bit and 8bit with specifications such as US-ASCII and other 7bit and 8bit
schemes which have a simple mapping from single octets to schemes which have a simple mapping from single octets to
single characters. Multi-octet coded character sets and single characters. Multi-octet coded character sets and
switching techniques make the situation more complex. For switching techniques make the situation more complex. For
example, some communities use the term "character encoding" example, some communities use the term "character encoding"
for what MIME calls a "character set", while using the phrase for what MIME calls a "character set", while using the phrase
"coded character set" to denote an abstract mapping from "coded character set" to denote an abstract mapping from
integers (not octets) to characters. integers (not octets) to characters.
skipping to change at page 14, line 44 skipping to change at page 14, line 44
ietf-token := <An extension token defined by a ietf-token := <An extension token defined by a
standards-track RFC and registered standards-track RFC and registered
with IANA.> with IANA.>
x-token := <The two characters "X-" or "x-" followed, with x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token> no intervening white space, by any token>
subtype := extension-token / iana-token subtype := extension-token / iana-token
iana-token := <A publicly-defined extension token. Tokens iana-token := <A publicly-defined extension token. Tokens
of this form should be registered with IANA of this form must be registered with IANA
as specified in RFC MIME-REG.> as specified in RFC MIME-REG.>
parameter := attribute "=" value parameter := attribute "=" value
attribute := token attribute := token
; Matching of attributes ; Matching of attributes
; is ALWAYS case-insensitive. ; is ALWAYS case-insensitive.
value := token / quoted-string value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials> or tspecials>
skipping to change at page 17, line 42 skipping to change at page 17, line 42
"quoted-printable" / "base64" / "quoted-printable" / "base64" /
ietf-token / x-token ietf-token / x-token
These values are not case sensitive -- Base64 and BASE64 and These values are not case sensitive -- Base64 and BASE64 and
bAsE64 are all equivalent. An encoding type of 7BIT requires bAsE64 are all equivalent. An encoding type of 7BIT requires
that the body is already in a 7bit mail-ready representation. that the body is already in a 7bit mail-ready representation.
This is the default value -- that is, "Content-Transfer- This is the default value -- that is, "Content-Transfer-
Encoding: 7BIT" is assumed if the Content-Transfer-Encoding Encoding: 7BIT" is assumed if the Content-Transfer-Encoding
header field is not present. header field is not present.
8.2. Content-Transfer-Encodings Sematics 8.2. Content-Transfer-Encodings Semantics
This single Content-Transfer-Encoding token actually provides This single Content-Transfer-Encoding token actually provides
two pieces of information. It specifies what sort of encoding two pieces of information. It specifies what sort of encoding
transformation the body was subjected to, and it specifies transformation the body was subjected to, and it specifies
what the domain of the result is. what the domain of the result is.
Three transformations are currently defined: identity, the Three transformations are currently defined: identity, the
"quoted-printable" encoding, and the "base64" encoding. The "quoted-printable" encoding, and the "base64" encoding. The
domains are "binary", "8bit" and "7bit". domains are "binary", "8bit" and "7bit".
skipping to change at page 21, line 47 skipping to change at page 21, line 47
couples the specification of an application protocol with a couples the specification of an application protocol with a
specific lower-level transport. This is not desirable since specific lower-level transport. This is not desirable since
the developers of a media type should not have to be aware of the developers of a media type should not have to be aware of
all the transports in use and what their limitations are. all the transports in use and what their limitations are.
8.5. Translating Encodings 8.5. Translating Encodings
The quoted-printable and base64 encodings are designed so that The quoted-printable and base64 encodings are designed so that
conversion between them is possible. The only issue that conversion between them is possible. The only issue that
arises in such a conversion is the handling of hard line arises in such a conversion is the handling of hard line
breaks. When converting from quoted-printable to base64 a breaks in quoted-printable encoding output. When converting
hard line break must be converted into a CRLF sequence. from quoted-printable to base64 a hard line break must be
converted into a CRLF sequence. Similarly, a CRLF sequence in
Similarly, a CRLF sequence in base64 data must be converted to base64 data must be converted to a quoted-printable hard line
a quoted-printable hard line break, but ONLY when converting break, but ONLY when converting text data.
text data.
8.6. Canonical Encoding Model 8.6. Canonical Encoding Model
There was some confusion, in the previous versions of this There was some confusion, in the previous versions of this
RFC, regarding the model for when email data was to be RFC, regarding the model for when email data was to be
converted to canonical form and encoded, and in particular how converted to canonical form and encoded, and in particular how
this process would affect the treatment of CRLFs, given that this process would affect the treatment of CRLFs, given that
the representation of newlines varies greatly from system to the representation of newlines varies greatly from system to
system, and the relationship between content-transfer- system, and the relationship between content-transfer-
encodings and character sets. A canonical model for encoding encodings and character sets. A canonical model for encoding
skipping to change at page 32, line 35 skipping to change at page 32, line 35
Email: ned@innosoft.com Email: ned@innosoft.com
Phone: +1 818 919 3600 Phone: +1 818 919 3600
Fax: +1 818 919 3614 Fax: +1 818 919 3614
MIME is a result of the work of the Internet Engineering Task MIME is a result of the work of the Internet Engineering Task
Force Working Group on Email Extensions. The chairman of that Force Working Group on Email Extensions. The chairman of that
group, Greg Vaudreuil, may be reached at: group, Greg Vaudreuil, may be reached at:
Gregory M. Vaudreuil Gregory M. Vaudreuil
Tigon Corporation Octel Network Services
17060 Dallas Parkway 17080 Dallas Parkway
Dallas Texas, 75248 Dallas, TX 75248-1905
USA
Email: greg.vaudreuil@ons.octel.com Email: Greg.Vaudreuil@Octel.Com
Phone: +1 214 733 2722
Appendix A -- Collected Grammar Appendix A -- Collected Grammar
This appendix contains the complete BNF grammar for all the This appendix contains the complete BNF grammar for all the
syntax specified by this document. syntax specified by this document.
By itself, however, this grammar is incomplete. It refers by By itself, however, this grammar is incomplete. It refers by
name to several syntax rules that are defined by RFC 822. name to several syntax rules that are defined by RFC 822.
Rather than reproduce those definitions here, and risk Rather than reproduce those definitions here, and risk
unintentional differences between the two, this document unintentional differences between the two, this document
simply refers the reader to RFC 822 for the remaining simply refers the reader to RFC 822 for the remaining
skipping to change at page 34, line 11 skipping to change at page 34, line 11
*( MIME-extension-field CRLF ) *( MIME-extension-field CRLF )
extension-token := ietf-token / x-token extension-token := ietf-token / x-token
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; Octet must be used for characters > 127, =, ; Octet must be used for characters > 127, =,
; SPACEs or TABs at the ends of lines, and is ; SPACEs or TABs at the ends of lines, and is
; recommended for any character not listed in ; recommended for any character not listed in
; RFC MIME-CONF as "mail-safe". ; RFC MIME-CONF as "mail-safe".
iana-token := <A publicly-defined extension token. Tokens iana-token := <A publicly-defined extension token. Tokens
of this form should be registered with IANA of this form must be registered with IANA
as specified in RFC MIME-REG.> as specified in RFC MIME-REG.>
ietf-token := <An extension token defined by a ietf-token := <An extension token defined by a
standards-track RFC and registered standards-track RFC and registered
with IANA.> with IANA.>
id := "Content-ID" ":" msg-id id := "Content-ID" ":" msg-id
mechanism := "7bit" / "8bit" / "binary" / mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" / "quoted-printable" / "base64" /
ietf-token / x-token ietf-token / x-token
 End of changes. 12 change blocks. 
32 lines changed or deleted 25 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/