RFC2045 日本語訳

2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format ofInternet Message Bodies. N. Freed, N. Borenstein. November 1996. (Format: TXT=72932 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2184, RFC2231, RFC5335) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                          N. Freed
Request for Comments: 2045                                     Innosoft
Obsoletes: 1521, 1522, 1590                               N. Borenstein
Category: Standards Track                                 First Virtual
                                                          November 1996

Network Working Group N. Freed Request for Comments: 2045 Innosoft Obsoletes: 1521, 1522, 1590 N. Borenstein Category: Standards Track First Virtual November 1996

                 Multipurpose Internet Mail Extensions
                            (MIME) Part One:
                   Format of Internet Message Bodies

Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies

Status of this Memo

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Abstract

Abstract

   STD 11, RFC 822, defines a message representation protocol specifying
   considerable detail about US-ASCII message headers, and leaves the
   message content, or message body, as flat US-ASCII text.  This set of
   documents, collectively called the Multipurpose Internet Mail
   Extensions, or MIME, redefines the format of messages to allow for

STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for

    (1)   textual message bodies in character sets other than
          US-ASCII,

(1) textual message bodies in character sets other than US-ASCII,

    (2)   an extensible set of different formats for non-textual
          message bodies,

(2) an extensible set of different formats for non-textual message bodies,

    (3)   multi-part message bodies, and

(3) multi-part message bodies, and

    (4)   textual header information in character sets other than
          US-ASCII.

(4) textual header information in character sets other than US-ASCII.

   These documents are based on earlier work documented in RFC 934, STD
   11, and RFC 1049, but extends and revises them.  Because RFC 822 said
   so little about message bodies, these documents are largely
   orthogonal to (rather than a revision of) RFC 822.

These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

   This initial document specifies the various headers used to describe
   the structure of MIME messages. The second document, RFC 2046,
   defines the general structure of the MIME media typing system and
   defines an initial set of media types. The third document, RFC 2047,
   describes extensions to RFC 822 to allow non-US-ASCII text data in

This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in

Freed & Borenstein          Standards Track                     [Page 1]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 1] RFC 2045 Internet Message Bodies November 1996

   Internet mail header fields. The fourth document, RFC 2048, specifies
   various IANA registration procedures for MIME-related facilities. The
   fifth and final document, RFC 2049, describes MIME conformance
   criteria as well as providing some illustrative examples of MIME
   message formats, acknowledgements, and the bibliography.

Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

   These documents are revisions of RFCs 1521, 1522, and 1590, which
   themselves were revisions of RFCs 1341 and 1342.  An appendix in RFC
   2049 describes differences and changes from previous versions.

These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.

Table of Contents

Table of Contents

   1. Introduction .........................................    3
   2. Definitions, Conventions, and Generic BNF Grammar ....    5
   2.1 CRLF ................................................    5
   2.2 Character Set .......................................    6
   2.3 Message .............................................    6
   2.4 Entity ..............................................    6
   2.5 Body Part ...........................................    7
   2.6 Body ................................................    7
   2.7 7bit Data ...........................................    7
   2.8 8bit Data ...........................................    7
   2.9 Binary Data .........................................    7
   2.10 Lines ..............................................    7
   3. MIME Header Fields ...................................    8
   4. MIME-Version Header Field ............................    8
   5. Content-Type Header Field ............................   10
   5.1 Syntax of the Content-Type Header Field .............   12
   5.2 Content-Type Defaults ...............................   14
   6. Content-Transfer-Encoding Header Field ...............   14
   6.1 Content-Transfer-Encoding Syntax ....................   14
   6.2 Content-Transfer-Encodings Semantics ................   15
   6.3 New Content-Transfer-Encodings ......................   16
   6.4 Interpretation and Use ..............................   16
   6.5 Translating Encodings ...............................   18
   6.6 Canonical Encoding Model ............................   19
   6.7 Quoted-Printable Content-Transfer-Encoding ..........   19
   6.8 Base64 Content-Transfer-Encoding ....................   24
   7. Content-ID Header Field ..............................   26
   8. Content-Description Header Field .....................   27
   9. Additional MIME Header Fields ........................   27
   10. Summary .............................................   27
   11. Security Considerations .............................   27
   12. Authors' Addresses ..................................   28
   A. Collected Grammar ....................................   29

1. Introduction ......................................... 3 2. Definitions, Conventions, and Generic BNF Grammar .... 5 2.1 CRLF ................................................ 5 2.2 Character Set ....................................... 6 2.3 Message ............................................. 6 2.4 Entity .............................................. 6 2.5 Body Part ........................................... 7 2.6 Body ................................................ 7 2.7 7bit Data ........................................... 7 2.8 8bit Data ........................................... 7 2.9 Binary Data ......................................... 7 2.10 Lines .............................................. 7 3. MIME Header Fields ................................... 8 4. MIME-Version Header Field ............................ 8 5. Content-Type Header Field ............................ 10 5.1 Syntax of the Content-Type Header Field ............. 12 5.2 Content-Type Defaults ............................... 14 6. Content-Transfer-Encoding Header Field ............... 14 6.1 Content-Transfer-Encoding Syntax .................... 14 6.2 Content-Transfer-Encodings Semantics ................ 15 6.3 New Content-Transfer-Encodings ...................... 16 6.4 Interpretation and Use .............................. 16 6.5 Translating Encodings ............................... 18 6.6 Canonical Encoding Model ............................ 19 6.7 Quoted-Printable Content-Transfer-Encoding .......... 19 6.8 Base64 Content-Transfer-Encoding .................... 24 7. Content-ID Header Field .............................. 26 8. Content-Description Header Field ..................... 27 9. Additional MIME Header Fields ........................ 27 10. Summary ............................................. 27 11. Security Considerations ............................. 27 12. Authors' Addresses .................................. 28 A. Collected Grammar .................................... 29

Freed & Borenstein          Standards Track                     [Page 2]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 2] RFC 2045 Internet Message Bodies November 1996

1.  Introduction

1. Introduction

   Since its publication in 1982, RFC 822 has defined the standard
   format of textual mail messages on the Internet.  Its success has
   been such that the RFC 822 format has been adopted, wholly or
   partially, well beyond the confines of the Internet and the Internet
   SMTP transport defined by RFC 821.  As the format has seen wider use,
   a number of limitations have proven increasingly restrictive for the
   user community.

Since its publication in 1982, RFC 822 has defined the standard format of textual mail messages on the Internet. Its success has been such that the RFC 822 format has been adopted, wholly or partially, well beyond the confines of the Internet and the Internet SMTP transport defined by RFC 821. As the format has seen wider use, a number of limitations have proven increasingly restrictive for the user community.

   RFC 822 was intended to specify a format for text messages.  As such,
   non-text messages, such as multimedia messages that might include
   audio or images, are simply not mentioned.  Even in the case of text,
   however, RFC 822 is inadequate for the needs of mail users whose
   languages require the use of character sets richer than US-ASCII.
   Since RFC 822 does not specify mechanisms for mail containing audio,
   video, Asian language text, or even text in most European languages,
   additional specifications are needed.

RFC 822 was intended to specify a format for text messages. As such, non-text messages, such as multimedia messages that might include audio or images, are simply not mentioned. Even in the case of text, however, RFC 822 is inadequate for the needs of mail users whose languages require the use of character sets richer than US-ASCII. Since RFC 822 does not specify mechanisms for mail containing audio, video, Asian language text, or even text in most European languages, additional specifications are needed.

   One of the notable limitations of RFC 821/822 based mail systems is
   the fact that they limit the contents of electronic mail messages to
   relatively short lines (e.g. 1000 characters or less [RFC-821]) of
   7bit US-ASCII.  This forces users to convert any non-textual data
   that they may wish to send into seven-bit bytes representable as
   printable US-ASCII characters before invoking a local mail UA (User
   Agent, a program with which human users send and receive mail).
   Examples of such encodings currently used in the Internet include
   pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in
   RFC 1421, the Andrew Toolkit Representation [ATK], and many others.

One of the notable limitations of RFC 821/822 based mail systems is the fact that they limit the contents of electronic mail messages to relatively short lines (e.g. 1000 characters or less [RFC-821]) of 7bit US-ASCII. This forces users to convert any non-textual data that they may wish to send into seven-bit bytes representable as printable US-ASCII characters before invoking a local mail UA (User Agent, a program with which human users send and receive mail). Examples of such encodings currently used in the Internet include pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in RFC 1421, the Andrew Toolkit Representation [ATK], and many others.

   The limitations of RFC 822 mail become even more apparent as gateways
   are designed to allow for the exchange of mail messages between RFC
   822 hosts and X.400 hosts.  X.400 [X400] specifies mechanisms for the
   inclusion of non-textual material within electronic mail messages.
   The current standards for the mapping of X.400 messages to RFC 822
   messages specify either that X.400 non-textual material must be
   converted to (not encoded in) IA5Text format, or that they must be
   discarded, notifying the RFC 822 user that discarding has occurred.
   This is clearly undesirable, as information that a user may wish to
   receive is lost.  Even though a user agent may not have the
   capability of dealing with the non-textual material, the user might
   have some mechanism external to the UA that can extract useful
   information from the material.  Moreover, it does not allow for the
   fact that the message may eventually be gatewayed back into an X.400
   message handling system (i.e., the X.400 message is "tunneled"
   through Internet mail), where the non-textual information would
   definitely become useful again.

The limitations of RFC 822 mail become even more apparent as gateways are designed to allow for the exchange of mail messages between RFC 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the inclusion of non-textual material within electronic mail messages. The current standards for the mapping of X.400 messages to RFC 822 messages specify either that X.400 non-textual material must be converted to (not encoded in) IA5Text format, or that they must be discarded, notifying the RFC 822 user that discarding has occurred. This is clearly undesirable, as information that a user may wish to receive is lost. Even though a user agent may not have the capability of dealing with the non-textual material, the user might have some mechanism external to the UA that can extract useful information from the material. Moreover, it does not allow for the fact that the message may eventually be gatewayed back into an X.400 message handling system (i.e., the X.400 message is "tunneled" through Internet mail), where the non-textual information would definitely become useful again.

Freed & Borenstein          Standards Track                     [Page 3]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 3] RFC 2045 Internet Message Bodies November 1996

   This document describes several mechanisms that combine to solve most
   of these problems without introducing any serious incompatibilities
   with the existing world of RFC 822 mail.  In particular, it
   describes:

This document describes several mechanisms that combine to solve most of these problems without introducing any serious incompatibilities with the existing world of RFC 822 mail. In particular, it describes:

    (1)   A MIME-Version header field, which uses a version
          number to declare a message to be conformant with MIME
          and allows mail processing agents to distinguish
          between such messages and those generated by older or
          non-conformant software, which are presumed to lack
          such a field.

(1) A MIME-Version header field, which uses a version number to declare a message to be conformant with MIME and allows mail processing agents to distinguish between such messages and those generated by older or non-conformant software, which are presumed to lack such a field.

    (2)   A Content-Type header field, generalized from RFC 1049,
          which can be used to specify the media type and subtype
          of data in the body of a message and to fully specify
          the native representation (canonical form) of such
          data.

(2) A Content-Type header field, generalized from RFC 1049, which can be used to specify the media type and subtype of data in the body of a message and to fully specify the native representation (canonical form) of such data.

    (3)   A Content-Transfer-Encoding header field, which can be
          used to specify both the encoding transformation that
          was applied to the body and the domain of the result.
          Encoding transformations other than the identity
          transformation are usually applied to data in order to
          allow it to pass through mail transport mechanisms
          which may have data or character set limitations.

(3) A Content-Transfer-Encoding header field, which can be used to specify both the encoding transformation that was applied to the body and the domain of the result. Encoding transformations other than the identity transformation are usually applied to data in order to allow it to pass through mail transport mechanisms which may have data or character set limitations.

    (4)   Two additional header fields that can be used to
          further describe the data in a body, the Content-ID and
          Content-Description header fields.

(4) Two additional header fields that can be used to further describe the data in a body, the Content-ID and Content-Description header fields.

   All of the header fields defined in this document are subject to the
   general syntactic rules for header fields specified in RFC 822.  In
   particular, all of these header fields except for Content-Disposition
   can include RFC 822 comments, which have no semantic content and
   should be ignored during MIME processing.

All of the header fields defined in this document are subject to the general syntactic rules for header fields specified in RFC 822. In particular, all of these header fields except for Content-Disposition can include RFC 822 comments, which have no semantic content and should be ignored during MIME processing.

   Finally, to specify and promote interoperability, RFC 2049 provides a
   basic applicability statement for a subset of the above mechanisms
   that defines a minimal level of "conformance" with this document.

Finally, to specify and promote interoperability, RFC 2049 provides a basic applicability statement for a subset of the above mechanisms that defines a minimal level of "conformance" with this document.

   HISTORICAL NOTE:  Several of the mechanisms described in this set of
   documents may seem somewhat strange or even baroque at first reading.
   It is important to note that compatibility with existing standards
   AND robustness across existing practice were two of the highest
   priorities of the working group that developed this set of documents.
   In particular, compatibility was always favored over elegance.

HISTORICAL NOTE: Several of the mechanisms described in this set of documents may seem somewhat strange or even baroque at first reading. It is important to note that compatibility with existing standards AND robustness across existing practice were two of the highest priorities of the working group that developed this set of documents. In particular, compatibility was always favored over elegance.

