📄 rfc1341.txt
字号:
process of defining new content-subtypes, then, is not
intended to be a mechanism for imposing restrictions, but
simply a mechanism for publicizing the usages. There are,
therefore, two acceptable mechanisms for defining new
Content-Type subtypes:
1. Private values (starting with "X-") may be
defined bilaterally between two cooperating
agents without outside registration or
standardization.
2. New standard values must be documented,
registered with, and approved by IANA, as
described in Appendix F. Where intended for
public use, the formats they refer to must
also be defined by a published specification,
and possibly offered for standardization.
The seven standard initial predefined Content-Types are
detailed in the bulk of this document. They are:
text -- textual information. The primary subtype,
"plain", indicates plain (unformatted) text. No
special software is required to get the full
meaning of the text, aside from support for the
indicated character set. Subtypes are to be used
for enriched text in forms where application
software may enhance the appearance of the text,
but such software must not be required in order to
get the general idea of the content. Possible
subtypes thus include any readable word processor
format. A very simple and portable subtype,
richtext, is defined in this document.
multipart -- data consisting of multiple parts of
independent data types. Four initial subtypes
are defined, including the primary "mixed"
subtype, "alternative" for representing the same
data in multiple formats, "parallel" for parts
intended to be viewed simultaneously, and "digest"
for multipart entities in which each part is of
type "message".
message -- an encapsulated message. A body of
Content-Type "message" is itself a fully formatted
RFC 822 conformant message which may contain its
own different Content-Type header field. The
primary subtype is "rfc822". The "partial"
subtype is defined for partial messages, to permit
the fragmented transmission of bodies that are
thought to be too large to be passed through mail
transport facilities. Another subtype,
"External-body", is defined for specifying large
bodies by reference to an external data source.
Borenstein & Freed [Page 8]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
image -- image data. Image requires a display device
(such as a graphical display, a printer, or a FAX
machine) to view the information. Initial
subtypes are defined for two widely-used image
formats, jpeg and gif.
audio -- audio data, with initial subtype "basic".
Audio requires an audio output device (such as a
speaker or a telephone) to "display" the contents.
video -- video data. Video requires the capability to
display moving images, typically including
specialized hardware and software. The initial
subtype is "mpeg".
application -- some other kind of data, typically
either uninterpreted binary data or information to
be processed by a mail-based application. The
primary subtype, "octet-stream", is to be used in
the case of uninterpreted binary data, in which
case the simplest recommended action is to offer
to write the information into a file for the user.
Two additional subtypes, "ODA" and "PostScript",
are defined for transporting ODA and PostScript
documents in bodies. Other expected uses for
"application" include spreadsheets, data for
mail-based scheduling systems, and languages for
"active" (computational) email. (Note that active
email entails several securityconsiderations,
which are discussed later in this memo,
particularly in the context of
application/PostScript.)
Default RFC 822 messages are typed by this protocol as plain
text in the US-ASCII character set, which can be explicitly
specified as "Content-type: text/plain; charset=us-ascii".
If no Content-Type is specified, either by error or by an
older user agent, this default is assumed. In the presence
of a MIME-Version header field, a receiving User Agent can
also assume that plain US-ASCII text was the sender's
intent. In the absence of a MIME-Version specification,
plain US-ASCII text must still be assumed, but the sender's
intent might have been otherwise.
RATIONALE: In the absence of any Content-Type header field
or MIME-Version header field, it is impossible to be certain
that a message is actually text in the US-ASCII character
set, since it might well be a message that, using the
conventions that predate this document, includes text in
another character set or non-textual data in a manner that
cannot be automatically recognized (e.g., a uuencoded
compressed UNIX tar file). Although there is no fully
acceptable alternative to treating such untyped messages as
"text/plain; charset=us-ascii", implementors should remain
aware that if a message lacks both the MIME-Version and the
Content-Type header fields, it may in practice contain
almost anything.
Borenstein & Freed [Page 9]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
It should be noted that the list of Content-Type values
given here may be augmented in time, via the mechanisms
described above, and that the set of subtypes is expected to
grow substantially.
When a mail reader encounters mail with an unknown Content-
type value, it should generally treat it as equivalent to
"application/octet-stream", as described later in this
document.
5 The Content-Transfer-Encoding Header Field
Many Content-Types which could usefully be transported via
email are represented, in their "natural" format, as 8-bit
character or binary data. Such data cannot be transmitted
over some transport protocols. For example, RFC 821
restricts mail messages to 7-bit US-ASCII data with 1000
character lines.
It is necessary, therefore, to define a standard mechanism
for re-encoding such data into a 7-bit short-line format.
This document specifies that such encodings will be
indicated by a new "Content-Transfer-Encoding" header field.
The Content-Transfer-Encoding field is used to indicate the
type of transformation that has been used in order to
represent the body in an acceptable manner for transport.
Unlike Content-Types, a proliferation of Content-Transfer-
Encoding values is undesirable and unnecessary. However,
establishing only a single Content-Transfer-Encoding
mechanism does not seem possible. There is a tradeoff
between the desire for a compact and efficient encoding of
largely-binary data and the desire for a readable encoding
of data that is mostly, but not entirely, 7-bit data. For
this reason, at least two encoding mechanisms are necessary:
a "readable" encoding and a "dense" encoding.
The Content-Transfer-Encoding field is designed to specify
an invertible mapping between the "native" representation of
a type of data and a representation that can be readily
exchanged using 7 bit mail transport protocols, such as
those defined by RFC 821 (SMTP). This field has not been
defined by any previous standard. The field's value is a
single token specifying the type of encoding, as enumerated
below. Formally:
Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" / x-token
These values are not case sensitive. That is, Base64 and
BASE64 and bAsE64 are all equivalent. An encoding type of
7BIT requires that the body is already in a seven-bit mail-
ready representation. This is the default value -- that is,
Borenstein & Freed [Page 10]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
"Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.
The values "8bit", "7bit", and "binary" all imply that NO
encoding has been performed. However, they are potentially
useful as indications of the kind of data contained in the
object, and therefore of the kind of encoding that might
need to be performed for transmission in a given transport
system. "7bit" means that the data is all represented as
short lines of US-ASCII data. "8bit" means that the lines
are short, but there may be non-ASCII characters (octets
with the high-order bit set). "Binary" means that not only
may non-ASCII characters be present, but also that the lines
are not necessarily short enough for SMTP transport.
The difference between "8bit" (or any other conceivable
bit-width token) and the "binary" token is that "binary"
does not require adherence to any limits on line length or
to the SMTP CRLF semantics, while the bit-width tokens do
require such adherence. If the body contains data in any
bit-width other than 7-bit, the appropriate bit-width
Content-Transfer-Encoding token must be used (e.g., "8bit"
for unencoded 8 bit wide data). If the body contains binary
data, the "binary" Content-Transfer-Encoding token must be
used.
NOTE: The distinction between the Content-Transfer-Encoding
values of "binary," "8bit," etc. may seem unimportant, in
that all of them really mean "none" -- that is, there has
been no encoding of the data for transport. However, clear
labeling will be of enormous value to gateways between
future mail transport systems with differing capabilities in
transporting data that do not meet the restrictions of RFC
821 transport.
As of the publication of this document, there are no
standardized Internet transports for which it is legitimate
to include unencoded 8-bit or binary data in mail bodies.
Thus there are no circumstances in which the "8bit" or
"binary" Content-Transfer-Encoding is actually legal on the
Internet. However, in the event that 8-bit or binary mail
transport becomes a reality in Internet mail, or when this
document is used in conjunction with any other 8-bit or
binary-capable transport mechanism, 8-bit or binary bodies
should be labeled as such using this mechanism.
NOTE: The five values defined for the Content-Transfer-
Encoding field imply nothing about the Content-Type other
than the algorithm by which it was encoded or the transport
system requirements if unencoded.
Implementors may, if necessary, define new Content-
Transfer-Encoding values, but must use an x-token, which is
a name prefixed by "X-" to indicate its non-standard status,
Borenstein & Freed [Page 11]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
e.g., "Content-Transfer-Encoding: x-my-new-encoding".
However, unlike Content-Types and subtypes, the creation of
new Content-Transfer-Encoding values is explicitly and
strongly discouraged, as it seems likely to hinder
interoperability with little potential benefit. Their use
is allowed only as the result of an agreement between
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -