< draft-ietf-822ext-mime-imb-04.txt   draft-ietf-822ext-mime-imb-05.txt >
Network Working Group Nathaniel Borenstein Network Working Group Nathaniel Borenstein
Internet Draft Ned Freed Internet Draft Ned Freed
<draft-ietf-822ext-mime-imb-04.txt> <draft-ietf-822ext-mime-imb-05.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
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 23 skipping to change at page 3, line 23
4.3 Message ............................................. 8 4.3 Message ............................................. 8
4.4 Entity .............................................. 8 4.4 Entity .............................................. 8
4.5 Body Part ........................................... 8 4.5 Body Part ........................................... 8
4.6 Body ................................................ 8 4.6 Body ................................................ 8
4.7 7bit Data ........................................... 9 4.7 7bit Data ........................................... 9
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 ............................. 13 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 ................. 18 8.2 Content-Transfer-Encodings Sematics ................. 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 ............................... 22 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 .................... 27 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
13 Security Considerations .............................. 31 13 Security Considerations .............................. 31
14 Authors' Addresses ................................... 32 14 Authors' Addresses ................................... 32
A Collected Grammar ..................................... 33 A Collected Grammar ..................................... 33
3. Introduction 3. Introduction
Since its publication in 1982, RFC 822 [RFC-822] has defined Since its publication in 1982, RFC 822 has defined the
the standard format of textual mail messages on the Internet. standard format of textual mail messages on the Internet. Its
Its success has been such that the RFC 822 format has been success has been such that the RFC 822 format has been
adopted, wholly or partially, well beyond the confines of the adopted, wholly or partially, well beyond the confines of the
Internet and the Internet SMTP transport defined by RFC 821 Internet and the Internet SMTP transport defined by RFC 821.
[RFC-821]. As the format has seen wider use, a number of As the format has seen wider use, a number of limitations have
limitations have proven increasingly restrictive for the user proven increasingly restrictive for the user community.
community.
RFC 822 was intended to specify a format for text messages. RFC 822 was intended to specify a format for text messages.
As such, non-text messages, such as multimedia messages that As such, non-text messages, such as multimedia messages that
might include audio or images, are simply not mentioned. Even might include audio or images, are simply not mentioned. Even
in the case of text, however, RFC 822 is inadequate for the in the case of text, however, RFC 822 is inadequate for the
needs of mail users whose languages require the use of needs of mail users whose languages require the use of
character sets richer than US-ASCII. Since RFC 822 does not character sets richer than US-ASCII. Since RFC 822 does not
specify mechanisms for mail containing audio, video, Asian specify mechanisms for mail containing audio, video, Asian
language text, or even text in most European languages, language text, or even text in most European languages,
additional specifications are needed. additional specifications are needed.
skipping to change at page 5, line 25 skipping to change at page 5, line 24
incompatibilities with the existing world of RFC 822 mail. In incompatibilities with the existing world of RFC 822 mail. In
particular, it describes: particular, it describes:
(1) A MIME-Version header field, which uses a version (1) A MIME-Version header field, which uses a version
number to declare a message to be conformant with this number to declare a message to be conformant with this
specification and allows mail processing agents to specification and allows mail processing agents to
distinguish between such messages and those generated distinguish between such messages and those generated
by older or non-conformant software, which are presumed by older or non-conformant software, which are presumed
to lack such a field. to lack such a field.
(2) A Content-Type header field, generalized from RFC 1049 (2) A Content-Type header field, generalized from RFC 1049,
[RFC-1049], which can be used to specify the media type which can be used to specify the media type and subtype
and subtype of data in the body of a message and to of data in the body of a message and to fully specify
fully specify the native representation (canonical the native representation (canonical form) of such
form) of such data. data.
(3) A Content-Transfer-Encoding header field, which can be (3) A Content-Transfer-Encoding header field, which can be
used to specify both the encoding transformation that used to specify both the encoding transformation that
was applied to the body and the domain of the result. was applied to the body and the domain of the result.
Encoding transformations other than the identity Encoding transformations other than the identity
transformation are usually applied to data in order to transformation are usually applied to data in order to
allow it to pass through mail transport mechanisms allow it to pass through mail transport mechanisms
which may have data or character set limitations. which may have data or character set limitations.
(4) Two additional header fields that can be used to (4) Two additional header fields that can be used to
skipping to change at page 6, line 20 skipping to change at page 6, line 20
HISTORICAL NOTE: Several of the mechanisms described in this HISTORICAL NOTE: Several of the mechanisms described in this
set of documents may seem somewhat strange or even baroque at set of documents may seem somewhat strange or even baroque at
first reading. It is important to note that compatibility first reading. It is important to note that compatibility
with existing standards AND robustness across existing with existing standards AND robustness across existing
practice were two of the highest priorities of the working practice were two of the highest priorities of the working
group that developed this set of documents. In particular, group that developed this set of documents. In particular,
compatibility was always favored over elegance. compatibility was always favored over elegance.
Please refer to the current edition of the "IAB Official Please refer to the current edition of the "IAB Official
Protocol Standards" for the standardization state and status Protocol Standards" for the standardization state and status
of this protocol. RFC 822 and RFC 1123 [RFC-1123] also of this protocol. RFC 822 and RFC 1123 also provide
provide essential background for MIME since no conforming essential background for MIME since no conforming
implementation of MIME can violate them. In addition, several implementation of MIME can violate them. In addition, several
other informational RFC documents will be of interest to the other informational RFC documents will be of interest to the
MIME implementor, in particular RFC 1344 [RFC-1344], RFC 1345 MIME implementor, in particular RFC 1344, RFC 1345, and RFC
[RFC-1345], and RFC 1524 [RFC-1524]. 1524.
4. Definitions, Conventions, and Generic BNF Grammar 4. Definitions, Conventions, and Generic BNF Grammar
Although the mechanisms specified in this set of documents are Although the mechanisms specified in this set of documents are
all described in prose, most are also described formally in all described in prose, most are also described formally in
the augmented BNF notation of RFC 822. Implementors will need the augmented BNF notation of RFC 822. Implementors will need
to be familiar with this notation in order to understand this to be familiar with this notation in order to understand this
specification, and are referred to RFC 822 for a complete specification, and are referred to RFC 822 for a complete
explanation of the augmented BNF notation. explanation of the augmented BNF notation.
skipping to change at page 10, line 27 skipping to change at page 10, line 27
fields fields
version CRLF version CRLF
; The ordering of the header ; The ordering of the header
; fields implied by this BNF ; fields implied by this BNF
; definition should be ignored. ; definition should be ignored.
MIME-part-headers := entity-headers MIME-part-headers := entity-headers
[ fields ] [ fields ]
; Any field not beginning with ; Any field not beginning with
; "content-" can have no defined ; "content-" can have no defined
; meaning and should be ignored. ; meaning and may be ignored.
; The ordering of the header ; The ordering of the header
; fields implied by this BNF ; fields implied by this BNF
; definition should be ignored. ; definition should be ignored.
The syntax of the various specific MIME header fields will be The syntax of the various specific MIME header fields will be
described in the following sections. described in the following sections.
6. MIME-Version Header Field 6. MIME-Version Header Field
Since RFC 822 was published in 1982, there has really been Since RFC 822 was published in 1982, there has really been
skipping to change at page 12, line 15 skipping to change at page 12, line 15
equivalent: equivalent:
MIME-Version: 1.0 MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x) MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0 MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0 MIME-Version: 1.(produced by MetaSend Vx.x)0
In the absence of a MIME-Version field, a receiving user agent In the absence of a MIME-Version field, a receiving mail user
(whether MIME compliant or not) may optionally choose to agent (whether conforming to MIME requirements or not) may
interpret the body of the message according to local optionally choose to interpret the body of the message
conventions. Many such conventions are currently in use and according to local conventions. Many such conventions are
it should be noted that in practice non-MIME messages can currently in use and it should be noted that in practice non-
contain just about anything. MIME messages can contain just about anything.
It is impossible to be certain that a non-MIME message is It is impossible to be certain that a non-MIME mail message is
actually plain text in the US-ASCII character set since it actually plain text in the US-ASCII character set since it
might well be a message that, using some set of nonstandard might well be a message that, using some set of nonstandard
local conventions that predate this document, includes text in local conventions that predate this document, includes text in
another character set or non-textual data presented in a another character set or non-textual data presented in a
manner that cannot be automatically recognized (e.g., a manner that cannot be automatically recognized (e.g., a
uuencoded compressed UNIX tar file). uuencoded compressed UNIX tar file).
MIME-compliant user agents are required, if they support any
such nonstandard conventions at all, to do so on received
messages only -- they must not send non-MIME messages
containing anything other than US-ASCII text.
In particular, the use of non-US-ASCII text in messages
without a MIME-Version field is strongly discouraged as it
impedes interoperability when sending messages between regions
with different localization conventions. MIME-compliant user
agents MUST include proper MIME labelling when sending
anything other than plain text in the US-ASCII character set.
In addition, non-MIME user agents should be upgraded if at all
possible to include appropriate MIME header information in the
messages they send even if nothing else in MIME is supported.
This upgrade will have little, if any, effect on non-MIME
recipients and will aid MIME in correctly displaying such
messages. It also provides a smooth transition path to
eventual adoption of other MIME capabilities.
7. Content-Type Header Field 7. Content-Type Header Field
The purpose of the Content-Type field is to describe the data The purpose of the Content-Type field is to describe the data
contained in the body fully enough that the receiving user contained in the body fully enough that the receiving user
agent can pick an appropriate agent or mechanism to present agent can pick an appropriate agent or mechanism to present
the data to the user, or otherwise deal with the data in an the data to the user, or otherwise deal with the data in an
appropriate manner. The value in this field is called a media appropriate manner. The value in this field is called a media
type. type.
HISTORICAL NOTE: The Content-Type header field was first HISTORICAL NOTE: The Content-Type header field was first
skipping to change at page 15, line 4 skipping to change at page 14, line 31
*(";" parameter) *(";" parameter)
; Matching of media type and subtype ; Matching of media type and subtype
; is ALWAYS case-insensitive. ; is ALWAYS case-insensitive.
type := discrete-type / composite-type type := discrete-type / composite-type
discrete-type := "text" / "image" / "audio" / "video" / discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token "application" / extension-token
composite-type := "message" / "multipart" / extension-token composite-type := "message" / "multipart" / extension-token
extension-token := ietf-token / x-token extension-token := ietf-token / x-token
ietf-token := <a publicly-defined extension token, ietf-token := <An extension token defined by a
initially registered with IANA and standards-track RFC and registered
subsequently standardized by the IETF> 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, iana-token := <A publicly-defined extension token. Tokens
registered with IANA, as specified in of this form should be registered with IANA
RFC MIME-REG [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>
tspecials := "(" / ")" / "<" / ">" / "@" / tspecials := "(" / ")" / "<" / ">" / "@" /
skipping to change at page 16, line 33 skipping to change at page 16, line 17
not conflict. That is, it would be undesirable to have two not conflict. That is, it would be undesirable to have two
different communities using "Content-Type: application/foobar" different communities using "Content-Type: application/foobar"
to mean two different things. The process of defining new to mean two different things. The process of defining new
media subtypes, then, is not intended to be a mechanism for media subtypes, then, is not intended to be a mechanism for
imposing restrictions, but simply a mechanism for publicizing imposing restrictions, but simply a mechanism for publicizing
their definition and usage. There are, therefore, two their definition and usage. There are, therefore, two
acceptable mechanisms for defining new media subtypes: acceptable mechanisms for defining new media subtypes:
(1) Private values (starting with "X-") may be defined (1) Private values (starting with "X-") may be defined
bilaterally between two cooperating agents without bilaterally between two cooperating agents without
outside registration or standardization. outside registration or standardization. Such values
cannot be registered or standardized.
(2) New standard values MUST be documented, registered (2) New standard values should be registered with IANA as
with, and approved by IANA, as described in RFC MIME- described in RFC MIME-REG.
REG [RFC-MIME-REG].
The second document in this set, RFC MIME-IMT, defines the The second document in this set, RFC MIME-IMT, defines the
initial set of media types for MIME. initial set of media types for MIME.
7.2. Content-Type Defaults 7.2. Content-Type Defaults
Default RFC 822 messages without a MIME Content-Type header Default RFC 822 messages without a MIME Content-Type header
are taken by this protocol to be plain text in the US-ASCII are taken by this protocol to be plain text in the US-ASCII
character set, which can be explicitly specified as: character set, which can be explicitly specified as:
skipping to change at page 19, line 8 skipping to change at page 18, line 39
Unlike media subtypes, a proliferation of Content-Transfer- Unlike media subtypes, a proliferation of Content-Transfer-
Encoding values is both undesirable and unnecessary. However, Encoding values is both undesirable and unnecessary. However,
establishing only a single transformation into the "7bit" establishing only a single transformation into the "7bit"
domain does not seem possible. There is a tradeoff between domain does not seem possible. There is a tradeoff between
the desire for a compact and efficient encoding of largely- the desire for a compact and efficient encoding of largely-
binary data and the desire for a readable encoding of data binary data and the desire for a readable encoding of data
that is mostly, but not entirely, 7bit. For this reason, at that is mostly, but not entirely, 7bit. For this reason, at
least two encoding mechanisms are necessary: a "readable" least two encoding mechanisms are necessary: a "readable"
encoding (quoted-printable) and a "dense" encoding (base64). encoding (quoted-printable) and a "dense" encoding (base64).
Mail transport for unencoded 8bit data is defined in RFC 1652 Mail transport for unencoded 8bit data is defined in RFC 1652.
[RFC-1652]. As of the initial publication of this document, As of the initial publication of this document, there are no
there are no standardized Internet mail transports for which standardized Internet mail transports for which it is
it is legitimate to include unencoded binary data in mail legitimate to include unencoded binary data in mail bodies.
bodies. Thus there are no circumstances in which the "binary" Thus there are no circumstances in which the "binary"
Content-Transfer-Encoding is actually valid in Internet mail. Content-Transfer-Encoding is actually valid in Internet mail.
However, in the event that binary mail transport becomes a However, in the event that binary mail transport becomes a
reality in Internet mail, or when this document is used in reality in Internet mail, or when this document is used in
conjunction with any other binary-capable transport mechanism, conjunction with any other binary-capable transport mechanism,
binary bodies should be labelled as such using this mechanism. binary bodies should be labelled as such using this mechanism.
NOTE: The five values defined for the Content-Transfer- NOTE: The five values defined for the Content-Transfer-
Encoding field imply nothing about the media type other than Encoding field imply nothing about the media type other than
the algorithm by which it was encoded or the transport system the algorithm by which it was encoded or the transport system
requirements if unencoded. requirements if unencoded.
skipping to change at page 22, line 18 skipping to change at page 22, line 4
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. When converting from quoted-printable to base64 a
hard line break must be converted into a CRLF sequence. hard line break must be converted into a CRLF sequence.
Similarly, a CRLF sequence in base64 data must be converted to Similarly, a CRLF sequence in base64 data must be converted to
a quoted-printable hard line break, but ONLY when converting a quoted-printable hard line 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 predecessors of this RFC, There was some confusion, in the previous versions of this
regarding the model for when email data was to be converted to RFC, regarding the model for when email data was to be
canonical form and encoded, and in particular how this process converted to canonical form and encoded, and in particular how
would affect the treatment of CRLFs, given that the this process would affect the treatment of CRLFs, given that
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
is presented in RFC MIME-CONF for this reason. is presented in RFC MIME-CONF for this reason.
8.7. Quoted-Printable Content-Transfer-Encoding 8.7. Quoted-Printable Content-Transfer-Encoding
The Quoted-Printable encoding is intended to represent data The Quoted-Printable encoding is intended to represent data
that largely consists of octets that correspond to printable that largely consists of octets that correspond to printable
characters in the US-ASCII character set. It encodes the data characters in the US-ASCII character set. It encodes the data
in such a way that the resulting octets are unlikely to be in such a way that the resulting octets are unlikely to be
skipping to change at page 27, line 13 skipping to change at page 26, line 39
structured header field. structured header field.
8.8. Base64 Content-Transfer-Encoding 8.8. Base64 Content-Transfer-Encoding
The Base64 Content-Transfer-Encoding is designed to represent The Base64 Content-Transfer-Encoding is designed to represent
arbitrary sequences of octets in a form that need not be arbitrary sequences of octets in a form that need not be
humanly readable. The encoding and decoding algorithms are humanly readable. The encoding and decoding algorithms are
simple, but the encoded data are consistently only about 33 simple, but the encoded data are consistently only about 33
percent larger than the unencoded data. This encoding is percent larger than the unencoded data. This encoding is
virtually identical to the one used in Privacy Enhanced Mail virtually identical to the one used in Privacy Enhanced Mail
(PEM) applications, as defined in RFC 1421 [RFC-1421]. (PEM) applications, as defined in RFC 1421.
A 65-character subset of US-ASCII is used, enabling 6 bits to A 65-character subset of US-ASCII is used, enabling 6 bits to
be represented per printable character. (The extra 65th be represented per printable character. (The extra 65th
character, "=", is used to signify a special processing character, "=", is used to signify a special processing
function.) function.)
NOTE: This subset has the important property that it is NOTE: This subset has the important property that it is
represented identically in all versions of ISO 646, including represented identically in all versions of ISO 646, including
US-ASCII, and all characters in the subset are also US-ASCII, and all characters in the subset are also
represented identically in all versions of EBCDIC. Other represented identically in all versions of EBCDIC. Other
skipping to change at page 30, line 25 skipping to change at page 30, line 25
The ability to associate some descriptive information with a The ability to associate some descriptive information with a
given body is often desirable. For example, it may be useful given body is often desirable. For example, it may be useful
to mark an "image" body as "a picture of the Space Shuttle to mark an "image" body as "a picture of the Space Shuttle
Endeavor." Such text may be placed in the Content-Description Endeavor." Such text may be placed in the Content-Description
header field. This header field is always optional. header field. This header field is always optional.
description := "Content-Description" ":" *text description := "Content-Description" ":" *text
The description is presumed to be given in the US-ASCII The description is presumed to be given in the US-ASCII
character set, although the mechanism specified in RFC MIME- character set, although the mechanism specified in RFC MIME-
HEADERS [RFC-MIME-HEADERS] may be used for non-US-ASCII HEADERS may be used for non-US-ASCII Content-Description
Content-Description values. values.
11. Additional MIME Header Fields 11. Additional MIME Header Fields
Future documents may elect to define additional MIME header Future documents may elect to define additional MIME header
fields for various purposes. Any new header field that fields for various purposes. Any new header field that
further describes the content of a message should begin with further describes the content of a message should begin with
the string "Content-" to allow such fields which appear in a the string "Content-" to allow such fields which appear in a
message header to be distinguished from ordinary RFC 822 message header to be distinguished from ordinary RFC 822
message header fields. message header fields.
skipping to change at page 34, line 10 skipping to change at page 34, line 10
[ description CRLF ] [ description CRLF ]
*( 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, iana-token := <A publicly-defined extension token. Tokens
registered with IANA, as specified in of this form should be registered with IANA
RFC MIME-REG> as specified in RFC MIME-REG.>
ietf-token := <a publicly-defined extension token, ietf-token := <An extension token defined by a
initially registered with IANA and standards-track RFC and registered
subsequently standardized by the IETF> 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
MIME-extension-field := <Any RFC 822 header field which MIME-extension-field := <Any RFC 822 header field which
begins with the string begins with the string
"Content-"> "Content-">
skipping to change at page 34, line 39 skipping to change at page 34, line 39
fields fields
version CRLF version CRLF
; The ordering of the header ; The ordering of the header
; fields implied by this BNF ; fields implied by this BNF
; definition should be ignored. ; definition should be ignored.
MIME-part-headers := entity-headers MIME-part-headers := entity-headers
[fields] [fields]
; Any field not beginning with ; Any field not beginning with
; "content-" can have no defined ; "content-" can have no defined
; meaning and should be ignored. ; meaning and may be ignored.
; The ordering of the header ; The ordering of the header
; fields implied by this BNF ; fields implied by this BNF
; definition should be ignored. ; definition should be ignored.
parameter := attribute "=" value parameter := attribute "=" value
ptext := hex-octet / safe-char ptext := hex-octet / safe-char
qp-line := *(qp-segment transport-padding CRLF) qp-line := *(qp-segment transport-padding CRLF)
qp-part transport-padding qp-part transport-padding
 End of changes. 29 change blocks. 
81 lines changed or deleted 61 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/