Freed & Borenstein          Standards Track                     [Page 4]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 4] RFC 2045 Internet Message Bodies November 1996

   Please refer to the current edition of the "Internet Official
   Protocol Standards" for the standardization state and status of this
   protocol.  RFC 822 and STD 3, RFC 1123 also provide essential
   background for MIME since no conforming implementation of MIME can
   violate them.  In addition, several other informational RFC documents
   will be of interest to the MIME implementor, in particular RFC 1344,
   RFC 1345, and RFC 1524.

Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. RFC 822 and STD 3, RFC 1123 also provide essential background for MIME since no conforming implementation of MIME can violate them. In addition, several other informational RFC documents will be of interest to the MIME implementor, in particular RFC 1344, RFC 1345, and RFC 1524.

2.  Definitions, Conventions, and Generic BNF Grammar

2. Definitions, Conventions, and Generic BNF Grammar

   Although the mechanisms specified in this set of documents are all
   described in prose, most are also described formally in the augmented
   BNF notation of RFC 822. Implementors will need to be familiar with
   this notation in order to understand this set of documents, and are
   referred to RFC 822 for a complete explanation of the augmented BNF
   notation.

Although the mechanisms specified in this set of documents are all described in prose, most are also described formally in the augmented BNF notation of RFC 822. Implementors will need to be familiar with this notation in order to understand this set of documents, and are referred to RFC 822 for a complete explanation of the augmented BNF notation.

   Some of the augmented BNF in this set of documents makes named
   references to syntax rules defined in RFC 822.  A complete formal
   grammar, then, is obtained by combining the collected grammar
   appendices in each document in this set with the BNF of RFC 822 plus
   the modifications to RFC 822 defined in RFC 1123 (which specifically
   changes the syntax for `return', `date' and `mailbox').

Some of the augmented BNF in this set of documents makes named references to syntax rules defined in RFC 822. A complete formal grammar, then, is obtained by combining the collected grammar appendices in each document in this set with the BNF of RFC 822 plus the modifications to RFC 822 defined in RFC 1123 (which specifically changes the syntax for `return', `date' and `mailbox').

   All numeric and octet values are given in decimal notation in this
   set of documents. All media type values, subtype values, and
   parameter names as defined are case-insensitive.  However, parameter
   values are case-sensitive unless otherwise specified for the specific
   parameter.

All numeric and octet values are given in decimal notation in this set of documents. All media type values, subtype values, and parameter names as defined are case-insensitive. However, parameter values are case-sensitive unless otherwise specified for the specific parameter.

   FORMATTING NOTE:  Notes, such at this one, provide additional
   nonessential information which may be skipped by the reader without
   missing anything essential.  The primary purpose of these non-
   essential notes is to convey information about the rationale of this
   set of documents, or to place these documents in the proper
   historical or evolutionary context.  Such information may in
   particular be skipped by those who are focused entirely on building a
   conformant implementation, but may be of use to those who wish to
   understand why certain design choices were made.

FORMATTING NOTE: Notes, such at this one, provide additional nonessential information which may be skipped by the reader without missing anything essential. The primary purpose of these non- essential notes is to convey information about the rationale of this set of documents, or to place these documents in the proper historical or evolutionary context. Such information may in particular be skipped by those who are focused entirely on building a conformant implementation, but may be of use to those who wish to understand why certain design choices were made.

2.1.  CRLF

2.1. CRLF

   The term CRLF, in this set of documents, refers to the sequence of
   octets corresponding to the two US-ASCII characters CR (decimal value
   13) and LF (decimal value 10) which, taken together, in this order,
   denote a line break in RFC 822 mail.

The term CRLF, in this set of documents, refers to the sequence of octets corresponding to the two US-ASCII characters CR (decimal value 13) and LF (decimal value 10) which, taken together, in this order, denote a line break in RFC 822 mail.

Freed & Borenstein          Standards Track                     [Page 5]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 5] RFC 2045 Internet Message Bodies November 1996

2.2.  Character Set

2.2. Character Set

   The term "character set" is used in MIME to refer to a method of
   converting a sequence of octets into a sequence of characters.  Note
   that unconditional and unambiguous conversion in the other direction
   is not required, in that not all characters may be representable by a
   given character set and a character set may provide more than one
   sequence of octets to represent a particular sequence of characters.

The term "character set" is used in MIME to refer to a method of converting a sequence of octets into a sequence of characters. Note that unconditional and unambiguous conversion in the other direction is not required, in that not all characters may be representable by a given character set and a character set may provide more than one sequence of octets to represent a particular sequence of characters.

   This definition is intended to allow various kinds of character
   encodings, from simple single-table mappings such as US-ASCII to
   complex table switching methods such as those that use ISO 2022's
   techniques, to be used as character sets.  However, the definition
   associated with a MIME character set name must fully specify the
   mapping to be performed.  In particular, use of external profiling
   information to determine the exact mapping is not permitted.

This definition is intended to allow various kinds of character encodings, from simple single-table mappings such as US-ASCII to complex table switching methods such as those that use ISO 2022's techniques, to be used as character sets. However, the definition associated with a MIME character set name must fully specify the mapping to be performed. In particular, use of external profiling information to determine the exact mapping is not permitted.

   NOTE: The term "character set" was originally to describe such
   straightforward schemes as US-ASCII and ISO-8859-1 which have a
   simple one-to-one mapping from single octets to single characters.
   Multi-octet coded character sets and switching techniques make the
   situation more complex. For example, some communities use the term
   "character encoding" for what MIME calls a "character set", while
   using the phrase "coded character set" to denote an abstract mapping
   from integers (not octets) to characters.

NOTE: The term "character set" was originally to describe such straightforward schemes as US-ASCII and ISO-8859-1 which have a simple one-to-one mapping from single octets to single characters. Multi-octet coded character sets and switching techniques make the situation more complex. For example, some communities use the term "character encoding" for what MIME calls a "character set", while using the phrase "coded character set" to denote an abstract mapping from integers (not octets) to characters.

2.3.  Message

2.3. Message

   The term "message", when not further qualified, means either a
   (complete or "top-level") RFC 822 message being transferred on a
   network, or a message encapsulated in a body of type "message/rfc822"
   or "message/partial".

The term "message", when not further qualified, means either a (complete or "top-level") RFC 822 message being transferred on a network, or a message encapsulated in a body of type "message/rfc822" or "message/partial".

2.4.  Entity

2.4. Entity

   The term "entity", refers specifically to the MIME-defined header
   fields and contents of either a message or one of the parts in the
   body of a multipart entity.  The specification of such entities is
   the essence of MIME.  Since the contents of an entity are often
   called the "body", it makes sense to speak about the body of an
   entity.  Any sort of field may be present in the header of an entity,
   but only those fields whose names begin with "content-" actually have
   any MIME-related meaning.  Note that this does NOT imply thay they
   have no meaning at all -- an entity that is also a message has non-
   MIME header fields whose meanings are defined by RFC 822.

The term "entity", refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity. The specification of such entities is the essence of MIME. Since the contents of an entity are often called the "body", it makes sense to speak about the body of an entity. Any sort of field may be present in the header of an entity, but only those fields whose names begin with "content-" actually have any MIME-related meaning. Note that this does NOT imply thay they have no meaning at all -- an entity that is also a message has non- MIME header fields whose meanings are defined by RFC 822.

Freed & Borenstein          Standards Track                     [Page 6]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 6] RFC 2045 Internet Message Bodies November 1996

2.5.  Body Part

2.5. Body Part

   The term "body part" refers to an entity inside of a multipart
   entity.

The term "body part" refers to an entity inside of a multipart entity.

2.6.  Body

2.6. Body

   The term "body", when not further qualified, means the body of an
   entity, that is, the body of either a message or of a body part.

The term "body", when not further qualified, means the body of an entity, that is, the body of either a message or of a body part.

   NOTE:  The previous four definitions are clearly circular.  This is
   unavoidable, since the overall structure of a MIME message is indeed
   recursive.

NOTE: The previous four definitions are clearly circular. This is unavoidable, since the overall structure of a MIME message is indeed recursive.

2.7.  7bit Data

2.7. 7bit Data

   "7bit data" refers to data that is all represented as relatively
   short lines with 998 octets or less between CRLF line separation
   sequences [RFC-821].  No octets with decimal values greater than 127
   are allowed and neither are NULs (octets with decimal value 0).  CR
   (decimal value 13) and LF (decimal value 10) octets only occur as
   part of CRLF line separation sequences.

"7bit data" refers to data that is all represented as relatively short lines with 998 octets or less between CRLF line separation sequences [RFC-821]. No octets with decimal values greater than 127 are allowed and neither are NULs (octets with decimal value 0). CR (decimal value 13) and LF (decimal value 10) octets only occur as part of CRLF line separation sequences.

2.8.  8bit Data

2.8. 8bit Data

   "8bit data" refers to data that is all represented as relatively
   short lines with 998 octets or less between CRLF line separation
   sequences [RFC-821]), but octets with decimal values greater than 127
   may be used.  As with "7bit data" CR and LF octets only occur as part
   of CRLF line separation sequences and no NULs are allowed.

"8bit data" refers to data that is all represented as relatively short lines with 998 octets or less between CRLF line separation sequences [RFC-821]), but octets with decimal values greater than 127 may be used. As with "7bit data" CR and LF octets only occur as part of CRLF line separation sequences and no NULs are allowed.

2.9.  Binary Data

2.9. Binary Data

   "Binary data" refers to data where any sequence of octets whatsoever
   is allowed.

"Binary data" refers to data where any sequence of octets whatsoever is allowed.

2.10.  Lines

2.10. Lines

   "Lines" are defined as sequences of octets separated by a CRLF
   sequences.  This is consistent with both RFC 821 and RFC 822.
   "Lines" only refers to a unit of data in a message, which may or may
   not correspond to something that is actually displayed by a user
   agent.

"Lines" are defined as sequences of octets separated by a CRLF sequences. This is consistent with both RFC 821 and RFC 822. "Lines" only refers to a unit of data in a message, which may or may not correspond to something that is actually displayed by a user agent.

Freed & Borenstein          Standards Track                     [Page 7]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 7] RFC 2045 Internet Message Bodies November 1996

3.  MIME Header Fields

3. MIME Header Fields

   MIME defines a number of new RFC 822 header fields that are used to
   describe the content of a MIME entity.  These header fields occur in
   at least two contexts:

MIME defines a number of new RFC 822 header fields that are used to describe the content of a MIME entity. These header fields occur in at least two contexts:

    (1)   As part of a regular RFC 822 message header.

(1) As part of a regular RFC 822 message header.

    (2)   In a MIME body part header within a multipart
          construct.

(2) In a MIME body part header within a multipart construct.

   The formal definition of these header fields is as follows:

The formal definition of these header fields is as follows:

     entity-headers := [ content CRLF ]
                       [ encoding CRLF ]
                       [ id CRLF ]
                       [ description CRLF ]
                       *( MIME-extension-field CRLF )

entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF )

     MIME-message-headers := entity-headers
                             fields
                             version CRLF
                             ; The ordering of the header
                             ; fields implied by this BNF
                             ; definition should be ignored.

MIME-message-headers := entity-headers fields version CRLF ; The ordering of the header ; fields implied by this BNF ; definition should be ignored.

     MIME-part-headers := entity-headers
                          [ fields ]
                          ; Any field not beginning with
                          ; "content-" can have no defined
                          ; meaning and may be ignored.
                          ; The ordering of the header
                          ; fields implied by this BNF
                          ; definition should be ignored.

MIME-part-headers := entity-headers [ fields ] ; Any field not beginning with ; "content-" can have no defined ; meaning and may be ignored. ; The ordering of the header ; fields implied by this BNF ; definition should be ignored.

   The syntax of the various specific MIME header fields will be
   described in the following sections.

The syntax of the various specific MIME header fields will be described in the following sections.

4.  MIME-Version Header Field

4. MIME-Version Header Field

   Since RFC 822 was published in 1982, there has really been only one
   format standard for Internet messages, and there has been little
   perceived need to declare the format standard in use.  This document
   is an independent specification that complements RFC 822.  Although
   the extensions in this document have been defined in such a way as to
   be compatible with RFC 822, there are still circumstances in which it
   might be desirable for a mail-processing agent to know whether a
   message was composed with the new standard in mind.

Since RFC 822 was published in 1982, there has really been only one format standard for Internet messages, and there has been little perceived need to declare the format standard in use. This document is an independent specification that complements RFC 822. Although the extensions in this document have been defined in such a way as to be compatible with RFC 822, there are still circumstances in which it might be desirable for a mail-processing agent to know whether a message was composed with the new standard in mind.

Freed & Borenstein          Standards Track                     [Page 8]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 8] RFC 2045 Internet Message Bodies November 1996

   Therefore, this document defines a new header field, "MIME-Version",
   which is to be used to declare the version of the Internet message
   body format standard in use.

Therefore, this document defines a new header field, "MIME-Version", which is to be used to declare the version of the Internet message body format standard in use.

   Messages composed in accordance with this document MUST include such
   a header field, with the following verbatim text:

Messages composed in accordance with this document MUST include such a header field, with the following verbatim text:

     MIME-Version: 1.0

MIME-Version: 1.0

   The presence of this header field is an assertion that the message
   has been composed in compliance with this document.

The presence of this header field is an assertion that the message has been composed in compliance with this document.

   Since it is possible that a future document might extend the message
   format standard again, a formal BNF is given for the content of the
   MIME-Version field:

Since it is possible that a future document might extend the message format standard again, a formal BNF is given for the content of the MIME-Version field:

     version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

   Thus, future format specifiers, which might replace or extend "1.0",
   are constrained to be two integer fields, separated by a period.  If
   a message is received with a MIME-version value other than "1.0", it
   cannot be assumed to conform with this document.

Thus, future format specifiers, which might replace or extend "1.0", are constrained to be two integer fields, separated by a period. If a message is received with a MIME-version value other than "1.0", it cannot be assumed to conform with this document.

   Note that the MIME-Version header field is required at the top level
   of a message.  It is not required for each body part of a multipart
   entity.  It is required for the embedded headers of a body of type
   "message/rfc822" or "message/partial" if and only if the embedded
   message is itself claimed to be MIME-conformant.

Note that the MIME-Version header field is required at the top level of a message. It is not required for each body part of a multipart entity. It is required for the embedded headers of a body of type "message/rfc822" or "message/partial" if and only if the embedded message is itself claimed to be MIME-conformant.

   It is not possible to fully specify how a mail reader that conforms
   with MIME as defined in this document should treat a message that
   might arrive in the future with some value of MIME-Version other than
   "1.0".

It is not possible to fully specify how a mail reader that conforms with MIME as defined in this document should treat a message that might arrive in the future with some value of MIME-Version other than "1.0".

   It is also worth noting that version control for specific media types
   is not accomplished using the MIME-Version mechanism.  In particular,
   some formats (such as application/postscript) have version numbering
   conventions that are internal to the media format.  Where such
   conventions exist, MIME does nothing to supersede them.  Where no
   such conventions exist, a MIME media type might use a "version"
   parameter in the content-type field if necessary.

It is also worth noting that version control for specific media types is not accomplished using the MIME-Version mechanism. In particular, some formats (such as application/postscript) have version numbering conventions that are internal to the media format. Where such conventions exist, MIME does nothing to supersede them. Where no such conventions exist, a MIME media type might use a "version" parameter in the content-type field if necessary.

Freed & Borenstein          Standards Track                     [Page 9]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 9] RFC 2045 Internet Message Bodies November 1996

   NOTE TO IMPLEMENTORS:  When checking MIME-Version values any RFC 822
   comment strings that are present must be ignored.  In particular, the
   following four MIME-Version fields are equivalent:

NOTE TO IMPLEMENTORS: When checking MIME-Version values any RFC 822 comment strings that are present must be ignored. In particular, the following four MIME-Version fields are 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 mail user agent
   (whether conforming to MIME requirements or not) may optionally
   choose to interpret the body of the message according to local
   conventions.  Many such conventions are currently in use and it
   should be noted that in practice non-MIME messages can contain just
   about anything.

In the absence of a MIME-Version field, a receiving mail user agent (whether conforming to MIME requirements or not) may optionally choose to interpret the body of the message according to local conventions. Many such conventions are currently in use and it should be noted that in practice non-MIME messages can contain just about anything.

   It is impossible to be certain that a non-MIME mail message is
   actually plain text in the US-ASCII character set since it might well
   be a message that, using some set of nonstandard local conventions
   that predate MIME, includes text in another character set or non-
   textual data presented in a manner that cannot be automatically
   recognized (e.g., a uuencoded compressed UNIX tar file).

It is impossible to be certain that a non-MIME mail message is actually plain text in the US-ASCII character set since it might well be a message that, using some set of nonstandard local conventions that predate MIME, includes text in another character set or non- textual data presented in a manner that cannot be automatically recognized (e.g., a uuencoded compressed UNIX tar file).

5.  Content-Type Header Field

5. Content-Type Header Field

   The purpose of the Content-Type field is to describe the data
   contained in the body fully enough that the receiving user agent can
   pick an appropriate agent or mechanism to present the data to the
   user, or otherwise deal with the data in an appropriate manner. The
   value in this field is called a media type.

The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. The value in this field is called a media type.

   HISTORICAL NOTE:  The Content-Type header field was first defined in
   RFC 1049.  RFC 1049 used a simpler and less powerful syntax, but one
   that is largely compatible with the mechanism given here.

HISTORICAL NOTE: The Content-Type header field was first defined in RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one that is largely compatible with the mechanism given here.

   The Content-Type header field specifies the nature of the data in the
   body of an entity by giving media type and subtype identifiers, and
   by providing auxiliary information that may be required for certain
   media types.  After the media type and subtype names, the remainder
   of the header field is simply a set of parameters, specified in an
   attribute=value notation.  The ordering of parameters is not
   significant.

The Content-Type header field specifies the nature of the data in the body of an entity by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the media type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute=value notation. The ordering of parameters is not significant.

Freed & Borenstein          Standards Track                    [Page 10]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 10] RFC 2045 Internet Message Bodies November 1996

   In general, the top-level media type is used to declare the general
   type of data, while the subtype specifies a specific format for that
   type of data.  Thus, a media type of "image/xyz" is enough to tell a
   user agent that the data is an image, even if the user agent has no
   knowledge of the specific image format "xyz".  Such information can
   be used, for example, to decide whether or not to show a user the raw
   data from an unrecognized subtype -- such an action might be
   reasonable for unrecognized subtypes of text, but not for
   unrecognized subtypes of image or audio.  For this reason, registered
   subtypes of text, image, audio, and video should not contain embedded
   information that is really of a different type.  Such compound
   formats should be represented using the "multipart" or "application"
   types.

In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a media type of "image/xyz" is enough to tell a user agent that the data is an image, even if the user agent has no knowledge of the specific image format "xyz". Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype -- such an action might be reasonable for unrecognized subtypes of text, but not for unrecognized subtypes of image or audio. For this reason, registered subtypes of text, image, audio, and video should not contain embedded information that is really of a different type. Such compound formats should be represented using the "multipart" or "application" types.

   Parameters are modifiers of the media subtype, and as such do not
   fundamentally affect the nature of the content.  The set of
   meaningful parameters depends on the media type and subtype.  Most
   parameters are associated with a single specific subtype.  However, a
   given top-level media type may define parameters which are applicable
   to any subtype of that type.  Parameters may be required by their
   defining content type or subtype or they may be optional. MIME
   implementations must ignore any parameters whose names they do not
   recognize.

Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining content type or subtype or they may be optional. MIME implementations must ignore any parameters whose names they do not recognize.

   For example, the "charset" parameter is applicable to any subtype of
   "text", while the "boundary" parameter is required for any subtype of
   the "multipart" media type.

For example, the "charset" parameter is applicable to any subtype of "text", while the "boundary" parameter is required for any subtype of the "multipart" media type.

   There are NO globally-meaningful parameters that apply to all media
   types.  Truly global mechanisms are best addressed, in the MIME
   model, by the definition of additional Content-* header fields.

There are NO globally-meaningful parameters that apply to all media types. Truly global mechanisms are best addressed, in the MIME model, by the definition of additional Content-* header fields.

   An initial set of seven top-level media types is defined in RFC 2046.
   Five of these are discrete types whose content is essentially opaque
   as far as MIME processing is concerned.  The remaining two are
   composite types whose contents require additional handling by MIME
   processors.

An initial set of seven top-level media types is defined in RFC 2046. Five of these are discrete types whose content is essentially opaque as far as MIME processing is concerned. The remaining two are composite types whose contents require additional handling by MIME processors.

   This set of top-level media types is intended to be substantially
   complete.  It is expected that additions to the larger set of
   supported types can generally be accomplished by the creation of new
   subtypes of these initial types.  In the future, more top-level types
   may be defined only by a standards-track extension to this standard.
   If another top-level type is to be used for any reason, it must be
   given a name starting with "X-" to indicate its non-standard status
   and to avoid a potential conflict with a future official name.

This set of top-level media types is intended to be substantially complete. It is expected that additions to the larger set of supported types can generally be accomplished by the creation of new subtypes of these initial types. In the future, more top-level types may be defined only by a standards-track extension to this standard. If another top-level type is to be used for any reason, it must be given a name starting with "X-" to indicate its non-standard status and to avoid a potential conflict with a future official name.

Freed & Borenstein          Standards Track                    [Page 11]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 11] RFC 2045 Internet Message Bodies November 1996

5.1.  Syntax of the Content-Type Header Field

5.1. Syntax of the Content-Type Header Field

   In the Augmented BNF notation of RFC 822, a Content-Type header field
   value is defined as follows:

In the Augmented BNF notation of RFC 822, a Content-Type header field value is defined as follows:

     content := "Content-Type" ":" type "/" subtype
                *(";" parameter)
                ; Matching of media type and subtype
                ; is ALWAYS case-insensitive.

content := "Content-Type" ":" type "/" subtype *(";" parameter) ; Matching of media type and subtype ; is ALWAYS case-insensitive.

     type := discrete-type / composite-type

type := discrete-type / composite-type

     discrete-type := "text" / "image" / "audio" / "video" /
                      "application" / extension-token

discrete-type := "text" / "image" / "audio" / "video" / "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 := <An extension token defined by a
                    standards-track RFC and registered
                    with IANA.>

ietf-token := <An extension token defined by a standards-track RFC and registered with IANA.>

     x-token := <The two characters "X-" or "x-" followed, with
                 no intervening white space, by any token>

x-token := <The two characters "X-" or "x-" followed, with no intervening white space, by any token>

     subtype := extension-token / iana-token

subtype := extension-token / iana-token

     iana-token := <A publicly-defined extension token. Tokens
                    of this form must be registered with IANA
                    as specified in RFC 2048.>

iana-token := <A publicly-defined extension token. Tokens of this form must be registered with IANA as specified in RFC 2048.>

     parameter := attribute "=" value

parameter := attribute "=" value

     attribute := token
                  ; Matching of attributes
                  ; is ALWAYS case-insensitive.

attribute := token ; Matching of attributes ; is ALWAYS case-insensitive.

     value := token / quoted-string

value := token / quoted-string

     token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                 or tspecials>

token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials>

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="
                   ; Must be in quoted-string,
                   ; to use within parameter values

tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" ; Must be in quoted-string, ; to use within parameter values

Freed & Borenstein          Standards Track                    [Page 12]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 12] RFC 2045 Internet Message Bodies November 1996

   Note that the definition of "tspecials" is the same as the RFC 822
   definition of "specials" with the addition of the three characters
   "/", "?", and "=", and the removal of ".".

Note that the definition of "tspecials" is the same as the RFC 822 definition of "specials" with the addition of the three characters "/", "?", and "=", and the removal of ".".

   Note also that a subtype specification is MANDATORY -- it may not be
   omitted from a Content-Type header field.  As such, there are no
   default subtypes.

Note also that a subtype specification is MANDATORY -- it may not be omitted from a Content-Type header field. As such, there are no default subtypes.

   The type, subtype, and parameter names are not case sensitive.  For
   example, TEXT, Text, and TeXt are all equivalent top-level media
   types.  Parameter values are normally case sensitive, but sometimes
   are interpreted in a case-insensitive fashion, depending on the
   intended use.  (For example, multipart boundaries are case-sensitive,
   but the "access-type" parameter for message/External-body is not
   case-sensitive.)

The type, subtype, and parameter names are not case sensitive. For example, TEXT, Text, and TeXt are all equivalent top-level media types. Parameter values are normally case sensitive, but sometimes are interpreted in a case-insensitive fashion, depending on the intended use. (For example, multipart boundaries are case-sensitive, but the "access-type" parameter for message/External-body is not case-sensitive.)

   Note that the value of a quoted string parameter does not include the
   quotes.  That is, the quotation marks in a quoted-string are not a
   part of the value of the parameter, but are merely used to delimit
   that parameter value.  In addition, comments are allowed in
   accordance with RFC 822 rules for structured header fields.  Thus the
   following two forms

Note that the value of a quoted string parameter does not include the quotes. That is, the quotation marks in a quoted-string are not a part of the value of the parameter, but are merely used to delimit that parameter value. In addition, comments are allowed in accordance with RFC 822 rules for structured header fields. Thus the following two forms

     Content-type: text/plain; charset=us-ascii (Plain text)

Content-type: text/plain; charset=us-ascii (Plain text)

     Content-type: text/plain; charset="us-ascii"

Content-type: text/plain; charset="us-ascii"

   are completely equivalent.

are completely equivalent.

   Beyond this syntax, the only syntactic constraint on the definition
   of subtype names is the desire that their uses must not conflict.
   That is, it would be undesirable to have two different communities
   using "Content-Type: application/foobar" to mean two different
   things.  The process of defining new media subtypes, then, is not
   intended to be a mechanism for imposing restrictions, but simply a
   mechanism for publicizing their definition and usage.  There are,
   therefore, two acceptable mechanisms for defining new media subtypes:

Beyond this syntax, the only syntactic constraint on the definition of subtype names is the desire that their uses must not conflict. That is, it would be undesirable to have two different communities using "Content-Type: application/foobar" to mean two different things. The process of defining new media subtypes, then, is not intended to be a mechanism for imposing restrictions, but simply a mechanism for publicizing their definition and usage. There are, therefore, two acceptable mechanisms for defining new media subtypes:

    (1)   Private values (starting with "X-") may be defined
          bilaterally between two cooperating agents without
          outside registration or standardization. Such values
          cannot be registered or standardized.

(1) Private values (starting with "X-") may be defined bilaterally between two cooperating agents without outside registration or standardization. Such values cannot be registered or standardized.

    (2)   New standard values should be registered with IANA as
          described in RFC 2048.

(2) New standard values should be registered with IANA as described in RFC 2048.

   The second document in this set, RFC 2046, defines the initial set of
   media types for MIME.

The second document in this set, RFC 2046, defines the initial set of media types for MIME.

Freed & Borenstein          Standards Track                    [Page 13]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 13] RFC 2045 Internet Message Bodies November 1996

5.2.  Content-Type Defaults

5.2. Content-Type Defaults

   Default RFC 822 messages without a MIME Content-Type header are taken
   by this protocol to be plain text in the US-ASCII character set,
   which can be explicitly specified as:

Default RFC 822 messages without a MIME Content-Type header are taken by this protocol to be plain text in the US-ASCII character set, which can be explicitly specified as:

     Content-type: text/plain; charset=us-ascii

Content-type: text/plain; charset=us-ascii

   This default is assumed if no Content-Type header field is specified.
   It is also recommend that this default be assumed when a
   syntactically invalid Content-Type header field is encountered. In
   the presence of a MIME-Version header field and the absence of any
   Content-Type header field, a receiving User Agent can also assume
   that plain US-ASCII text was the sender's intent.  Plain US-ASCII
   text may still be assumed in the absence of a MIME-Version or the
   presence of an syntactically invalid Content-Type header field, but
   the sender's intent might have been otherwise.

This default is assumed if no Content-Type header field is specified. It is also recommend that this default be assumed when a syntactically invalid Content-Type header field is encountered. In the presence of a MIME-Version header field and the absence of any Content-Type header field, a receiving User Agent can also assume that plain US-ASCII text was the sender's intent. Plain US-ASCII text may still be assumed in the absence of a MIME-Version or the presence of an syntactically invalid Content-Type header field, but the sender's intent might have been otherwise.

6.  Content-Transfer-Encoding Header Field

6. Content-Transfer-Encoding Header Field

   Many media types which could be usefully transported via email are
   represented, in their "natural" format, as 8bit character or binary
   data.  Such data cannot be transmitted over some transfer protocols.
   For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII
   data with lines no longer than 1000 characters including any trailing
   CRLF line separator.

Many media types which could be usefully transported via email are represented, in their "natural" format, as 8bit character or binary data. Such data cannot be transmitted over some transfer protocols. For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII data with lines no longer than 1000 characters including any trailing CRLF line separator.

   It is necessary, therefore, to define a standard mechanism for
   encoding such data into a 7bit short line format.  Proper labelling
   of unencoded material in less restrictive formats for direct use over
   less restrictive transports is also desireable.  This document
   specifies that such encodings will be indicated by a new "Content-
   Transfer-Encoding" header field.  This field has not been defined by
   any previous standard.

It is necessary, therefore, to define a standard mechanism for encoding such data into a 7bit short line format. Proper labelling of unencoded material in less restrictive formats for direct use over less restrictive transports is also desireable. This document specifies that such encodings will be indicated by a new "Content- Transfer-Encoding" header field. This field has not been defined by any previous standard.

6.1.  Content-Transfer-Encoding Syntax

6.1. Content-Transfer-Encoding Syntax

   The Content-Transfer-Encoding field's value is a single token
   specifying the type of encoding, as enumerated below.  Formally:

The Content-Transfer-Encoding field's value is a single token specifying the type of encoding, as enumerated below. Formally:

     encoding := "Content-Transfer-Encoding" ":" mechanism

encoding := "Content-Transfer-Encoding" ":" mechanism

     mechanism := "7bit" / "8bit" / "binary" /
                  "quoted-printable" / "base64" /
                  ietf-token / x-token

mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token

   These values are not case sensitive -- Base64 and BASE64 and bAsE64
   are all equivalent.  An encoding type of 7BIT requires that the body

These values are not case sensitive -- Base64 and BASE64 and bAsE64 are all equivalent. An encoding type of 7BIT requires that the body

Freed & Borenstein          Standards Track                    [Page 14]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 14] RFC 2045 Internet Message Bodies November 1996

   is already in a 7bit mail-ready representation.  This is the default
   value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the
   Content-Transfer-Encoding header field is not present.

is already in a 7bit mail-ready representation. This is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the Content-Transfer-Encoding header field is not present.

6.2.  Content-Transfer-Encodings Semantics

6.2. Content-Transfer-Encodings Semantics

   This single Content-Transfer-Encoding token actually provides two
   pieces of information.  It specifies what sort of encoding
   transformation the body was subjected to and hence what decoding
   operation must be used to restore it to its original form, and it
   specifies what the domain of the result is.

This single Content-Transfer-Encoding token actually provides two pieces of information. It specifies what sort of encoding transformation the body was subjected to and hence what decoding operation must be used to restore it to its original form, and it specifies what the domain of the result is.

   The transformation part of any Content-Transfer-Encodings specifies,
   either explicitly or implicitly, a single, well-defined decoding
   algorithm, which for any sequence of encoded octets either transforms
   it to the original sequence of octets which was encoded, or shows
   that it is illegal as an encoded sequence.  Content-Transfer-
   Encodings transformations never depend on any additional external
   profile information for proper operation. Note that while decoders
   must produce a single, well-defined output for a valid encoding no
   such restrictions exist for encoders: Encoding a given sequence of
   octets to different, equivalent encoded sequences is perfectly legal.

The transformation part of any Content-Transfer-Encodings specifies, either explicitly or implicitly, a single, well-defined decoding algorithm, which for any sequence of encoded octets either transforms it to the original sequence of octets which was encoded, or shows that it is illegal as an encoded sequence. Content-Transfer- Encodings transformations never depend on any additional external profile information for proper operation. Note that while decoders must produce a single, well-defined output for a valid encoding no such restrictions exist for encoders: Encoding a given sequence of octets to different, equivalent encoded sequences is perfectly legal.

   Three transformations are currently defined: identity, the "quoted-
   printable" encoding, and the "base64" encoding.  The domains are
   "binary", "8bit" and "7bit".

Three transformations are currently defined: identity, the "quoted- printable" encoding, and the "base64" encoding. The domains are "binary", "8bit" and "7bit".

   The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all
   mean that the identity (i.e. NO) encoding transformation has been
   performed.  As such, they serve simply as indicators of the domain of
   the body data, and provide useful information about the sort of
   encoding that might be needed for transmission in a given transport
   system.  The terms "7bit data", "8bit data", and "binary data" are
   all defined in Section 2.

The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all mean that the identity (i.e. NO) encoding transformation has been performed. As such, they serve simply as indicators of the domain of the body data, and provide useful information about the sort of encoding that might be needed for transmission in a given transport system. The terms "7bit data", "8bit data", and "binary data" are all defined in Section 2.

   The quoted-printable and base64 encodings transform their input from
   an arbitrary domain into material in the "7bit" range, thus making it
   safe to carry over restricted transports.  The specific definition of
   the transformations are given below.

The quoted-printable and base64 encodings transform their input from an arbitrary domain into material in the "7bit" range, thus making it safe to carry over restricted transports. The specific definition of the transformations are given below.

   The proper Content-Transfer-Encoding label must always be used.
   Labelling unencoded data containing 8bit characters as "7bit" is not
   allowed, nor is labelling unencoded non-line-oriented data as
   anything other than "binary" allowed.

The proper Content-Transfer-Encoding label must always be used. Labelling unencoded data containing 8bit characters as "7bit" is not allowed, nor is labelling unencoded non-line-oriented data as anything other than "binary" allowed.

   Unlike media subtypes, a proliferation of Content-Transfer-Encoding
   values is both undesirable and unnecessary.  However, establishing
   only a single transformation into the "7bit" domain does not seem

Unlike media subtypes, a proliferation of Content-Transfer-Encoding values is both undesirable and unnecessary. However, establishing only a single transformation into the "7bit" domain does not seem

Freed & Borenstein          Standards Track                    [Page 15]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 15] RFC 2045 Internet Message Bodies November 1996

   possible.  There is a tradeoff between the desire for a compact and
   efficient encoding of largely- binary data and the desire for a
   somewhat readable encoding of data that is mostly, but not entirely,
   7bit.  For this reason, at least two encoding mechanisms are
   necessary: a more or less readable encoding (quoted-printable) and a
   "dense" or "uniform" encoding (base64).

possible. There is a tradeoff between the desire for a compact and efficient encoding of largely- binary data and the desire for a somewhat readable encoding of data that is mostly, but not entirely, 7bit. For this reason, at least two encoding mechanisms are necessary: a more or less readable encoding (quoted-printable) and a "dense" or "uniform" encoding (base64).

   Mail transport for unencoded 8bit data is defined in RFC 1652.  As of
   the initial publication of this document, there are no standardized
   Internet mail transports for which it is legitimate to include
   unencoded binary data in mail bodies.  Thus there are no
   circumstances in which the "binary" Content-Transfer-Encoding is
   actually valid in Internet mail.  However, in the event that binary
   mail transport becomes a reality in Internet mail, or when MIME is
   used in conjunction with any other binary-capable mail transport
   mechanism, binary bodies must be labelled as such using this
   mechanism.

Mail transport for unencoded 8bit data is defined in RFC 1652. As of the initial publication of this document, there are no standardized Internet mail transports for which it is legitimate to include unencoded binary data in mail bodies. Thus there are no circumstances in which the "binary" Content-Transfer-Encoding is actually valid in Internet mail. However, in the event that binary mail transport becomes a reality in Internet mail, or when MIME is used in conjunction with any other binary-capable mail transport mechanism, binary bodies must be labelled as such using this mechanism.

   NOTE: The five values defined for the Content-Transfer-Encoding field
   imply nothing about the media type other than the algorithm by which
   it was encoded or the transport system requirements if unencoded.

NOTE: The five values defined for the Content-Transfer-Encoding field imply nothing about the media type other than the algorithm by which it was encoded or the transport system requirements if unencoded.

6.3.  New Content-Transfer-Encodings

6.3. New Content-Transfer-Encodings

   Implementors may, if necessary, define private Content-Transfer-
   Encoding values, but must use an x-token, which is a name prefixed by
   "X-", to indicate its non-standard status, e.g., "Content-Transfer-
   Encoding: x-my-new-encoding".  Additional standardized Content-
   Transfer-Encoding values must be specified by a standards-track RFC.
   The requirements such specifications must meet are given in RFC 2048.
   As such, all content-transfer-encoding namespace except that
   beginning with "X-" is explicitly reserved to the IETF for future
   use.

Implementors may, if necessary, define private Content-Transfer- Encoding values, but must use an x-token, which is a name prefixed by "X-", to indicate its non-standard status, e.g., "Content-Transfer- Encoding: x-my-new-encoding". Additional standardized Content- Transfer-Encoding values must be specified by a standards-track RFC. The requirements such specifications must meet are given in RFC 2048. As such, all content-transfer-encoding namespace except that beginning with "X-" is explicitly reserved to the IETF for future use.

   Unlike media types and subtypes, the creation of new Content-
   Transfer-Encoding values is STRONGLY discouraged, as it seems likely
   to hinder interoperability with little potential benefit

Unlike media types and subtypes, the creation of new Content- Transfer-Encoding values is STRONGLY discouraged, as it seems likely to hinder interoperability with little potential benefit

6.4.  Interpretation and Use

6.4. Interpretation and Use

   If a Content-Transfer-Encoding header field appears as part of a
   message header, it applies to the entire body of that message.  If a
   Content-Transfer-Encoding header field appears as part of an entity's
   headers, it applies only to the body of that entity.  If an entity is
   of type "multipart" the Content-Transfer-Encoding is not permitted to
   have any value other than "7bit", "8bit" or "binary".  Even more
   severe restrictions apply to some subtypes of the "message" type.

If a Content-Transfer-Encoding header field appears as part of a message header, it applies to the entire body of that message. If a Content-Transfer-Encoding header field appears as part of an entity's headers, it applies only to the body of that entity. If an entity is of type "multipart" the Content-Transfer-Encoding is not permitted to have any value other than "7bit", "8bit" or "binary". Even more severe restrictions apply to some subtypes of the "message" type.

Freed & Borenstein          Standards Track                    [Page 16]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 16] RFC 2045 Internet Message Bodies November 1996

   It should be noted that most media types are defined in terms of
   octets rather than bits, so that the mechanisms described here are
   mechanisms for encoding arbitrary octet streams, not bit streams.  If
   a bit stream is to be encoded via one of these mechanisms, it must
   first be converted to an 8bit byte stream using the network standard
   bit order ("big-endian"), in which the earlier bits in a stream
   become the higher-order bits in a 8bit byte.  A bit stream not ending
   at an 8bit boundary must be padded with zeroes. RFC 2046 provides a
   mechanism for noting the addition of such padding in the case of the
   application/octet-stream media type, which has a "padding" parameter.

It should be noted that most media types are defined in terms of octets rather than bits, so that the mechanisms described here are mechanisms for encoding arbitrary octet streams, not bit streams. If a bit stream is to be encoded via one of these mechanisms, it must first be converted to an 8bit byte stream using the network standard bit order ("big-endian"), in which the earlier bits in a stream become the higher-order bits in a 8bit byte. A bit stream not ending at an 8bit boundary must be padded with zeroes. RFC 2046 provides a mechanism for noting the addition of such padding in the case of the application/octet-stream media type, which has a "padding" parameter.

   The encoding mechanisms defined here explicitly encode all data in
   US-ASCII.  Thus, for example, suppose an entity has header fields
   such as:

The encoding mechanisms defined here explicitly encode all data in US-ASCII. Thus, for example, suppose an entity has header fields such as:

     Content-Type: text/plain; charset=ISO-8859-1
     Content-transfer-encoding: base64

Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64

   This must be interpreted to mean that the body is a base64 US-ASCII
   encoding of data that was originally in ISO-8859-1, and will be in
   that character set again after decoding.

This must be interpreted to mean that the body is a base64 US-ASCII encoding of data that was originally in ISO-8859-1, and will be in that character set again after decoding.

   Certain Content-Transfer-Encoding values may only be used on certain
   media types.  In particular, it is EXPRESSLY FORBIDDEN to use any
   encodings other than "7bit", "8bit", or "binary" with any composite
   media type, i.e. one that recursively includes other Content-Type
   fields.  Currently the only composite media types are "multipart" and
   "message".  All encodings that are desired for bodies of type
   multipart or message must be done at the innermost level, by encoding
   the actual body that needs to be encoded.

Certain Content-Transfer-Encoding values may only be used on certain media types. In particular, it is EXPRESSLY FORBIDDEN to use any encodings other than "7bit", "8bit", or "binary" with any composite media type, i.e. one that recursively includes other Content-Type fields. Currently the only composite media types are "multipart" and "message". All encodings that are desired for bodies of type multipart or message must be done at the innermost level, by encoding the actual body that needs to be encoded.

   It should also be noted that, by definition, if a composite entity
   has a transfer-encoding value such as "7bit", but one of the enclosed
   entities has a less restrictive value such as "8bit", then either the
   outer "7bit" labelling is in error, because 8bit data are included,
   or the inner "8bit" labelling placed an unnecessarily high demand on
   the transport system because the actual included data were actually
   7bit-safe.

It should also be noted that, by definition, if a composite entity has a transfer-encoding value such as "7bit", but one of the enclosed entities has a less restrictive value such as "8bit", then either the outer "7bit" labelling is in error, because 8bit data are included, or the inner "8bit" labelling placed an unnecessarily high demand on the transport system because the actual included data were actually 7bit-safe.

   NOTE ON ENCODING RESTRICTIONS:  Though the prohibition against using
   content-transfer-encodings on composite body data may seem overly
   restrictive, it is necessary to prevent nested encodings, in which
   data are passed through an encoding algorithm multiple times, and
   must be decoded multiple times in order to be properly viewed.
   Nested encodings add considerable complexity to user agents:  Aside
   from the obvious efficiency problems with such multiple encodings,
   they can obscure the basic structure of a message.  In particular,
   they can imply that several decoding operations are necessary simply

NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using content-transfer-encodings on composite body data may seem overly restrictive, it is necessary to prevent nested encodings, in which data are passed through an encoding algorithm multiple times, and must be decoded multiple times in order to be properly viewed. Nested encodings add considerable complexity to user agents: Aside from the obvious efficiency problems with such multiple encodings, they can obscure the basic structure of a message. In particular, they can imply that several decoding operations are necessary simply

Freed & Borenstein          Standards Track                    [Page 17]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 17] RFC 2045 Internet Message Bodies November 1996

   to find out what types of bodies a message contains.  Banning nested
   encodings may complicate the job of certain mail gateways, but this
   seems less of a problem than the effect of nested encodings on user
   agents.

to find out what types of bodies a message contains. Banning nested encodings may complicate the job of certain mail gateways, but this seems less of a problem than the effect of nested encodings on user agents.

   Any entity with an unrecognized Content-Transfer-Encoding must be
   treated as if it has a Content-Type of "application/octet-stream",
   regardless of what the Content-Type header field actually says.

Any entity with an unrecognized Content-Transfer-Encoding must be treated as if it has a Content-Type of "application/octet-stream", regardless of what the Content-Type header field actually says.

   NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-TRANSFER-
   ENCODING: It may seem that the Content-Transfer-Encoding could be
   inferred from the characteristics of the media that is to be encoded,
   or, at the very least, that certain Content-Transfer-Encodings could
   be mandated for use with specific media types.  There are several
   reasons why this is not the case. First, given the varying types of
   transports used for mail, some encodings may be appropriate for some
   combinations of media types and transports but not for others.  (For
   example, in an 8bit transport, no encoding would be required for text
   in certain character sets, while such encodings are clearly required
   for 7bit SMTP.)

NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-TRANSFER- ENCODING: It may seem that the Content-Transfer-Encoding could be inferred from the characteristics of the media that is to be encoded, or, at the very least, that certain Content-Transfer-Encodings could be mandated for use with specific media types. There are several reasons why this is not the case. First, given the varying types of transports used for mail, some encodings may be appropriate for some combinations of media types and transports but not for others. (For example, in an 8bit transport, no encoding would be required for text in certain character sets, while such encodings are clearly required for 7bit SMTP.)

   Second, certain media types may require different types of transfer
   encoding under different circumstances.  For example, many PostScript
   bodies might consist entirely of short lines of 7bit data and hence
   require no encoding at all.  Other PostScript bodies (especially
   those using Level 2 PostScript's binary encoding mechanism) may only
   be reasonably represented using a binary transport encoding.
   Finally, since the Content-Type field is intended to be an open-ended
   specification mechanism, strict specification of an association
   between media types and encodings effectively couples the
   specification of an application protocol with a specific lower-level
   transport.  This is not desirable since the developers of a media
   type should not have to be aware of all the transports in use and
   what their limitations are.

Second, certain media types may require different types of transfer encoding under different circumstances. For example, many PostScript bodies might consist entirely of short lines of 7bit data and hence require no encoding at all. Other PostScript bodies (especially those using Level 2 PostScript's binary encoding mechanism) may only be reasonably represented using a binary transport encoding. Finally, since the Content-Type field is intended to be an open-ended specification mechanism, strict specification of an association between media types and encodings effectively couples the specification of an application protocol with a specific lower-level transport. This is not desirable since the developers of a media type should not have to be aware of all the transports in use and what their limitations are.

6.5.  Translating Encodings

6.5. Translating Encodings

   The quoted-printable and base64 encodings are designed so that
   conversion between them is possible.  The only issue that arises in
   such a conversion is the handling of hard line breaks in quoted-
   printable encoding output. When converting from quoted-printable to
   base64 a hard line break in the quoted-printable form represents a
   CRLF sequence in the canonical form of the data. It must therefore be
   converted to a corresponding encoded CRLF in the base64 form of the
   data.  Similarly, a CRLF sequence in the canonical form of the data
   obtained after base64 decoding must be converted to a quoted-
   printable hard line break, but ONLY when converting text data.

The quoted-printable and base64 encodings are designed so that conversion between them is possible. The only issue that arises in such a conversion is the handling of hard line breaks in quoted- printable encoding output. When converting from quoted-printable to base64 a hard line break in the quoted-printable form represents a CRLF sequence in the canonical form of the data. It must therefore be converted to a corresponding encoded CRLF in the base64 form of the data. Similarly, a CRLF sequence in the canonical form of the data obtained after base64 decoding must be converted to a quoted- printable hard line break, but ONLY when converting text data.

Freed & Borenstein          Standards Track                    [Page 18]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 18] RFC 2045 Internet Message Bodies November 1996

6.6.  Canonical Encoding Model

6.6. Canonical Encoding Model

   There was some confusion, in the previous versions of this RFC,
   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, and the relationship
   between content-transfer-encodings and character sets.  A canonical
   model for encoding is presented in RFC 2049 for this reason.

There was some confusion, in the previous versions of this RFC, 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, and the relationship between content-transfer-encodings and character sets. A canonical model for encoding is presented in RFC 2049 for this reason.

6.7.  Quoted-Printable Content-Transfer-Encoding

6.7. Quoted-Printable Content-Transfer-Encoding

   The Quoted-Printable encoding is intended to represent data that
   largely consists of octets that correspond to printable characters in
   the US-ASCII character set.  It encodes the data in such a way that
   the resulting octets are unlikely to be modified by mail transport.
   If the data being encoded are mostly US-ASCII text, the encoded form
   of the data remains largely recognizable by humans.  A body which is
   entirely US-ASCII may also be encoded in Quoted-Printable to ensure
   the integrity of the data should the message pass through a
   character-translating, and/or line-wrapping gateway.

The Quoted-Printable encoding is intended to represent data that largely consists of octets that correspond to printable characters in the US-ASCII character set. It encodes the data in such a way that the resulting octets are unlikely to be modified by mail transport. If the data being encoded are mostly US-ASCII text, the encoded form of the data remains largely recognizable by humans. A body which is entirely US-ASCII may also be encoded in Quoted-Printable to ensure the integrity of the data should the message pass through a character-translating, and/or line-wrapping gateway.

   In this encoding, octets are to be represented as determined by the
   following rules:

In this encoding, octets are to be represented as determined by the following rules:

    (1)   (General 8bit representation) Any octet, except a CR or
          LF that is part of a CRLF line break of the canonical
          (standard) form of the data being encoded, may be
          represented by an "=" followed by a two digit
          hexadecimal representation of the octet's value.  The
          digits of the hexadecimal alphabet, for this purpose,
          are "0123456789ABCDEF".  Uppercase letters must be
          used; lowercase letters are not allowed.  Thus, for
          example, the decimal value 12 (US-ASCII form feed) can
          be represented by "=0C", and the decimal value 61 (US-
          ASCII EQUAL SIGN) can be represented by "=3D".  This
          rule must be followed except when the following rules
          allow an alternative encoding.

(1) (General 8bit representation) Any octet, except a CR or LF that is part of a CRLF line break of the canonical (standard) form of the data being encoded, may be represented by an "=" followed by a two digit hexadecimal representation of the octet's value. The digits of the hexadecimal alphabet, for this purpose, are "0123456789ABCDEF". Uppercase letters must be used; lowercase letters are not allowed. Thus, for example, the decimal value 12 (US-ASCII form feed) can be represented by "=0C", and the decimal value 61 (US- ASCII EQUAL SIGN) can be represented by "=3D". This rule must be followed except when the following rules allow an alternative encoding.

    (2)   (Literal representation) Octets with decimal values of
          33 through 60 inclusive, and 62 through 126, inclusive,
          MAY be represented as the US-ASCII characters which
          correspond to those octets (EXCLAMATION POINT through
          LESS THAN, and GREATER THAN through TILDE,
          respectively).

(2) (Literal representation) Octets with decimal values of 33 through 60 inclusive, and 62 through 126, inclusive, MAY be represented as the US-ASCII characters which correspond to those octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN through TILDE, respectively).

    (3)   (White Space) Octets with values of 9 and 32 MAY be
          represented as US-ASCII TAB (HT) and SPACE characters,

(3) (White Space) Octets with values of 9 and 32 MAY be represented as US-ASCII TAB (HT) and SPACE characters,

Freed & Borenstein          Standards Track                    [Page 19]

RFC 2045                Internet Message Bodies            November 1996

