RFC822 definition.
attribute := token
body-part = <"message" as defined in RFC822,
with all header fields optional, and with the
specified delimiter not occurring anywhere in
the message body, either on a line by itself
or as a substring anywhere.>
boundary := 0*69<bchars> bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /
"_"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
close-delimiter := delimiter "--"
Content-Description := *text
Content-ID := msg-id
Content-Transfer-Encoding := "BASE64" / "QUOTED-
PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" / x-token
Content-Type := type "/" subtype *[";" parameter]
delimiter := CRLF "--" boundary ; taken from Content-Type
field.
; when content-type is
multipart
; There should be no space
; between "--" and boundary.
encapsulation := delimiter CRLF body-part
epilogue := *text ; to be ignored upon
receipt.
Borenstein & Freed [Page 66]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
MIME-Version := 1*text
multipart-body := preamble 1*encapsulation close-delimiter
epilogue
parameter := attribute "=" value
preamble := *text ; to be ignored upon
receipt.
subtype := token
token := 1*<any CHAR except SPACE, CTLs, or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in
/ "," / ";" / ":" / "\" / <"> ; quoted-string,
/ "/" / "[" / "]" / "?" / "." ; to use within
/ "=" ; parameter values
type := "application" / "audio" ; case-
insensitive
/ "image" / "message"
/ "multipart" / "text"
/ "video" / x-token
value := token / quoted-string
x-token := <The two characters "X-" followed, with no
intervening white space, by any token>
Borenstein & Freed [Page 67]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Appendix F -- IANA Registration Procedures
MIME has been carefully designed to have extensible
mechanisms, and it is expected that the set of content-
type/subtype pairs and their associated parameters will grow
significantly with time. Several other MIME fields, notably
character set names, access-type parameters for the
message/external-body type, conversions parameters for the
application type, and possibly even Content-Transfer-
Encoding values, are likely to have new values defined over
time. In order to ensure that the set of such values is
developed in an orderly, well-specified, and public manner,
MIME defines a registration process which uses the Internet
Assigned Numbers Authority (IANA) as a central registry for
such values.
In general, parameters in the content-type header field are
used to convey supplemental information for various content
types, and their use is defined when the content-type and
subtype are defined. New parameters should not be defined
as a way to introduce new functionality.
In order to simplify and standardize the registration
process, this appendix gives templates for the registration
of new values with IANA. Each of these is given in the form
of an email message template, to be filled in by the
registering party.
F.1 Registration of New Content-type/subtype Values
Note that MIME is generally expected to be extended by
subtypes. If a new fundamental top-level type is needed,
its specification should be published as an RFCor
submitted in a form suitable to become an RFC, and be
subject to the Internet standards process.
To: IANA@isi.edu
Subject: Registration of new MIME content-type/subtype
MIME type name:
(If the above is not an existing top-level MIME type,
please explain why an existing type cannot be used.)
MIME subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Borenstein & Freed [Page 68]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Published specification:
(The published specification must be an Internet RFCor
RFC-to-be if a new top-level type is being defined, and
must be a publicly available specification in any
case.)
Person & email address to contact for further
information:
F.2 Registration of New Character Set Values
To: IANA@isi.edu
Subject: Registration of new MIME character set value
MIME character set name:
Published specification:
(The published specification must be an Internet RFCor
RFC-to-be or an international standard.)
Person & email address to contact for further
information:
F.3 Registration of New Access-type Values for
Message/external-body
To: IANA@isi.edu
Subject: Registration of new MIME Access-type for
Message/external-body content-type
MIME access-type name:
Required parameters:
Optional parameters:
Published specification:
(The published specification must be an Internet RFCor
RFC-to-be.)
Person & email address to contact for further
information:
F.4 Registration of New Conversions Values for Application
To: IANA@isi.edu
Subject: Registration of new MIME Conversions value
for Application content-type
MIME Conversions name:
Borenstein & Freed [Page 69]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Published specification:
(The published specification must be an Internet RFCor
RFC-to-be.)
Person & email address to contact for further
information:
Borenstein & Freed [Page 70]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Appendix G -- Summary of the Seven Content-types
Content-type: text
Subtypes defined by this document: plain, richtext
Important Parameters: charset
Encoding notes: quoted-printable generally preferred if an
encoding is needed and the character set is mostly an
ASCII superset.
Security considerations: Rich text formats such as TeX and
Troff often contain mechanisms for executing arbitrary
commands or file system operations, and should not be
used automatically unless these security problems have
been addressed. Even plain text may contain control
characters that can be used to exploit the capabilities
of "intelligent" terminals and cause security
violations. User interfaces designed to run on such
terminals should be aware of and try to prevent such
problems.
________________________________________________________________
Content-type: multipart
Subtypes defined by this document: mixed, alternative,
digest, parallel.
Important Parameters: boundary
Encoding notes: No content-transfer-encoding is permitted.
________________________________________________________________
Content-type: message
Subtypes defined by this document: rfc822, partial,
external-body
Important Parameters: id, number, total
Encoding notes: No content-transfer-encoding is permitted.
________________________________________________________________
Content-type: application
Subtypes defined by this document: octet-stream,
postscript, oda
Important Parameters: profile
Borenstein & Freed [Page 71]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Encoding notes: base64 generally preferred for octet-stream
or other unreadable subtypes.
Security considerations: This type is intended for the
transmission of data to be interpreted by locally-installed
programs. If used, for example, to transmit executable
binary programs or programs in general-purpose interpreted
languages, such as LISP programs or shell scripts, severe
security problems could result. In general, authors of
mail-reading agents are cautioned against giving their
systems the power to execute mail-based application data
without carefully considering the security implications.
While it is certainly possible to define safe application
formats and even safe interpreters for unsafe formats, each
interpreter should be evaluated separately for possible
security problems.
________________________________________________________________
Content-type: image
Subtypes defined by this document: jpeg, gif
Important Parameters: none
Encoding notes: base64 generally preferred
________________________________________________________________
Content-type: audio
Subtypes defined by this document: basic
Important Parameters: none
Encoding notes: base64 generally preferred
________________________________________________________________
Content-type: video
Subtypes defined by this document: mpeg
Important Parameters: none
Encoding notes: base64 generally preferred
Borenstein & Freed [Page 72]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Appendix H -- Canonical Encoding Model
There was some confusion, in earlier drafts of this memo,
regarding the model for when email data was to be converted
to canonical form and encoded, and in particular how this
process would affect the treatment of CRLFs, given that the
representation of newlines varies greatly from system to
system. For this reason, a canonical model for encoding is
presented below.
The process of composing a MIME message part can be modelled
as being done in a number of steps. Note that these steps
are roughly similar to those steps used in RFC1113:
Step 1. Creation of local form.
The body part to be transmitted is created in the system's
native format. The native character set is used, and where
appropriate local end of line conventions are used as well.
The may be a UNIX-style text file, or a Sun raster image, or
a VMS indexed file, or audio data in a system-dependent
format stored only in memory, or anything else that
corresponds to the local model for the representation of
some form of information.
Step 2. Conversion to canonical form.
The entire body part, including "out-of-band" information
such as record lengths and possibly file attribute
information, is converted to a universal canonical form.
The specific content type of the body part as well as its
associated attributes dictate the nature of the canonical
form that is used. Conversion to the proper canonical form
may involve character set conversion, transformation of
audio data, compression, or various other operations
specific to the various content types.
For example, in the case of text/plain data, the text must
be converted to a supported character set and lines must be
delimited with CRLF delimiters in accordance with RFC822.
Note that the restriction on line lengths implied by RFC822
is eliminated if the next step employs either quoted-
printable or base64 encoding.
Step 3. Apply transfer encoding.
A Content-Transfer-Encoding appropriate for this body part
is applied. Note that there is no fixed relationship
between the content type and the transfer encoding. In
particular, it may be appropriate to base the choice of
base64 or quoted-printable on character frequency counts
which are specific to a given instance of body part.
Borenstein & Freed [Page 73]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Step 4. Insertion into message.
The encoded object is inserted into a MIME message with
appropriate body part headers and boundary markers.
It is vital to note that these steps are only a model; they
are 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 prior to encoding will be subsumed into the
encoder itself, which understands local formats
directly. For example, the local newline
convention for text bodyparts might be carried
through to the encoder itself along with knowledge
of what that format is.
2. The output of the encoders may have to pass
through one or more additional steps prior to
being transmitted as a message. As such, the
output of the encoder may not be compliant with
the formats specified by RFC822. In particular,
once again it may be appropriate for the
converter's output to be expressed using local
newline conventions rather than using the standard
RFC822 CRLF delimiters.
Other implementation variations are conceivable as well.
The only important aspect of this discussion is that the
resulting messages are consistent with those produced by the
model described here.
Borenstein & Freed [Page 74]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
References
[US-ASCII] Coded Character Set--7-Bit American Standard Code
for Information Interchange, ANSI X3.4-1986.
[ATK] Borenstein, Nathaniel S., Multimedia Applications
Development with the Andrew Toolkit, Prentice-Hall, 1990.
[GIF] Graphics Interchange Format (Version 89a), Compuserve,
Inc., Columbus, Ohio, 1990.
[ISO-2022] International Standard--Information Processing--
ISO 7-bit and 8-bit coded character sets--Code extension
techniques, ISO 2022:1986.
[ISO-8859] Information Processing -- 8-bit Single-Byte Coded
Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO
8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2,
1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part
4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5:
Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6:
Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7:
Latin/Greek alphabet, ISO 8859-7, 1987. Part 8:
Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin
alphabet No. 5, ISO 8859-9, 1990.
[ISO-646] International Standard--Information Processing--
ISO 7-bit coded character set for information interchange,
ISO 646:1983.
[MPEG] Video Coding Draft Standard ISO 11172 CD, ISO
IEC/TJC1/SC2/WG11 (Motion Picture Experts Group), May, 1991.
[ODA] ISO 8613; Information Processing: Text and Office
System; Office Document Architecture (ODA) and Interchange
Format (ODIF), Part 1-8, 1989.
[PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva,
1972, "Pulse Code Modulation (PCM) of Voice Frequencies".
[POSTSCRIPT] Adobe Systems, Inc., PostScript Language
Reference Manual, Addison-Wesley, 1985.
[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.
[RFC-783] Sollins, K.R. TFTP Protocol (revision 2). June,
1981, MIT, RFC-783.
[RFC-821] Postel, J.B. Simple Mail Transfer Protocol.
August, 1982, USC/Information Sciences Institute, RFC-821.
Borenstein & Freed [Page 75]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
[RFC-822] Crocker, D. Standard for the format of ARPA
Internet text messages. August, 1982, UDEL, RFC-822.
[RFC-934] Rose, M.T.; Stefferud, E.A. Proposed standard
for message encapsulation. January, 1985, Delaware
and NMA, RFC-934.
[RFC-959] Postel, J.B.; Reynolds, J.K. File Transfer
Protocol. October, 1985, USC/Information Sciences
Institute, RFC-959.
[RFC-1049] Sirbu, M.A. Content-Type header field for
Internet messages. March, 1988, CMU, RFC-1049.
[RFC-1113] Linn, J. Privacy enhancement for Internet
electronic mail: Part I - message encipherment and
authentication procedures. August, 1989, IAB Privacy Task
Force, RFC-1113.
[RFC-1154] Robinson, D.; Ullmann, R. Encoding header field
for Internet messages. April, 1990, Prime Computer,
Inc., RFC-1154.
[RFC-1342] Moore, Keith, Representation of Non-Ascii Text in
Internet Message Headers. June, 1992, University of
Tennessee, RFC-1342.
Security Considerations
Security issues are discussed in Section 7.4.2 and in
Appendix G. Implementors should pay special attention to
the security implications of any mail content-types that can
cause the remote execution of any actions in the recipient's
environment. In such cases, the discussion of the
applicaton/postscript content-type in Section 7.4.2 may
serve as a model for considering other content-types with
remote execution capabilities.
Borenstein & Freed [Page 76]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Authors' Addresses
For more information, the authors of this document may be
contacted via Internet mail:
Nathaniel S. Borenstein
MRE 2D-296, Bellcore
445 South St.
Morristown, NJ 07962-1910
Phone: +1 201 829 4270
Fax: +1 201 829 7019
Email: nsb@bellcore.com
Ned Freed
Innosoft International, Inc.
250 West First Street
Suite 240
Claremont, CA 91711
Phone: +1 714 624 7907
Fax: +1 714 621 5319
Email: ned@innosoft.com
Borenstein & Freed [Page 77]
RFC1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
THIS PAGE INTENTIONALLY LEFT BLANK.
Please discard this page and place the following table of
contents after the title page.
Borenstein & Freed [Page i]
Table of Contents
1 Introduction....................................... 1
2 Notations, Conventions, and Generic BNF Grammar.... 3
3 The MIME-Version Header Field...................... 5
4 The Content-Type Header Field...................... 6
5 The Content-Transfer-Encoding Header Field......... 10
5.1 Quoted-Printable Content-Transfer-Encoding......... 14
5.2 Base64 Content-Transfer-Encoding................... 17
6 Additional Optional Content- Header Fields......... 19
6.1 Optional Content-ID Header Field................... 19
6.2 Optional Content-Description Header Field.......... 19
7 The Predefined Content-Type Values................. 20
7.1 The Text Content-Type.............................. 20
7.1.1 The charset parameter.............................. 20
7.1.2 The Text/plain subtype............................. 23
7.1.3 The Text/richtext subtype.......................... 23
7.2 The Multipart Content-Type......................... 29
7.2.1 Multipart: The common syntax...................... 30
7.2.2 The Multipart/mixed (primary) subtype.............. 34
7.2.3 The Multipart/alternative subtype.................. 34
7.2.4 The Multipart/digest subtype....................... 36
7.2.5 The Multipart/parallel subtype..................... 36
7.3 The Message Content-Type........................... 37
7.3.1 The Message/rfc822 (primary) subtype............... 37
7.3.2 The Message/Partial subtype........................ 37
7.3.3 The Message/External-Body subtype.................. 40
7.4 The Application Content-Type....................... 46
7.4.1 The Application/Octet-Stream (primary) subtype..... 46
7.4.2 The Application/PostScript subtype................. 47
7.4.3 The Application/ODA subtype........................ 50
7.5 The Image Content-Type............................. 51
7.6 The Audio Content-Type............................. 51
7.7 The Video Content-Type............................. 51
7.8 Experimental Content-Type Values................... 51
Summary............................................ 53
Acknowledgements................................... 54
Appendix A -- Minimal MIME-Conformance............. 56
Appendix B -- General Guidelines For Sending Email Data59
Appendix C -- A Complex Multipart Example.......... 62
Appendix D -- A Simple Richtext-to-Text Translator in C64
Appendix E -- Collected Grammar.................... 66
Appendix F -- IANA Registration Procedures......... 68
F.1 Registration of New Content-type/subtype Values..68
F.2 Registration of New Character Set Values...... 69
F.3 Registration of New Access-type Values for Message/external-body69
F.4 Registration of New Conversions Values for Application69
Appendix G -- Summary of the Seven Content-types... 71
Appendix H -- Canonical Encoding Model............. 73
References......................................... 75
Security Considerations............................ 76
Authors' Addresses................................. 77
Borenstein & Freed [Page ii]
Borenstein & Freed [Page iii]