As per Relevance of the word internet, we have this rfc below:
Network Working Group N.
Request for Comments: 2049
Obsoletes: 1521, 1522, 1590 N.
Category: Standards Track First
November 1996
Multipurpose Internet Mail
(MIME) Part Five
Conformance Criteria and
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
STD 11, RFC 822, defines a message representation protocol
considerable detail about US-ASCII message headers, and leaves
message content, or message body, as flat US-ASCII text. This set
documents, collectively called the Multipurpose Internet
Extensions, or MIME, redefines the format of messages to allow
(1) textual message bodies in character sets other
US-ASCII
(2) an extensible set of different formats for non-
message bodies
(3) multi-part message bodies,
(4) textual header information in character sets other
US-ASCII
These documents are based on earlier work documented in RFC 934,
11, and RFC 1049, but extends and revises them. Because RFC 822
so little about message bodies, these documents are
orthogonal to (rather than a revision of) RFC 822.
The initial document in this set, RFC 2045, specifies the
headers used to describe the structure of MIME messages. The
document defines the general structure of the MIME media
system and defines an initial set of media types. The
document, RFC 2047, describes extensions to RFC 822 to allow non-US
Freed & Borenstein Standards Track [Page 1]
RFC 2049 MIME Conformance November 1996
ASCII text data in Internet mail header fields. The fourth document
RFC 2048, specifies various IANA registration procedures for MIME
related facilities. This fifth and final document describes
conformance criteria as well as providing some illustrative
of MIME message formats, acknowledgements, and the bibliography
These documents are revisions of RFCs 1521, 1522, and 1590,
themselves were revisions of RFCs 1341 and 1342. Appendix B of
document describes differences and changes from previous versions
Table of
1. Introduction .......................................... 2
2. MIME Conformance ...................................... 2
3. Guidelines for Sending Email Data ..................... 6
4. Canonical Encoding Model .............................. 9
5. Summary ............................................... 12
6. Security Considerations ............................... 12
7. Authors' Addresses .................................... 12
8. Acknowledgements ...................................... 13
A. A Complex Multipart Example ........................... 15
B. Changes from RFC 1521, 1522, and 1590 ................. 16
C. References ............................................ 20
1.
The first and second documents in this set define MIME header
and the initial set of MIME media types. The third
describes extensions to RFC822 formats to allow for character
other than US-ASCII. This document describes what portions of
must be supported by a conformant MIME implementation. It
describes various pitfalls of contemporary messaging systems as
as the canonical encoding model MIME is based on
2. MIME
The mechanisms described in these documents are open-ended. It
definitely not expected that all implementations will support
available media types, nor that they will all share the
extensions. In order to promote interoperability, however, it
useful to define the concept of "MIME-conformance" to define
certain level of implementation that allows the useful
of messages with content that differs from US-ASCII text. In
section, we specify the requirements for such conformance
Freed & Borenstein Standards Track [Page 2]
RFC 2049 MIME Conformance November 1996
A mail user agent that is MIME-conformant MUST
(1) Always generate a "MIME-Version: 1.0" header field
any message it creates
(2) Recognize the Content-Transfer-Encoding header
and decode all received data encoded by either quoted
printable or base64 implementations. The
transformations 7bit, 8bit, and binary must also
recognized
Any non-7bit data that is sent without encoding must
properly labelled with a content-transfer-encoding
8bit or binary, as appropriate. If the
transport does not support 8bit or binary (as
[RFC-821] does not), the sender is required to
encode and label data using an appropriate Content
Transfer-Encoding such as quoted-printable or base64.
(3) Must treat any unrecognized Content-Transfer-
as if it had a Content-Type of "application/octet
stream", regardless of whether or not the
Content-Type is recognized
(4) Recognize and interpret the Content-Type header field
and avoid showing users raw data with a Content-
field other than text. Implementations must be
to send at least text/plain messages, with
character set specified with the charset parameter
it is not US-ASCII
(5) Ignore any content type parameters whose names they
not recognize
(6) Explicitly handle the following media type values,
at least the following extents
Text
-- Recognize and display "text" mail with
character set "US-ASCII."
-- Recognize other character sets at least to
extent of being able to inform the user about
character set the message uses
Freed & Borenstein Standards Track [Page 3]
RFC 2049 MIME Conformance November 1996
-- Recognize the "ISO-8859-*" character sets to
extent of being able to display those characters
are common to ISO-8859-* and US-ASCII, namely
characters represented by octet values 1-127.
-- For unrecognized subtypes in a known
set, show or offer to show the user the "raw"
of the data after conversion of the content
canonical form to local form
-- Treat material in an unknown character set as
it were "application/octet-stream".
Image, audio, and video
-- At a minumum provide facilities to treat
unrecognized subtypes as if they
"application/octet-stream".
Application
-- Offer the ability to remove either of the quoted
printable or base64 encodings defined in
document if they were used and put the
information in a user file
Multipart
-- Recognize the mixed subtype. Display all
information on the message level and the body
header level and then display or offer to
each of the body parts individually
-- Recognize the "alternative" subtype, and
showing the user redundant parts
multipart/alternative mail
-- Recognize the "multipart/digest" subtype
specifically using "message/rfc822" rather
"text/plain" as the default media type for body
inside "multipart/digest" entities
-- Treat any unrecognized subtypes as if they
"mixed".
Freed & Borenstein Standards Track [Page 4]
RFC 2049 MIME Conformance November 1996
Message
-- Recognize and display at least the RFC822
encapsulation (message/rfc822) in such a way as
preserve any recursive structure, that is,
or offering to display the encapsulated data
accordance with its media type
-- Treat any unrecognized subtypes as if they
"application/octet-stream".
(7) Upon encountering any unrecognized Content-Type field
an implementation must treat it as if it had a
type of "application/octet-stream" with no
sub-arguments. How such data are handled is up to
implementation, but likely options for handling
unrecognized data include offering the user to write
into a file (decoded from its mail transport format)
offering the user to name a program to which
decoded data should be passed as input
(8) Conformant user agents are required, if they
non-standard support for non-MIME messages
character sets other than US-ASCII, to do so
received messages only. Conforming user agents must
send non-MIME messages containing anything other
US-ASCII text
In particular, the use of non-US-ASCII text in
messages without a MIME-Version field is
discouraged as it impedes interoperability when
messages between regions with different
conventions. Conforming user agents MUST include
MIME labelling when sending anything other than
text in the US-ASCII character set
In addition, non-MIME user agents should be upgraded
at all possible to include appropriate MIME
information in the messages they send even if
else in MIME is supported. This upgrade will
little, if any, effect on non-MIME recipients and
aid MIME in correctly displaying such messages.
also provides a smooth transition path to
adoption of other MIME capabilities
(9) Conforming user agents must ensure that any string
non-white-space printable US-ASCII characters within
"*text" or "*ctext" that begins with "=?" and ends
Freed & Borenstein Standards Track [Page 5]
RFC 2049 MIME Conformance November 1996
"?=" be a valid encoded-word. ("begins" means: At
start of the field-body or immediately
linear-white-space; "ends" means: At the end of
field-body or immediately preceding linear-white
space.) In addition, any "word" within a "phrase"
begins with "=?" and ends with "?=" must be a
encoded-word
(10) Conforming user agents must be able to
encoded-words from "text", "ctext", or "word"s
according to the rules in section 4, anytime
appear in appropriate places in message headers.
must support both the "B" and "Q" encodings for
character set which it supports. The program must
able to display the unencoded text if the character
is "US-ASCII". For the ISO-8859-* character sets,
mail reading program must at least be able to
the characters which are also in the US-ASCII set
A user agent that meets the above conditions is said to be MIME
conformant. The meaning of this phrase is that it is assumed to
"safe" to send virtually any kind of properly-marked data to users
such mail systems, because such systems will at least be able
treat the data as undifferentiated binary, and will not simply
it onto the screen of unsuspecting users
There is another sense in which it is always "safe" to send data in
format that is MIME-conformant, which is that such data will
break or be broken by any known systems that are conformant with
821 and RFC 822. User agents that are MIME-conformant have
additional guarantee that the user will not be shown data that
never intended to be viewed as text
3. Guidelines for Sending Email
Internet email is not a perfect, homogeneous system. Mail may
corrupted at several stages in its travel to a final destination
Specifically, email sent throughout the Internet may travel
many networking technologies. Many networking and mail
do not support the full functionality possible in the SMTP
environment. Mail traversing these systems is likely to be
in order that it can be transported
There exist many widely-deployed non-conformant MTAs in the Internet
These MTAs, speaking the SMTP protocol, alter messages on the fly
take advantage of the internal data structure of the hosts they
implemented on, or are just plain broken
Freed & Borenstein Standards Track [Page 6]
RFC 2049 MIME Conformance November 1996
The following guidelines may be useful to anyone devising a
format (media type) that is supposed to survive the widest range
networking technologies and known broken MTAs unscathed. Note
anything encoded in the base64 encoding will satisfy these rules,
that some well-known mechanisms, notably the UNIX uuencode facility
will not. Note also that anything encoded in the Quoted-
encoding will survive most gateways intact, but possibly not
gateways to systems that use the EBCDIC character set
(1) Under some circumstances the encoding used for data
change as part of normal gateway or user
operation. In particular, conversion from base64
quoted-printable and vice versa may be necessary.
may result in the confusion of CRLF sequences with
breaks in text bodies. As such, the persistence
CRLF as something other than a line break must not
relied on
(2) Many systems may elect to represent and store text
using local newline conventions. Local
conventions may not match the RFC822 CRLF convention --
systems are known that use plain CR, plain LF, CRLF,
counted records. The result is that isolated CR and
characters are not well tolerated in general; they
be lost or converted to delimiters on some systems,
hence must not be relied on
(3) The transmission of NULs (US-ASCII value 0)
problematic in Internet mail. (This is largely
result of NULs being used as a termination character
many of the standard runtime library routines in the
programming language.) The practice of using NULs
termination characters is so entrenched now
messages should not rely on them being preserved
(4) TAB (HT) characters may be misinterpreted or may
automatically converted to variable numbers of spaces
This is unavoidable in some environments, notably
not based on the US-ASCII character set.
conversion is STRONGLY DISCOURAGED, but it may occur
and mail formats must not rely on the persistence
TAB (HT) characters
(5) Lines longer than 76 characters may be wrapped
truncated in some environments. Line wrapping or
truncation imposed by mail transports is
DISCOURAGED, but unavoidable in some cases
Applications which require long lines must
Freed & Borenstein Standards Track [Page 7]
RFC 2049 MIME Conformance November 1996
differentiate between soft and hard line breaks. (
simple way to do this is to use the quoted-
encoding.)
(6) Trailing "white space" characters (SPACE, TAB (HT))
a line may be discarded by some transport agents,
other transport agents may pad lines with
characters so that all lines in a mail file are
equal length. The persistence of trailing white space
therefore, must not be relied on
(7) Many mail domains use variations on the US-
character set, or use character sets such as
which contain most but not all of the US-
characters. The correct translation of characters
in the "invariant" set cannot be depended on
character converting gateways. For example,
situation is a problem when sending
information across BITNET, an EBCDIC system.
problems can occur without crossing a gateway,
many Internet hosts use character sets other than US
ASCII internally. The definition of Printable
in X.400 adds further restrictions in certain
cases. In particular, the only characters that
known to be consistent across all gateways are the 73
characters that correspond to the upper and lower
letters A-Z and a-z, the 10 digits 0-9, and
following eleven special characters
"'" (US-ASCII decimal value 39)
"(" (US-ASCII decimal value 40)
")" (US-ASCII decimal value 41)
"+" (US-ASCII decimal value 43)
"," (US-ASCII decimal value 44)
"-" (US-ASCII decimal value 45)
"." (US-ASCII decimal value 46)
"/" (US-ASCII decimal value 47)
":" (US-ASCII decimal value 58)
"=" (US-ASCII decimal value 61)
"?" (US-ASCII decimal value 63)
A maximally portable mail representation will
itself to relatively short lines of text in which
only meaningful characters are taken from this set
73 characters. The base64 encoding follows this rule
(8) Some mail transport agents will corrupt data
includes certain literal strings. In particular,
Freed & Borenstein Standards Track [Page 8]
RFC 2049 MIME Conformance November 1996
period (".") alone on a line is known to be
by some (incorrect) SMTP implementations, and a
that starts with the five characters "From " (the
character is a SPACE) are commonly corrupted as well
A careful composition agent can prevent
corruptions by encoding the data (e.g., in the quoted
printable encoding using "=46rom " in place of "From "
at the start of a line, and "=2E" in place of "."
on a line).
Please note that the above list is NOT a list of
practices for MTAs. RFC 821 MTAs are prohibited from altering
character of white space or wrapping long lines. These BAD
invalid practices are known to occur on established networks,
implementations should be robust in dealing with the bad effects
can cause
4. Canonical Encoding
There was some confusion, in earlier versions of these documents
regarding the model for when email data was to be converted
canonical form and encoded, and in particular how this process
affect the treatment of CRLFs, given that the representation
newlines varies greatly from system to system. For this reason,
canonical model for encoding is presented below
The process of composing a MIME entity can be modeled as being
in a number of steps. Note that these steps are roughly similar
those steps used in PEM [RFC-1421] and are performed for
"innermost level" body
(1) Creation of local form
The body to be transmitted is created in the system'
native format. The native character set is used and
where appropriate, local end of line conventions
used as well. The body may be a UNIX-style text file
or a Sun raster image, or a VMS indexed file, or
data in a system-dependent format stored only
memory, or anything else that corresponds to the
model for the representation of some form
information. Fundamentally, the data is created in
"native" form that corresponds to the type specified
the media type
Freed & Borenstein Standards Track [Page 9]
RFC 2049 MIME Conformance November 1996
(2) Conversion to canonical form
The entire body, including "out-of-band"
such as record lengths and possibly file
information, is converted to a universal
form. The specific media type of the body as well
its associated attributes dictate the nature of
canonical form that is used. Conversion to the
canonical form may involve character set conversion
transformation of audio data, compression, or
other operations specific to the various media types
If character set conversion is involved, however,
must be taken to understand the semantics of the
type, which may have strong implications for
character set conversion, e.g. with regard
syntactically meaningful characters in a text
other than "plain".
For example, in the case of text/plain data, the
must be converted to a supported character set
lines must be delimited with CRLF delimiters
accordance with RFC 822. Note that the restriction
line lengths implied by RFC 822 is eliminated if
next step employs either quoted-printable or base64
encoding
(3) Apply transfer encoding
A Content-Transfer-Encoding appropriate for this
is applied. Note that there is no fixed
between the media type and the transfer encoding.
particular, it may be appropriate to base the choice
base64 or quoted-printable on character
counts which are specific to a given instance of
body
(4) Insertion into entity
The encoded body is inserted into a MIME entity
appropriate headers. The entity is then inserted
the body of a higher-level entity (message
multipart) as needed
Conversion from entity form to local form is accomplished
reversing these steps. Note that reversal of these steps may
differing results since there is no guarantee that the original
final local forms are the same
Freed & Borenstein Standards Track [Page 10]
RFC 2049 MIME Conformance November 1996
It is vital to note that these steps are only a model; they
specifically NOT a blueprint for how an actual system would be built
In particular, the model fails to account for two common designs
(1) In many cases the conversion to a canonical form
to encoding will be subsumed into the encoder itself
which understands local formats directly. For example
the local newline convention for text bodies might
carried through to the encoder itself along
knowledge of what that format is
(2) The output of the encoders may have to pass through
or more additional steps prior to being transmitted
a message. As such, the output of the encoder may
be conformant with the formats specified by RFC 822.
In particular, once again it may be appropriate for
converter's output to be expressed using local
conventions rather than using the standard RFC 822
delimiters
Other implementation variations are conceivable as well. The
aspect of this discussion is that, in spite of any optimizations
collapsings of required steps, or insertion of additional processing
the resulting messages must be consistent with those produced by
model described here. For example, a message with the
header fields
Content-type: text/foo; charset=
Content-Transfer-Encoding: base64
must be first represented in the text/foo form, then (if necessary
represented in the "bar" character set, and finally transformed
the base64 algorithm into a mail-safe form
NOTE: Some confusion has been caused by systems that
messages in a format which uses local newline conventions
differ from the RFC822 CRLF convention. It is important to note
these formats are not canonical RFC822/MIME. These formats
instead *encodings* of RFC822, where CRLF sequences in the
representation of the message are encoded as the local
convention. Note that formats which encode CRLF sequences as,
example, LF are not capable of representing MIME messages
binary data which contains LF octets not part of CRLF line
sequences
Freed & Borenstein Standards Track [Page 11]
RFC 2049 MIME Conformance November 1996
5.
This document defines what is meant by MIME Conformance. It
details various problems known to exist in the Internet email
and how to use MIME to overcome them. Finally, it describes MIME'
canonical encoding model
6. Security
Security issues are discussed in the second document in this set,
2046.
7. Authors'
For more information, the authors of this document are best
via Internet mail
Ned
Innosoft International, Inc
1050 East Garvey Avenue
West Covina, CA 91790
Phone: +1 818 919 3600
Fax: +1 818 919 3614
EMail: ned@innosoft.
Nathaniel S.
First Virtual
25 Washington
Morristown, NJ 07960
Phone: +1 201 540 8967
Fax: +1 201 993 3032
EMail: nsb@nsb.fv.
MIME is a result of the work of the Internet Engineering Task
Working Group on RFC 822 Extensions. The chairman of that group
Greg Vaudreuil, may be reached at
Gregory M.
Octel Network
17080 Dallas
Dallas, TX 75248-1905
EMail: Greg.Vaudreuil@Octel.
Freed & Borenstein Standards Track [Page 12]
RFC 2049 MIME Conformance November 1996
8.
This document is the result of the collective effort of a
number of people, at several IETF meetings, on the IETF-SMTP
IETF-822 mailing lists, and elsewhere. Although any
seems doomed to suffer from egregious omissions, the following
among the many contributors to this effort
Harald Tveit Alvestrand Marc
Randall Atkinson Bob
Philippe Brandon Brian
Kevin Carosso Uhhyung
Peter Clitherow Dave Collier-
Cristian Constantinof John
Mark Crispin Dave
Stephen Crocker Terry
Walt Daniels Jim
Frank Dawson Axel
Hitoshi Doi Kevin
Steve Dorner Keith
Chris Eich Dana S.
Johnny Eriksson Craig
Patrik Faltstrom Erik E.
Roger Fajman Alain
Martin Forssen James M.
Stephen Gildea Philip
Thomas Gordon Keld
Terry Gray Phill
James Hamilton David
Mark Horton Bruce
Bill Janssen Olle
Risto Kankkunen Phil
Alan Katz Tim
Neil Katin Steve
Kyuho Kim Anders
John Klensin Valdis
Jim Knowles Stev
Bob Kummerfeld Pekka
Stellan Lagerstrom Vincent
Timo Lehtinen Donald
Warner Losh Carlyn
Laurence Lundblade Charles
John R. MacMillan Larry
Rick McGowan Michael J.
Leo Mclaughlin Goli Montaser-
Tom Moore John Gardiner
Erik Naggum Mark
Chris Newman John
Freed & Borenstein Standards Track [Page 13]
RFC 2049 MIME Conformance November 1996
Mats Ohrman Julian
Michael Patton David J.
Erik van der Poel Blake C.
Christer Romson Luc
Marshall T. Rose Jonathan
Guido van Rossum Jan
Harri Salminen Michael
Yutaka Sato Markku
Richard Alan Schafer Masahiro
Mark Sherman Bob
Peter Speck Henry
Einar Stefferud Michael
Klaus Steinberger Peter
James Thompson Steve
Stuart Vance Peter
Greg Vaudreuil Ed
Larry W. Virden Ryan
Rhys Weatherly Jay
Dave Wecker Wally
Sven-Ove Westberg Brian
John Wobus Glenn
Rayan Zachariassen David
The authors apologize for any omissions from this list, which
certainly unintentional
Freed & Borenstein Standards Track [Page 14]
RFC 2049 MIME Conformance November 1996
Appendix A -- A Complex Multipart
What follows is the outline of a complex multipart message.
message contains five parts that are to be displayed serially:
introductory plain text objects, an embedded multipart message,
text/enriched object, and a closing encapsulated text message in
non-ASCII character set. The embedded multipart message
contains two objects to be displayed in parallel, a picture and
audio fragment
MIME-Version: 1.0
From: Nathaniel Borenstein
To: Ned Freed
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT
Subject: A multipart
Content-Type: multipart/mixed
boundary=unique-boundary-1
This is the preamble area of a multipart message
Mail readers that understand multipart
should ignore this preamble
If you are reading this text, you might want
consider changing to a mail reader that
how to properly display multipart messages
--unique-boundary-1
... Some text appears here ...
[Note that the blank between the boundary and the
of the text in this part means no header fields
given and this is text in the US-ASCII character set
It could have been done with explicit typing as in
next part.]
--unique-boundary-1
Content-type: text/plain; charset=US-
This could have been part of the previous part,
illustrates explicit versus implicit typing of
parts
--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2
--unique-boundary-2
Content-Type: audio/
Freed & Borenstein Standards Track [Page 15]
RFC 2049 MIME Conformance November 1996
Content-Transfer-Encoding: base64
... base64-encoded 8000 Hz single-
mu-law-format audio data goes here ...
--unique-boundary-2
Content-Type: image/
Content-Transfer-Encoding: base64
... base64-encoded image data goes here ...
--unique-boundary-2--
--unique-boundary-1
Content-type: text/
This is enriched.
as defined in RFC 1896
Isn't
cool?
--unique-boundary-1
Content-Type: message/rfc822
From: (mailbox in US-ASCII
To: (address in US-ASCII
Subject: (subject in US-ASCII
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-
... Additional text in ISO-8859-1 goes here ...
--unique-boundary-1--
Appendix B -- Changes from RFC 1521, 1522, and 1590
These documents are a revision of RFC 1521, 1522, and 1590. For
convenience of those familiar with the earlier documents, the
from those documents are summarized in this appendix. For
history, note that Appendix H in RFC 1521 specified how that
differed from its predecessor, RFC 1341.
(1) This document has been completely reformatted and
into multiple documents. This was done to improve
quality of the plain text version of this document
which is required to be the reference copy
Freed & Borenstein Standards Track [Page 16]
RFC 2049 MIME Conformance November 1996
(2) BNF describing the overall structure of MIME
headers has been added. This is a documentation
only -- the underlying syntax has not changed in
way
(3) The specific BNF for the seven media types in MIME
been removed. This BNF was incorrect, incomplete,
inconsistent with the type-indendependent BNF.
since the type-independent BNF already fully
the syntax of the various MIME headers, the type
specific BNF was, in the final analysis,
unnecessary and caused more problems than it solved
(4) The more specific "US-ASCII" character set name
replaced the use of the informal term ASCII in
parts of these documents
(5) The informal concept of a primary subtype has
removed
(6) The term "object" was being used inconsistently.
definition of this term has been clarified, along
the related terms "body", "body part", and "entity",
and usage has been corrected where appropriate
(7) The BNF for the multipart media type has
rearranged to make it clear that the CRLF
the boundary marker is actually part of the
itself rather than the preceeding body part
(8) The prose and BNF describing the multipart media
have been changed to make it clear that the body
within a multipart object MUST NOT contain any
beginning with the boundary parameter string
(9) In the rules on reassembling "message/partial"
entities, "Subject" is added to the list of headers
take from the inner message, and the example
modified to clarify this point
(10) "Message/partial" fragmenters are restricted
splitting MIME objects only at line boundaries
(11) In the discussion of the application/postscript type
an additional paragraph has been added warning
possible interoperability problems caused by
of binary data inside a PostScript MIME entity
Freed & Borenstein Standards Track [Page 17]
RFC 2049 MIME Conformance November 1996
(12) Added a clarifying note to the basic syntax rules
the Content-Type header field to make it clear that
following two forms
Content-type: text/plain; charset=us-ascii (comment
Content-type: text/plain; charset="us-ascii
are completely equivalent
(13) The following sentence has been removed from
discussion of the MIME-Version header: "However
conformant software is encouraged to check the
number and at least warn the user if an
MIME-version is encountered."
(14) A typo was fixed that said "application/external-body
instead of "message/external-body".
(15) The definition of a character set has been
to make the requirements clearer
(16) The definition of the "image/gif" media type has
moved to a separate document. This change was
because of potential conflicts with IETF
governing the standardization of patented technology
(17) The definitions of "7bit" and "8bit" have
tightened so that use of bare CR, LF can only be
as end-of-line sequences. The document also no
requires that NUL characters be preserved, which
MIME into alignment with real-world implementations
(18) The definition of canonical text in MIME has
tightened so that line breaks must be represented by
CRLF sequence. CR and LF characters are not
outside of this usage. The definition of quoted
printable encoding has been altered accordingly
(19) The definition of the quoted-printable encoding
includes a number of suggestions for how quoted
printable encoders might best handle improperly
material
(20) Prose was added to clarify the use of the "7bit",
"8bit", and "binary" transfer-encodings on multipart
message entities encapsulating "8bit" or "binary" data
Freed & Borenstein Standards Track [Page 18]
RFC 2049 MIME Conformance November 1996
(21) In the section on MIME Conformance, "multipart/digest
support was added to the list of requirements
minimal MIME conformance. Also, the requirement
"message/rfc822" support were strengthened to
the importance of recognizing recursive structure
(22) The various restrictions on subtypes of "message"
now specified entirely on a subtype by subtype basis
(23) The definition of "message/rfc822" was changed
indicate that at least one of the "From", "Subject",
"Date" headers must be present
(24) The required handling of unrecognized subtypes
"application/octet-stream" has been made more
in both the type definitions sections and
conformance guidelines
(25) Examples using text/richtext were changed
text/enriched
(26) The BNF definition of subtype has been changed to
it clear that either an IANA registered subtype or
nonstandard "X-" subtype must be used in a Content-
header field
(27) MIME media types that are simply registered for use
those that are standardized by the IETF are
distinguished in the MIME BNF
(28) All of the various MIME registration procedures
been extensively revised. IANA registration
for character sets have been moved to a
document that is no included in this set of documents
(29) The use of escape and shift mechanisms in the US-
and ISO-8859-X character sets these documents
have been clarified: Such mechanisms should never
used in conjunction with these character sets and
effect if they are used is undefined
(30) The definition of the AFS access-type
message/external-body has been removed
(31) The handling of the combination
multipart/alternative and message/external-body is
specifically addressed
Freed & Borenstein Standards Track [Page 19]
RFC 2049 MIME Conformance November 1996
(32) Security issues specific to message/external-body
now discussed in some detail
Appendix C --
[ATK
Borenstein, Nathaniel S., Multimedia
Development with the Andrew Toolkit, Prentice-Hall, 1990.
[ISO-2022]
International Standard -- Information Processing --
Character Code Structure and Extension Techniques
ISO/IEC 2022:1994, 4th ed
[ISO-8859]
International Standard -- Information Processing -- 8-
Single-Byte Coded Graphic Character
- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed
- Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed
- Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed
- Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed
- Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1
ed
- Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed
- Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed
- Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed
- Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1
ed
International Standard -- Information Technology -- 8-
Single-Byte Coded Graphic Character
- Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992,
1st ed
[ISO-646]
International Standard -- Information Technology --
7-bit Coded Character Set for Information Interchange
ISO 646:1991, 3rd ed..
[JPEG
JPEG Draft Standard ISO 10918-1 CD
[MPEG
Video Coding Draft Standard ISO 11172 CD,
IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May
1991.
Freed & Borenstein Standards Track [Page 20]
RFC 2049 MIME Conformance November 1996
[PCM
CCITT, Fascicle III.4 - Recommendation G.711, "Pulse
Modulation (PCM) of Voice Frequencies", Geneva, 1972.
[POSTSCRIPT
Adobe Systems, Inc., PostScript Language
Manual, Addison-Wesley, 1985.
[POSTSCRIPT2]
Adobe Systems, Inc., PostScript Language
Manual, Addison-Wesley, Second Ed., 1990.
[RFC-783]
Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783,
MIT, June 1981.
[RFC-821]
Postel, J.B., "Simple Mail Transfer Protocol", STD 10,
RFC 821, USC/Information Sciences Institute, August 1982.
[RFC-822]
Crocker, D., "Standard for the Format of ARPA
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[RFC-934]
Rose, M. and E. Stefferud, "Proposed Standard for
Encapsulation", RFC 934, Delaware and NMA, January 1985.
[RFC-959]
Postel, J. and J. Reynolds, "File Transfer Protocol",
9, RFC 959, USC/Information Sciences Institute,
1985.
[RFC-1049]
Sirbu, M., "Content-Type Header Field for
Messages", RFC 1049, CMU, March 1988.
[RFC-1154]
Robinson, D., and R. Ullmann, "Encoding Header Field
Internet Messages", RFC 1154, Prime Computer, Inc.,
1990.
[RFC-1341]
Borenstein, N., and N. Freed, "MIME (
Internet Mail Extensions): Mechanisms for Specifying
Describing the Format of Internet Message Bodies",
1341, Bellcore, Innosoft, June 1992.
Freed & Borenstein Standards Track [Page 21]
RFC 2049 MIME Conformance November 1996
[RFC-1342]
Moore, K., "Representation of Non-Ascii Text in
Message Headers", RFC 1342, University of Tennessee,
1992.
[RFC-1344]
Borenstein, N., "Implications of MIME for Internet
Gateways", RFC 1344, Bellcore, June 1992.
[RFC-1345]
Simonsen, K., "Character Mnemonics & Character Sets",
1345, Rationel Almen Planlaegning, June 1992.
[RFC-1421]
Linn, J., "Privacy Enhancement for Internet
Mail: Part I -- Message Encryption and
Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG
February 1993.
[RFC-1422]
Kent, S., "Privacy Enhancement for Internet
Mail: Part II -- Certificate-Based Key Management",
1422, IAB IRTF PSRG, IETF PEM WG, February 1993.
[RFC-1423]
Balenson, D., "Privacy Enhancement for
Electronic Mail: Part III -- Algorithms, Modes,
Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993.
[RFC-1424]
Kaliski, B., "Privacy Enhancement for Internet
Mail: Part IV -- Key Certification and
Services", IAB IRTF PSRG, IETF PEM WG, February 1993.
[RFC-1521]
Borenstein, N., and Freed, N., "MIME (
Internet Mail Extensions): Mechanisms for Specifying
Describing the Format of Internet Message Bodies",
1521, Bellcore, Innosoft, September, 1993.
[RFC-1522]
Moore, K., "Representation of Non-ASCII Text in
Message Headers", RFC 1522, University of Tennessee
September 1993.
Freed & Borenstein Standards Track [Page 22]
RFC 2049 MIME Conformance November 1996
[RFC-1524]
Borenstein, N., "A User Agent Configuration Mechanism
Multimedia Mail Format Information", RFC 1524, Bellcore
September 1993.
[RFC-1543]
Postel, J., "Instructions to RFC Authors", RFC 1543,
USC/Information Sciences Institute, October 1993.
[RFC-1556]
Nussbacher, H., "Handling of Bi-directional Texts
MIME", RFC 1556, Israeli Inter-University
Center, December 1993.
[RFC-1590]
Postel, J., "Media Type Registration Procedure",
1590, USC/Information Sciences Institute, March 1994.
[RFC-1602]
Internet Architecture Board, Internet
Steering Group, Huitema, C., Gross, P., "The
Standards Process -- Revision 2", March 1994.
[RFC-1652]
Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M.,
Stefferud, E., and Crocker, D., "SMTP Service
for 8bit-MIME transport", RFC 1652, United
University, Innosoft, Dover Beach Consulting, Inc.,
Network Management Associates, Inc., The Branch Office
March 1994.
[RFC-1700]
Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, USC/Information Sciences Institute,
1994.
[RFC-1741]
Faltstrom, P., Crocker, D., and Fair, E., "MIME
Type for BinHex Encoded Files", December 1994.
[RFC-1896]
Resnick, P., and A. Walker, "The text/enriched
Content-type", RFC 1896, February, 1996.
Freed & Borenstein Standards Track [Page 23]
RFC 2049 MIME Conformance November 1996
[RFC-2045]
Freed, N., and and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet
Bodies", RFC 2045, Innosoft, First Virtual Holdings
November 1996.
[RFC-2046]
Freed, N., and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part Two: Media Types", RFC 2046,
Innosoft, First Virtual Holdings, November 1996.
[RFC-2047]
Moore, K., "Multipurpose Internet Mail Extensions (MIME
Part Three: Representation of Non-ASCII Text in
Message Headers", RFC 2047, University
Tennessee, November 1996.
[RFC-2048]
Freed, N., Klensin, J., and J. Postel, "
Internet Mail Extensions (MIME) Part Four:
Registration Procedures", RFC 2048, Innosoft, MCI
ISI, November 1996.
[RFC-2049]
Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part Five: Conformance Criteria
Examples", RFC 2049 (this document), Innosoft,
Virtual Holdings, November 1996.
[US-ASCII
Coded Character Set -- 7-Bit American Standard Code
Information Interchange, ANSI X3.4-1986.
[X400]
Schicker, Pietro, "Message Handling Systems, X.400",
Message Handling Systems and Distributed Applications, E
Stefferud, O-j. Jacobsen, and P. Schicker, eds., North
Holland, 1989, pp. 3-41.
Freed & Borenstein Standards Track [Page 24]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