Freed & Borenstein Standards Track [Page 19] RFC 2045 Internet Message Bodies November 1996

          respectively, but MUST NOT be so represented at the end
          of an encoded line.  Any TAB (HT) or SPACE characters
          on an encoded line MUST thus be followed on that line
          by a printable character.  In particular, an "=" at the
          end of an encoded line, indicating a soft line break
          (see rule #5) may follow one or more TAB (HT) or SPACE
          characters.  It follows that an octet with decimal
          value 9 or 32 appearing at the end of an encoded line
          must be represented according to Rule #1.  This rule is
          necessary because some MTAs (Message Transport Agents,
          programs which transport messages from one user to
          another, or perform a portion of such transfers) are
          known to pad lines of text with SPACEs, and others are
          known to remove "white space" characters from the end
          of a line.  Therefore, when decoding a Quoted-Printable
          body, any trailing white space on a line must be
          deleted, as it will necessarily have been added by
          intermediate transport agents.

それぞれ、コード化された行の終わりに非常に表されてはいけません。 その結果、印刷可能なキャラクタはその線の上でコード化された線の上のどんなTAB(HT)やSPACEキャラクタにもついて来なければなりません。 特にコード化された行の終わりの「=」、柔らかいラインブレイク(規則#5を見る)を示すと、1つ以上のタブ(HT)か間隔文字が従われるかもしれません。 Rule#1に従ってコード化された行の終わりに現れるデシマル値9か32がある八重奏を表さなければならないということになります。 いくつかのMTAs(メッセージTransportエージェント、1人のユーザから別のユーザまでメッセージを輸送するか、またはそのような転送の部分を実行するプログラム)がSPACEsと共にテキストの線を水増しするのが知られていて、他のものが線の端から「余白」キャラクタを外すのが知られるので、この規則が必要です。 したがって、Quoted印刷可能なボディーを解読するとき、線の上のどんな引きずっている余白も削除しなければなりません、それが必ず中間的輸送エージェントによって加えられてしまうだろうというとき。

    (4)   (Line Breaks) A line break in a text body, represented
          as a CRLF sequence in the text canonical form, must be
          represented by a (RFC 822) line break, which is also a
          CRLF sequence, in the Quoted-Printable encoding.  Since
          the canonical representation of media types other than
          text do not generally include the representation of
          line breaks as CRLF sequences, no hard line breaks
          (i.e. line breaks that are intended to be meaningful
          and to be displayed to the user) can occur in the
          quoted-printable encoding of such types.  Sequences
          like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely
          appear in non-text data represented in quoted-
          printable, of course.

(4) (RFC822)ラインブレイクでCRLF系列としてテキスト標準形に表されたテキスト本文の(線Breaks)ラインブレイクを表さなければなりません、Quoted印刷可能なコード化で。(また、ラインブレイクはCRLF系列です)。 メディアの正準な代理以来、一般に、テキスト以外のタイプはCRLF系列としてラインブレイクの表現を入れないで、どんな困難なラインブレイク(すなわち、重要であり、ユーザに表示されることを意図するラインブレイク)もそのようなタイプの引用されて印刷可能なコード化で起こることができません。 「=0A」という「=0D」のような系列が「0A=0Dと等しく」、「=0D=0A」が引用されるところに表された非テキストデータできまりきって印刷可能に見える、もちろん。

          Note that many implementations may elect to encode the
          local representation of various content types directly
          rather than converting to canonical form first,
          encoding, and then converting back to local
          representation.  In particular, this may apply to plain
          text material on systems that use newline conventions
          other than a CRLF terminator sequence.  Such an
          implementation optimization is permissible, but only
          when the combined canonicalization-encoding step is
          equivalent to performing the three steps separately.

多くの実現が、最初に標準形に変えるより直接むしろ様々な満足しているタイプのローカルの表現をコード化するのを選ぶかもしれないことに注意してください、ローカルの表現への後部をコード化して、次に、変換して。 特に、これはCRLF終了配列以外のニューラインコンベンションを使用するシステムの上のプレーンテキストの材料に適用されるかもしれません。 結合したcanonicalizationをコード化しているステップが別々に3ステップを実行するのに同等であるときにだけ、そのような実現最適化は許されています。

    (5)   (Soft Line Breaks) The Quoted-Printable encoding
          REQUIRES that encoded lines be no more than 76
          characters long.  If longer lines are to be encoded
          with the Quoted-Printable encoding, "soft" line breaks

(5) 76未満のキャラクタが長かったなら、それがコード化した(柔らかい線Breaks)Quoted印刷可能なコード化REQUIRESは立ち並んでいます。 より長い線がQuoted印刷可能なコード化していて、「柔らかい」ラインブレイクでコード化されることであるなら

Freed & Borenstein          Standards Track                    [Page 20]

RFC 2045                Internet Message Bodies            November 1996

解放されるのとBorenstein規格はインターネットメッセージボディー1996年11月にRFC2045を追跡します[20ページ]。

          must be used.  An equal sign as the last character on a
          encoded line indicates such a non-significant ("soft")
          line break in the encoded text.

使用しなければなりません。 コード化された線の上の最後のキャラクタとしての等号はコード化されたテキストのそのような非重要な(「柔らかい」)ラインブレイクを示します。

   Thus if the "raw" form of the line is a single unencoded line that
   says:

したがって、線の「生」のフォームがただ一つの暗号化されていない線であるなら、それは言います:

     Now's the time for all folk to come to the aid of their country.

現在は彼らの国の援助へのすべての人々の来たる時間です。

   This can be represented, in the Quoted-Printable encoding, as:

以下としてQuoted印刷可能なコード化でこれを表すことができます。

     Now's the time =
     for all folk to come=
      to the aid of their country.

現在はすべての人々の来たる時間=です。彼らの国の援助への=。

   This provides a mechanism with which long lines are encoded in such a
   way as to be restored by the user agent.  The 76 character limit does
   not count the trailing CRLF, but counts all other characters,
   including any equal signs.

これはユーザエージェントによって回復されるほど長い線がそのような方法でコード化されるメカニズムを提供します。 76キャラクタ限界は、引きずっているCRLFを数えませんが、どんな等号も含む他のすべてのキャラクタを数えます。

   Since the hyphen character ("-") may be represented as itself in the
   Quoted-Printable encoding, care must be taken, when encapsulating a
   quoted-printable encoded body inside one or more multipart entities,
   to ensure that the boundary delimiter does not appear anywhere in the
   encoded body.  (A good strategy is to choose a boundary that includes
   a character sequence such as "=_" which can never appear in a
   quoted-printable body.  See the definition of multipart messages in
   RFC 2046.)

ハイフンキャラクタ(「-」)がそれ自体として引用されて印刷可能なコード化で代理をされるかもしれないので、境界デリミタがコード化されたボディーで何処にも現れないのを保証するために1つ以上の複合実体で引用されて印刷可能なコード化されたボディーを要約するとき、注意しなければなりません。 (優れた戦略は引用されて印刷可能なボディーに決して現れることができない「=_」などのキャラクタシーケンスを含んでいる境界を選ぶことです。 RFC2046との複合メッセージの定義を見てください。)

   NOTE: The quoted-printable encoding represents something of a
   compromise between readability and reliability in transport.  Bodies
   encoded with the quoted-printable encoding will work reliably over
   most mail gateways, but may not work perfectly over a few gateways,
   notably those involving translation into EBCDIC.  A higher level of
   confidence is offered by the base64 Content-Transfer-Encoding.  A way
   to get reasonably reliable transport through EBCDIC gateways is to
   also quote the US-ASCII characters

以下に注意してください。 引用されて印刷可能なコード化は読み易さと信頼性の間の輸送におけるある種の妥協を表します。 数ゲートウェイ(著しくEBCDICへの翻訳にかかわるもの)の上で完全に働かないかもしれないのを除いて、引用されて印刷可能なコード化でコード化されたボディーはほとんどのメール・ゲートウェイより確かにやり直すでしょう。 base64 Content転送コード化で、より高いレベルの信用を提供します。 合理的に信頼できる輸送をEBCDICゲートウェイに通す方法はまた、米国-ASCII文字を引用することです。

     !"#$@[\]^`{|}~

!"#$@[\]^`{|}~

   according to rule #1.

規則#1に従って。

   Because quoted-printable data is generally assumed to be line-
   oriented, it is to be expected that the representation of the breaks
   between the lines of quoted-printable data may be altered in
   transport, in the same manner that plain text mail has always been
   altered in Internet mail when passing between systems with differing
   newline conventions.  If such alterations are likely to constitute a

引用されて印刷可能なデータが適応する線であると一般に思われるので、引用されて印刷可能なデータの線の間の中断の表現が輸送で変更されるかもしれないと予想されることになっていて、異なったニューラインコンベンションと共にシステムの間を通るとき、同じ方法で、そのプレーンテキストメールはインターネット・メールでいつも変更されていました。 そのような変更がaを構成しそうであるなら

Freed & Borenstein          Standards Track                    [Page 21]

RFC 2045                Internet Message Bodies            November 1996

解放されるのとBorenstein規格はインターネットメッセージボディー1996年11月にRFC2045を追跡します[21ページ]。

   corruption of the data, it is probably more sensible to use the
   base64 encoding rather than the quoted-printable encoding.

不正である、データでは、引用されて印刷可能なコード化よりむしろbase64コード化を使用するのはたぶんさらに分別があります。

   NOTE: Several kinds of substrings cannot be generated according to
   the encoding rules for the quoted-printable content-transfer-
   encoding, and hence are formally illegal if they appear in the output
   of a quoted-printable encoder. This note enumerates these cases and
   suggests ways to handle such illegal substrings if any are
   encountered in quoted-printable data that is to be decoded.

以下に注意してください。 数種類のサブストリングは、引用されて印刷可能な満足している転送コード化のための符号化規則に応じて発生できないで、したがって、引用されて印刷可能なエンコーダの出力に現れるなら、正式に不法です。 この注意は、これらのケースを数え上げて、もしあればそのような不法なサブストリングを扱う方法が解読されることになっている引用されて印刷可能なデータで遭遇するのを示します。

    (1)   An "=" followed by two hexadecimal digits, one or both
          of which are lowercase letters in "abcdef", is formally
          illegal. A robust implementation might choose to
          recognize them as the corresponding uppercase letters.

(1) それの1か両方が"abcdef"の小文字である2つの16進数字があとに続いた「=」は正式に不法です。 体力を要している実現は、それらが対応する大文字であると認めるのを選ぶかもしれません。

    (2)   An "=" followed by a character that is neither a
          hexadecimal digit (including "abcdef") nor the CR
          character of a CRLF pair is illegal.  This case can be
          the result of US-ASCII text having been included in a
          quoted-printable part of a message without itself
          having been subjected to quoted-printable encoding.  A
          reasonable approach by a robust implementation might be
          to include the "=" character and the following
          character in the decoded data without any
          transformation and, if possible, indicate to the user
          that proper decoding was not possible at this point in
          the data.

(2) 16進数字("abcdef"を含んでいる)でなくてまた1CRLF組のCRキャラクタでないキャラクタによって後をつけられた「=」は不法です。 本件は引用されて印刷可能なコード化にかけられたメッセージの引用されて印刷可能な部分にそれ自体なしで含まれている米国-ASCIIテキストの結果であるかもしれません。 体力を要している実現による合理的なアプローチは、解読されたデータで少しも変化なしで「=」キャラクタと以下のキャラクタを含めて、できれば、適切な解読がここにデータで可能でなかったのをユーザに示すことであるかもしれません。

    (3)   An "=" cannot be the ultimate or penultimate character
          in an encoded object.  This could be handled as in case
          (2) above.

(3) 「=」はコード化された物の究極の、または、終わりから二番目ののキャラクタであるはずがありません。 上のケース(2)のようにこれを扱うことができました。

    (4)   Control characters other than TAB, or CR and LF as
          parts of CRLF pairs, must not appear. The same is true
          for octets with decimal values greater than 126.  If
          found in incoming quoted-printable data by a decoder, a
          robust implementation might exclude them from the
          decoded data and warn the user that illegal characters
          were discovered.

(4) CRLF組の部分としてのTABか、CRとLF以外の制御文字は現れてはいけません。 八重奏に、同じくらいはデシマル値より多くの126で本当です。 入って来る引用されて印刷可能なデータでデコーダによって当たられるなら、体力を要している実現は、解読されたデータにそれらを入れないようにして、違法キャラクタが発見されたとユーザに警告するかもしれません。

    (5)   Encoded lines must not be longer than 76 characters,
          not counting the trailing CRLF. If longer lines are
          found in incoming, encoded data, a robust
          implementation might nevertheless decode the lines, and
          might report the erroneous encoding to the user.

(5) コード化された線は引きずっているCRLFを数えるのではなく、76のキャラクタより長いはずがありません。 より長い線が入って来て、コード化されたデータで見つけられるなら、体力を要している実現は、それにもかかわらず、線を解読して、ユーザへの誤ったコード化を報告するかもしれません。

Freed & Borenstein          Standards Track                    [Page 22]

RFC 2045                Internet Message Bodies            November 1996

解放されるのとBorenstein規格はインターネットメッセージボディー1996年11月にRFC2045を追跡します[22ページ]。

   WARNING TO IMPLEMENTORS:  If binary data is encoded in quoted-
   printable, care must be taken to encode CR and LF characters as "=0D"
   and "=0A", respectively.  In particular, a CRLF sequence in binary
   data should be encoded as "=0D=0A".  Otherwise, if CRLF were
   represented as a hard line break, it might be incorrectly decoded on
   platforms with different line break conventions.

作成者への警告: 2進のデータがコード化されたコネが、「=0D」としてCRとLFキャラクタをコード化して、「0Aと等しい」ように印刷可能であることで、注意しなければならないのをそれぞれ引用したということであるなら。 特に、2進のデータのCRLF系列は「=0D=0A」としてコード化されるべきです。 さもなければ、CRLFが困難なラインブレイクとして表されるなら、それは異なったラインブレイクコンベンションと共にプラットホームで不当に解読されるでしょうに。

   For formalists, the syntax of quoted-printable data is described by
   the following grammar:

形式主義者に関しては、引用されて印刷可能なデータの構文は以下の文法によって説明されます:

     quoted-printable := qp-line *(CRLF qp-line)

引用されて印刷可能な:=qp-線*(CRLF qp-線)

     qp-line := *(qp-segment transport-padding CRLF)
                qp-part transport-padding

qp-線:=*(輸送をそっと歩くqp-セグメントCRLF)qp-部分輸送詰め物

     qp-part := qp-section
                ; Maximum length of 76 characters

qp-部分:=qp-部。 76のキャラクタの最大の長さ

     qp-segment := qp-section *(SPACE / TAB) "="
                   ; Maximum length of 76 characters

qp-セグメント:=qp-セクション*(SPACE / TAB)「=」。 76のキャラクタの最大の長さ

     qp-section := [*(ptext / SPACE / TAB) ptext]

qp-セクション:=[*(ptext/SPACE/TAB)ptext]

     ptext := hex-octet / safe-char

安全なptext:=十六進法八重奏/炭

     safe-char := <any octet with decimal value of 33 through
                  60 inclusive, and 62 through 126>
                  ; Characters not listed as "mail-safe" in
                  ; RFC 2049 are also not recommended.

そして、包括的に小数があるどんな八重奏も評価する33〜60の:=<が金庫で焦げてください、126>を通した62。 キャラクターは中で「メール安全である」として記載しませんでした。 また、RFC2049は推薦されません。

     hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
                  ; Octet must be used for characters > 127, =,
                  ; SPACEs or TABs at the ends of lines, and is
                  ; recommended for any character not listed in
                  ; RFC 2049 as "mail-safe".

十六進法八重奏:=「=」2(/「B」/ケタ/「C」/「D」/「E」/「F」)。 キャラクタ>127、=に八重奏を使用しなければなりません。 そして、行の終わりのSPACEsかTABs、あります。 記載されなかった少しのキャラクタのためにも、推薦されます。 「メール金庫」としてのRFC2049。

     transport-padding := *LWSP-char
                          ; Composers MUST NOT generate
                          ; non-zero length transport
                          ; padding, but receivers MUST
                          ; be able to handle padding
                          ; added by message transports.

輸送をそっと歩く:=*LWSP-炭。 作曲家、発生してはいけません。 非ゼロ・レングス輸送。 しかし、詰め物、受信機はそうしなければなりません。 詰め物を扱うことができてください。 メッセージ転送で、加えられます。

   IMPORTANT:  The addition of LWSP between the elements shown in this
   BNF is NOT allowed since this BNF does not specify a structured
   header field.

重要: このBNFが構造化されたヘッダーフィールドを指定しないので、このBNFで見せられた要素の間のLWSPの添加は許されていません。

Freed & Borenstein          Standards Track                    [Page 23]

RFC 2045                Internet Message Bodies            November 1996

解放されるのとBorenstein規格はインターネットメッセージボディー1996年11月にRFC2045を追跡します[23ページ]。

6.8.  Base64 Content-Transfer-Encoding

6.8. Base64の満足している転送コード化

   The Base64 Content-Transfer-Encoding is designed to represent
   arbitrary sequences of octets in a form that need not be humanly
   readable.  The encoding and decoding algorithms are simple, but the
   encoded data are consistently only about 33 percent larger than the
   unencoded data.  This encoding is virtually identical to the one used
   in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.

Base64 Content転送コード化は、人間的に読み込み可能である必要はないフォームでの八重奏の気紛れな順番を表すように設計されています。 コード化とアルゴリズムを解読するのが簡単ですが、コード化されたデータは暗号化されていないデータより一貫しておよそ33パーセント大きいだけです。 このコード化は実際にはRFC1421で定義されるようにPrivacy Enhancedメール(PEM)アプリケーションで使用されるものと同じです。

   A 65-character subset of US-ASCII is used, enabling 6 bits to be
   represented per printable character. (The extra 65th character, "=",
   is used to signify a special processing function.)

6ビットが印刷可能なキャラクタ単位で表されるのを可能にして、米国-ASCIIの65文字サブセットが使用されています。 (「=」という65番目の余分なキャラクタは特別な処理機能を意味するのに使用されます。)

   NOTE:  This subset has the important property that it is represented
   identically in all versions of ISO 646, including US-ASCII, and all
   characters in the subset are also represented identically in all
   versions of EBCDIC. Other popular encodings, such as the encoding
   used by the uuencode utility, Macintosh binhex 4.0 [RFC-1741], and
   the base85 encoding specified as part of Level 2 PostScript, do not
   share these properties, and thus do not fulfill the portability
   requirements a binary transport encoding for mail must meet.

以下に注意してください。 この部分集合には、同様にISO646のすべてのバージョンに表されて、米国-ASCIIを含んでいて、重要な特性があります、そして、また、部分集合のすべてのキャラクタが同様にEBCDICのすべてのバージョンで代理をされます。 uuencodeユーティリティ、マッキントッシュbinhex4.0[RFC-1741]、およびbase85コード化で使用されるコード化などの他のポピュラーなencodingsはLevelの一部として2つのポストスクリプトを指定して、これらの特性を共有しないで、またその結果、メールのためにコード化される2進の輸送に満たされなければならないという携帯性要件を実現させません。

   The encoding process represents 24-bit groups of input bits as output
   strings of 4 encoded characters.  Proceeding from left to right, a
   24-bit input group is formed by concatenating 3 8bit input groups.
   These 24 bits are then treated as 4 concatenated 6-bit groups, each
   of which is translated into a single digit in the base64 alphabet.
   When encoding a bit stream via the base64 encoding, the bit stream
   must be presumed to be ordered with the most-significant-bit first.
   That is, the first bit in the stream will be the high-order bit in
   the first 8bit byte, and the eighth bit will be the low-order bit in
   the first 8bit byte, and so on.

4の出力ストリングがキャラクタをコード化したので、コード化の過程は入力ビットの24ビットのグループを代表します。 左から右まで続いて、24ビットの入力グループは、3 8ビットの入力グループを連結することによって、結成されます。 そして、4が6ビットのグループ(それのそれぞれがbase64アルファベットの一桁に翻訳される)を連結したので、これらの24ビットは扱われます。 base64コード化を通して流れを少しコード化するとき、ビットストリームは最初に、あえて最も重要なビットで命令されなければなりません。 すなわち、流れにおける最初のビットは最初の8ビットのバイトで高位のビットになるでしょう、そして、8番目のビットは最初の8ビットのバイト、などに下位のビットになるでしょう。

   Each 6-bit group is used as an index into an array of 64 printable
   characters.  The character referenced by the index is placed in the
   output string.  These characters, identified in Table 1, below, are
   selected so as to be universally representable, and the set excludes
   characters with particular significance to SMTP (e.g., ".", CR, LF)
   and to the multipart boundary delimiters defined in RFC 2046 (e.g.,
   "-").

それぞれの6ビットのグループはインデックスとして64の印刷可能なキャラクタのアレイに使用されます。 インデックスによって参照をつけられるキャラクタは出力ストリングに置かれます。 「これらの以下のTable1で特定されたキャラクタが一般に「表-可能」になるように選ばれて、セットが特定の意味でSMTPまでキャラクタを除く、(例えば」、」、CR、LF) そして、RFC2046(例えば、「-」)で複合境界デリミタと定義されています。

Freed & Borenstein          Standards Track                    [Page 24]

RFC 2045                Internet Message Bodies            November 1996

解放されるのとBorenstein規格はインターネットメッセージボディー1996年11月にRFC2045を追跡します[24ページ]。

                    Table 1: The Base64 Alphabet

テーブル1: Base64アルファベット

     Value Encoding  Value Encoding  Value Encoding  Value Encoding
         0 A            17 R            34 i            51 z
         1 B            18 S            35 j            52 0
         2 C            19 T            36 k            53 1
         3 D            20 U            37 l            54 2
         4 E            21 V            38 m            55 3
         5 F            22 W            39 n            56 4
         6 G            23 X            40 o            57 5
         7 H            24 Y            41 p            58 6
         8 I            25 Z            42 q            59 7
         9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 +
        12 M            29 d            46 u            63 /
        13 N            30 e            47 v
        14 O            31 f            48 w         (pad) =
        15 P            32 g            49 x
        16 Q            33 h            50 y

評価..18秒間..C..44秒間..パッド..33時間

   The encoded output stream must be represented in lines of no more
   than 76 characters each.  All line breaks or other characters not
   found in Table 1 must be ignored by decoding software.  In base64
   data, characters other than those in Table 1, line breaks, and other
   white space probably indicate a transmission error, about which a
   warning message or even a message rejection might be appropriate
   under some circumstances.

それぞれ76未満のキャラクタの線でコード化された出力ストリームを表さなければなりません。 ソフトウェアを解読することによって、Table1で見つけられなかったすべてのラインブレイクか他のキャラクタを無視しなければなりません。 base64データでは、Table1のそれら以外のキャラクタ、ラインブレイク、および他の余白はたぶん伝送エラーを示します。(警告メッセージかメッセージ拒絶さえそれに関していくつかの状況で適切であるかもしれません)。

   Special processing is performed if fewer than 24 bits are available
   at the end of the data being encoded.  A full encoding quantum is
   always completed at the end of a body.  When fewer than 24 input bits
   are available in an input group, zero bits are added (on the right)
   to form an integral number of 6-bit groups.  Padding at the end of
   the data is performed using the "=" character.  Since all base64
   input is an integral number of octets, only the following cases can
   arise: (1) the final quantum of encoding input is an integral
   multiple of 24 bits; here, the final unit of encoded output will be
   an integral multiple of 4 characters with no "=" padding, (2) the
   final quantum of encoding input is exactly 8 bits; here, the final
   unit of encoded output will be two characters followed by two "="
   padding characters, or (3) the final quantum of encoding input is
   exactly 16 bits; here, the final unit of encoded output will be three
   characters followed by one "=" padding character.

24ビット未満がコード化されるデータの終わりで有効であるなら、特別な処理は実行されます。 完全なコード化量子はいつもボディーの先に完成します。 24入力ビット未満が入力グループで有効であるときに、ゼロ・ビットは、整数の6ビットのグループを結成するために加えられます(右で)。 データの終わりでそっと歩くのは、「=」キャラクタを使用することで実行されます。 すべてのbase64入力が整数の八重奏であるので、以下のケースしか起こることができません: (1) 入力をコード化する最終的な量子は24ビットの不可欠の倍数です。 (2) ここで、コード化された出力の最終的なユニットが「=」が全くそっと歩いていない4つのキャラクタの不可欠の倍数になる、入力をコード化する最終的な量子はちょうど8ビットです。 (3) ここで、コード化された出力の最終的なユニットは2人の「=」暫定記号によっていうことになられた2つのキャラクタになるだろうか、入力をコード化する最終的な量子はまさに16ビットです。 ここで、コード化された出力の最終的なユニットは1人の「=」暫定記号によっていうことになられた3つのキャラクタになるでしょう。

   Because it is used only for padding at the end of the data, the
   occurrence of any "=" characters may be taken as evidence that the
   end of the data has been reached (without truncation in transit).  No

それがデータの終わりでそっと歩くのにだけ使用されるので、どんな「=」キャラクタの発生もデータの端に達したという(トランジットにおけるトランケーションなしで)証拠としてみなされるかもしれません。 いいえ

Freed & Borenstein          Standards Track                    [Page 25]

RFC 2045                Internet Message Bodies            November 1996

解放されるのとBorenstein規格はインターネットメッセージボディー1996年11月にRFC2045を追跡します[25ページ]。

   such assurance is possible, however, when the number of octets
   transmitted was a multiple of three and no "=" characters are
   present.

そのような保証が可能である、しかしながら、八重奏の数が3が倍数があって、いいえと伝えたとき、「=」キャラクタは出席しています。

   Any characters outside of the base64 alphabet are to be ignored in
   base64-encoded data.

base64アルファベットにおける外部のどんなキャラクタもbase64によってコード化されたデータで無視されることになっています。

   Care must be taken to use the proper octets for line breaks if base64
   encoding is applied directly to text material that has not been
   converted to canonical form.  In particular, text line breaks must be
   converted into CRLF sequences prior to base64 encoding.  The
   important thing to note is that this may be done directly by the
   encoder rather than in a prior canonicalization step in some
   implementations.

base64コード化が直接テキストの材料に適用されて、それが標準形に変換されていないということであるなら、ラインブレイクに適切な八重奏を使用するために注意しなければなりません。 特に、base64コード化の前にテキストラインブレイクをCRLF系列に変換しなければなりません。 注意する重要なことは直接先のcanonicalizationステップでというよりむしろエンコーダでいくつかの実現でこれをするかもしれないということです。

   NOTE: There is no need to worry about quoting potential boundary
   delimiters within base64-encoded bodies within multipart entities
   because no hyphen characters are used in the base64 encoding.

以下に注意してください。 ハイフンキャラクタが全くbase64コード化に使用されないので複合実体の中でbase64によってコード化されたボディーの中で潜在的境界デリミタを引用するのを心配する必要は全くありません。

7.  Content-ID Header Field

7. コンテントIDヘッダーフィールド

   In constructing a high-level user agent, it may be desirable to allow
   one body to make reference to another.  Accordingly, bodies may be
   labelled using the "Content-ID" header field, which is syntactically
   identical to the "Message-ID" header field:

ハイレベルのユーザエージェントを組み立てるのにおいて、1つのボディーが別のものについて言及するのを許容するのは望ましいかもしれません。 それに従って、ボディーはシンタクス上「Message ID」ヘッダーフィールドと同じ「コンテントID」ヘッダーフィールドを使用することでラベルされるかもしれません:

     id := "Content-ID" ":" msg-id

「イド:=「コンテントID」」:、」 msg-イド

   Like the Message-ID values, Content-ID values must be generated to be
   world-unique.

Message-ID値のように、コンテントID値は、世界特有になるように発生しなければなりません。

   The Content-ID value may be used for uniquely identifying MIME
   entities in several contexts, particularly for caching data
   referenced by the message/external-body mechanism.  Although the
   Content-ID header is generally optional, its use is MANDATORY in
   implementations which generate data of the optional MIME media type
   "message/external-body".  That is, each message/external-body entity
   must have a Content-ID field to permit caching of such data.

コンテントID値は唯一いくつかの文脈のMIME実体を特定するのに使用されるかもしれません、特に外部のメッセージ/ボディーメカニズムによって参照をつけられるデータをキャッシュするために。 コンテントIDヘッダーは一般に任意ですが、使用は「外部のメッセージ/ボディー」という任意のMIMEメディアタイプに関するデータを発生させる実現でMANDATORYです。 すなわちそれぞれの外部のメッセージ/ボディー実体はそのようなデータの許可証キャッシュにコンテントID分野を持たなければなりません。

   It is also worth noting that the Content-ID value has special
   semantics in the case of the multipart/alternative media type.  This
   is explained in the section of RFC 2046 dealing with
   multipart/alternative.

また、コンテントID値が複合の、または、代替のメディアタイプの場合で特別な意味論を持っていることに注意する価値があります。 これは複合か代替のRFC2046の取扱いのセクションで説明されます。

Freed & Borenstein          Standards Track                    [Page 26]

RFC 2045                Internet Message Bodies            November 1996

解放されるのとBorenstein規格はインターネットメッセージボディー1996年11月にRFC2045を追跡します[26ページ]。

8.  Content-Description Header Field

8. 満足している記述ヘッダーフィールド

   The ability to associate some descriptive information with a given
   body is often desirable.  For example, it may be useful to mark an
   "image" body as "a picture of the Space Shuttle Endeavor."  Such text
   may be placed in the Content-Description header field.  This header
   field is always optional.

何らかの記述的な情報を与えられたボディーに関連づける能力はしばしば望ましいです。 例えば、「スペースシャトルEndeavorの絵」として「イメージ」ボディーをマークするのは役に立つかもしれません。 そのようなテキストはContent-記述ヘッダーフィールドに置かれるかもしれません。 このヘッダーフィールドはいつも任意です。

     description := "Content-Description" ":" *text

「記述:=「満足している記述」」:、」 *テキスト

   The description is presumed to be given in the US-ASCII character
   set, although the mechanism specified in RFC 2047 may be used for
   non-US-ASCII Content-Description values.

あえて米国-ASCII文字の組で記述を与えます、RFC2047で指定されたメカニズムは非米国のASCII Content-記述値に使用されるかもしれませんが。

9.  Additional MIME Header Fields

9. 追加MIMEヘッダーフィールド

   Future documents may elect to define additional MIME header fields
   for various purposes.  Any new header field that further describes
   the content of a message should begin with the string "Content-" to
   allow such fields which appear in a message header to be
   distinguished from ordinary RFC 822 message header fields.

将来のドキュメントは、様々な目的のための追加MIMEヘッダーフィールドを定義するのを選ぶかもしれません。 さらにメッセージの内容について説明するどんな新しいヘッダーフィールドもひもで822のメッセージヘッダーに現れるそのような野原が普通のRFCと区別されるのを許容するので「満足している」メッセージヘッダーフィールドを始めるべきです。

     MIME-extension-field := <Any RFC 822 header field which
                              begins with the string
                              "Content-">

ひもで始まるMIME拡大分野:=<Any RFC822ヘッダーフィールド、「内容">"

10.  Summary

10. 概要

   Using the MIME-Version, Content-Type, and Content-Transfer-Encoding
   header fields, it is possible to include, in a standardized way,
   arbitrary types of data with RFC 822 conformant mail messages.  No
   restrictions imposed by either RFC 821 or RFC 822 are violated, and
   care has been taken to avoid problems caused by additional
   restrictions imposed by the characteristics of some Internet mail
   transport mechanisms (see RFC 2049).

MIMEバージョン、コンテントタイプ、およびContent転送コード化ヘッダーフィールドを使用して、RFCがある標準化された道、任意のタイプに関するデータに822のconformantメール・メッセージを含んでいるのは可能です。 RFC821かRFC822のどちらかによって課されなかった制限は全く違反されます、そして、いくつかのインターネット・メール移送機構の特性によって課された追加制限で引き起こされた問題を避けるために、注意しました(RFC2049を見てください)。

   The next document in this set, RFC 2046, specifies the initial set of
   media types that can be labelled and transported using these headers.

このセットにおける次のドキュメント(RFC2046)はこれらのヘッダーを使用することでレッテルを貼って、輸送できるメディアタイプの始発を指定します。

11.  Security Considerations

11. セキュリティ問題

   Security issues are discussed in the second document in this set, RFC
   2046.

このセット、RFC2046における2番目のドキュメントで安全保障問題について議論します。

Freed & Borenstein          Standards Track                    [Page 27]

RFC 2045                Internet Message Bodies            November 1996

解放されるのとBorenstein規格はインターネットメッセージボディー1996年11月にRFC2045を追跡します[27ページ]。

12.  Authors' Addresses

12. 作者のアドレス

   For more information, the authors of this document are best contacted
   via Internet mail:

詳しくは、インターネット・メールでこのドキュメントの作者に連絡するのは最も良いです:

   Ned Freed
   Innosoft International, Inc.
   1050 East Garvey Avenue South
   West Covina, CA 91790
   USA

ネッドは東ガーヴェーアベニューSouth West Innosoftの国際Inc.1050カリフォルニア91790コビーナ(米国)を解放しました。

   Phone: +1 818 919 3600
   Fax:   +1 818 919 3614
   EMail: ned@innosoft.com

以下に電話をしてください。 +1 818 919、3600Fax: +1 3614年の818 919メール: ned@innosoft.com

   Nathaniel S. Borenstein
   First Virtual Holdings
   25 Washington Avenue
   Morristown, NJ 07960
   USA

ナザニエルS.Borensteinファースト・バーチャル持ち株25ワシントン・Avenueニュージャージー07960モリスタウン(米国)

   Phone: +1 201 540 8967
   Fax:   +1 201 993 3032
   EMail: nsb@nsb.fv.com

以下に電話をしてください。 +1 201 540、8967Fax: +1 3032年の201 993メール: nsb@nsb.fv.com

   MIME is a result of the work of the Internet Engineering Task Force
   Working Group on RFC 822 Extensions.  The chairman of that group,
   Greg Vaudreuil, may be reached at:

MIMEはRFC822Extensionsへのインターネット・エンジニアリング・タスク・フォース作業部会の作業の結果です。 そのグループ、グレッグ・ボードルイの議長は以下で連絡されるかもしれません。

   Gregory M. Vaudreuil
   Octel Network Services
   17080 Dallas Parkway
   Dallas, TX 75248-1905
   USA

グレゴリーM.ボードルイのOctelネットワーク・サービス17080ダラスParkwayテキサス75248-1905ダラス(米国)

   EMail: Greg.Vaudreuil@Octel.Com

メール: Greg.Vaudreuil@Octel.Com

Freed & Borenstein          Standards Track                    [Page 28]

RFC 2045                Internet Message Bodies            November 1996

解放されるのとBorenstein規格はインターネットメッセージボディー1996年11月にRFC2045を追跡します[28ページ]。

Appendix A -- Collected Grammar

付録A--集まっている文法

   This appendix contains the complete BNF grammar for all the syntax
   specified by this document.

この付録はこのドキュメントによって指定されたすべての構文のための完全なBNF文法を含んでいます。

   By itself, however, this grammar is incomplete.  It refers by name to
   several syntax rules that are defined by RFC 822.  Rather than
   reproduce those definitions here, and risk unintentional differences
   between the two, this document simply refers the reader to RFC 822
   for the remaining definitions. Wherever a term is undefined, it
   refers to the RFC 822 definition.

しかしながら、それ自体で、この文法は不完全です。 それは名前でRFC822によって定義されるいくつかのシンタックス・ルールを参照します。 むしろ、このドキュメントはここでそれらの定義を再生させて、2の意図的でない違いを危険にさらすより残っている定義について単にRFC822の読者を参照します。 用語が未定義である、それがRFC822定義を呼ぶどこ。

  attribute := token
               ; Matching of attributes
               ; is ALWAYS case-insensitive.

:=象徴を結果と考えてください。 属性のマッチング。 ALWAYSは大文字と小文字を区別しないですか?

  composite-type := "message" / "multipart" / extension-token

拡大合成型:=「メッセージ」/「複合」/象徴

  content := "Content-Type" ":" type "/" subtype
             *(";" parameter)
             ; Matching of media type and subtype
             ; is ALWAYS case-insensitive.

「「コンテントタイプ」という内容:=」:、」 」 「タイプ」/「副-タイプ」*(「;」パラメタ)。 メディアタイプと「副-タイプ」のマッチング。 ALWAYSは大文字と小文字を区別しないですか?

  description := "Content-Description" ":" *text

「記述:=「満足している記述」」:、」 *テキスト

  discrete-type := "text" / "image" / "audio" / "video" /
                   "application" / extension-token

拡大離散的なタイプ:=「テキスト」/「イメージ」/「オーディオ」/「ビデオ」/「アプリケーション」/象徴

  encoding := "Content-Transfer-Encoding" ":" mechanism

「:=「満足している転送コード化」をコード化します」:、」 メカニズム

  entity-headers := [ content CRLF ]
                    [ encoding CRLF ]
                    [ id CRLF ]
                    [ description CRLF ]
                    *( MIME-extension-field CRLF )

実体ヘッダー:=[内容CRLF][CRLFをコード化します][イドCRLF][記述CRLF]*(MIME拡大分野CRLF)

  extension-token := ietf-token / x-token

x拡大象徴:=ietf-象徴/象徴

  hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
               ; Octet must be used for characters > 127, =,
               ; SPACEs or TABs at the ends of lines, and is
               ; recommended for any character not listed in
               ; RFC 2049 as "mail-safe".

十六進法八重奏:=「=」2(/「B」/ケタ/「C」/「D」/「E」/「F」)。 キャラクタ>127、=に八重奏を使用しなければなりません。 そして、行の終わりのSPACEsかTABs、あります。 記載されなかった少しのキャラクタのためにも、推薦されます。 「メール金庫」としてのRFC2049。

  iana-token := <A publicly-defined extension token. Tokens
                 of this form must be registered with IANA
                 as specified in RFC 2048.>

iana-象徴:=<Aは公的に拡大象徴を定義しました。 RFC 2048.>の指定されるとしてのIANAにこの形式の象徴を登録しなければなりません。

Freed & Borenstein          Standards Track                    [Page 29]

RFC 2045                Internet Message Bodies            November 1996

解放されるのとBorenstein規格はインターネットメッセージボディー1996年11月にRFC2045を追跡します[29ページ]。

  ietf-token := <An extension token defined by a
                 standards-track RFC and registered
                 with IANA.>

標準化過程RFCによって定義されて、IANA>に登録されたietf-象徴:=<An拡大象徴

  id := "Content-ID" ":" msg-id

「イド:=「コンテントID」」:、」 msg-イド

  mechanism := "7bit" / "8bit" / "binary" /
               "quoted-printable" / "base64" /
               ietf-token / x-token

メカニズム:=「7ビット」/「8ビット」/「2進」の/「引用されて印刷可能な」/「x base64" / ietf-象徴/象徴」

  MIME-extension-field := <Any RFC 822 header field which
                           begins with the string
                           "Content-">

ひもで始まるMIME拡大分野:=<Any RFC822ヘッダーフィールド、「内容">"

  MIME-message-headers := entity-headers
                          fields
                          version CRLF
                          ; The ordering of the header
                          ; fields implied by this BNF
                          ; definition should be ignored.

MIMEメッセージヘッダー:=実体ヘッダーはバージョンCRLFをさばきます。 ヘッダーの注文。 このBNFによって含意された分野。 定義は無視されるべきです。

  MIME-part-headers := entity-headers
                       [fields]
                       ; Any field not beginning with
                       ; "content-" can have no defined
                       ; meaning and may be ignored.
                       ; The ordering of the header
                       ; fields implied by this BNF
                       ; definition should be ignored.

MIME部分ヘッダー:=実体ヘッダー[分野]。 いくらか、少しの始めもさばきません。 「内容」はいいえを定義された持つことができます。 意味して、無視されるかもしれません。 ; ヘッダーの注文。 このBNFによって含意された分野。 定義は無視されるべきです。

  parameter := attribute "=" value

パラメタ:=属性「=」価値

  ptext := hex-octet / safe-char

安全なptext:=十六進法八重奏/炭

  qp-line := *(qp-segment transport-padding CRLF)
             qp-part transport-padding

qp-線:=*(輸送をそっと歩くqp-セグメントCRLF)qp-部分輸送詰め物

  qp-part := qp-section
             ; Maximum length of 76 characters

qp-部分:=qp-部。 76のキャラクタの最大の長さ

  qp-section := [*(ptext / SPACE / TAB) ptext]

qp-セクション:=[*(ptext/SPACE/TAB)ptext]

  qp-segment := qp-section *(SPACE / TAB) "="
                ; Maximum length of 76 characters

qp-セグメント:=qp-セクション*(SPACE / TAB)「=」。 76のキャラクタの最大の長さ

  quoted-printable := qp-line *(CRLF qp-line)

引用されて印刷可能な:=qp-線*(CRLF qp-線)

Freed & Borenstein          Standards Track                    [Page 30]

RFC 2045                Internet Message Bodies            November 1996

解放されるのとBorenstein規格はインターネットメッセージボディー1996年11月にRFC2045を追跡します[30ページ]。

  safe-char := <any octet with decimal value of 33 through
               60 inclusive, and 62 through 126>
               ; Characters not listed as "mail-safe" in
               ; RFC 2049 are also not recommended.

そして、包括的に小数があるどんな八重奏も評価する33〜60の:=<が金庫で焦げてください、126>を通した62。 キャラクターは中で「メール安全である」として記載しませんでした。 また、RFC2049は推薦されません。

  subtype := extension-token / iana-token

iana「副-タイプ」:=拡大象徴/象徴

  token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
              or tspecials>

象徴:=1*<はSPACE、CTLs、またはtspecials>以外のあらゆる(米国のASCII)のCHARです。

  transport-padding := *LWSP-char
                       ; Composers MUST NOT generate
                       ; non-zero length transport
                       ; padding, but receivers MUST
                       ; be able to handle padding
                       ; added by message transports.

輸送をそっと歩く:=*LWSP-炭。 作曲家、発生してはいけません。 非ゼロ・レングス輸送。 しかし、詰め物、受信機はそうしなければなりません。 詰め物を扱うことができてください。 メッセージ転送で、加えられます。

  tspecials :=  "(" / ")" / "<" / ">" / "@" /
                "," / ";" / ":" / "\" / <">
                "/" / "[" / "]" / "?" / "="
                ; Must be in quoted-string,
                ; to use within parameter values

「」 tspecials:=「(「/」)」/「<」 /">"/"@"/」、/」;、」 / ":" 「/「\」/<">"/」/「[「/」]」/“?" / "=" ; 引用文字列にあるに違いありません。 パラメタ値の中の使用に

  type := discrete-type / composite-type

:=の離散的なタイプ/合成型をタイプしてください。

  value := token / quoted-string

値の:=象徴/引用文字列

  version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

「「MIMEバージョン」というバージョン:=」:、」 「1*ケタ」、」 1*ケタ

  x-token := <The two characters "X-" or "x-" followed, with
              no  intervening white space, by any token>

2つのキャラクタ「X」か「x」がどんな象徴>も介入している余白なしで続けたx-象徴:=<。

Freed & Borenstein          Standards Track                    [Page 31]

解放されるのとBorenstein標準化過程[31ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

<ADDRESS> 連絡先・問合せ先を示す

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る