| < draft-ietf-822ext-mime-imb-05.txt | draft-ietf-822ext-mime-imb-06.txt > | |||
|---|---|---|---|---|
| Network Working Group Nathaniel Borenstein | Network Working Group Nathaniel Borenstein | |||
| Internet Draft Ned Freed | Internet Draft Ned Freed | |||
| <draft-ietf-822ext-mime-imb-05.txt> | <draft-ietf-822ext-mime-imb-06.txt> | |||
| Multipurpose Internet Mail Extensions | Multipurpose Internet Mail Extensions | |||
| (MIME) Part One: | (MIME) Part One: | |||
| Format of Internet Message Bodies | Format of Internet Message Bodies | |||
| January 1996 | March 1996 | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft. Internet-Drafts are | This document is an Internet-Draft. Internet-Drafts are | |||
| working documents of the Internet Engineering Task Force | working documents of the Internet Engineering Task Force | |||
| (IETF), its areas, and its working groups. Note that other | (IETF), its areas, and its working groups. Note that other | |||
| groups may also distribute working documents as Internet- | groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six | |||
| skipping to change at page 2, line ? ¶ | skipping to change at page 2, line ? ¶ | |||
| STD 11, RFC 822, defines a message representation protocol | STD 11, RFC 822, defines a message representation protocol | |||
| specifying considerable detail about US-ASCII message headers, | specifying considerable detail about US-ASCII message headers, | |||
| and leaves the message content, or message body, as flat US- | and leaves the message content, or message body, as flat US- | |||
| ASCII text. This set of documents, collectively called the | ASCII text. This set of documents, collectively called the | |||
| Multipurpose Internet Mail Extensions, or MIME, redefines the | Multipurpose Internet Mail Extensions, or MIME, redefines the | |||
| format of messages to allow for | format of messages to allow for | |||
| (1) textual message bodies in character sets other than | (1) textual message bodies in character sets other than | |||
| US-ASCII, | US-ASCII, | |||
| (2) 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 | (4) textual header information in character sets other than | |||
| US-ASCII. | US-ASCII. | |||
| These documents are based on earlier work documented in RFC | These documents are based on earlier work documented in RFC | |||
| 934, STD 11, and RFC 1049, but extends and revises them. | 934, STD 11, and RFC 1049, but extends and revises them. | |||
| Because RFC 822 said so little about message bodies, these | Because RFC 822 said so little about message bodies, these | |||
| documents are largely orthogonal to (rather than a revision | documents are largely orthogonal to (rather than a revision | |||
| of) RFC 822. | of) RFC 822. | |||
| In particular, these documents are designed to provide | ||||
| facilities to include multiple parts in a single message, to | ||||
| represent body and header text in character sets other than | ||||
| US-ASCII, to represent formatted multi-font text messages, to | ||||
| represent non-textual material such as images and audio clips, | ||||
| and generally to facilitate later extensions defining new | ||||
| types of Internet mail for use by cooperating mail agents. | ||||
| This initial document specifies the various headers used to | This initial document specifies the various headers used to | |||
| describe the structure of MIME messages. The second document, | describe the structure of MIME messages. The second document, | |||
| RFC MIME-IMT, defines the general structure of the MIME media | RFC MIME-IMT, defines the general structure of the MIME media | |||
| typing system and defines an initial set of media types. The | typing system and defines an initial set of media types. The | |||
| third document, RFC MIME-HEADERS, describes extensions to RFC | third document, RFC MIME-HEADERS, describes extensions to RFC | |||
| 822 to allow non-US-ASCII text data in Internet mail header | 822 to allow non-US-ASCII text data in Internet mail header | |||
| fields. The fourth document, RFC MIME-REG, specifies various | fields. The fourth document, RFC MIME-REG, specifies various | |||
| IANA registration procedures for MIME-related facilities. The | IANA registration procedures for MIME-related facilities. The | |||
| fifth and final document, RFC MIME-CONF, describes MIME | fifth and final document, RFC MIME-CONF, describes MIME | |||
| conformance criteria as well as providing some illustrative | conformance criteria as well as providing some illustrative | |||
| skipping to change at page 3, line 28 ¶ | skipping to change at page 3, line 28 ¶ | |||
| 4.8 8bit Data ........................................... 9 | 4.8 8bit Data ........................................... 9 | |||
| 4.9 Binary Data ......................................... 9 | 4.9 Binary Data ......................................... 9 | |||
| 4.10 Lines .............................................. 9 | 4.10 Lines .............................................. 9 | |||
| 5 MIME Header Fields .................................... 9 | 5 MIME Header Fields .................................... 9 | |||
| 6 MIME-Version Header Field ............................. 10 | 6 MIME-Version Header Field ............................. 10 | |||
| 7 Content-Type Header Field ............................. 12 | 7 Content-Type Header Field ............................. 12 | |||
| 7.1 Syntax of the Content-Type Header Field ............. 14 | 7.1 Syntax of the Content-Type Header Field ............. 14 | |||
| 7.2 Content-Type Defaults ............................... 16 | 7.2 Content-Type Defaults ............................... 16 | |||
| 8 Content-Transfer-Encoding Header Field ................ 17 | 8 Content-Transfer-Encoding Header Field ................ 17 | |||
| 8.1 Content-Transfer-Encoding Syntax .................... 17 | 8.1 Content-Transfer-Encoding Syntax .................... 17 | |||
| 8.2 Content-Transfer-Encodings Sematics ................. 17 | 8.2 Content-Transfer-Encodings Semantics ................ 17 | |||
| 8.3 New Content-Transfer-Encodings ...................... 19 | 8.3 New Content-Transfer-Encodings ...................... 19 | |||
| 8.4 Interpretation and Use .............................. 19 | 8.4 Interpretation and Use .............................. 19 | |||
| 8.5 Translating Encodings ............................... 21 | 8.5 Translating Encodings ............................... 21 | |||
| 8.6 Canonical Encoding Model ............................ 22 | 8.6 Canonical Encoding Model ............................ 22 | |||
| 8.7 Quoted-Printable Content-Transfer-Encoding .......... 22 | 8.7 Quoted-Printable Content-Transfer-Encoding .......... 22 | |||
| 8.8 Base64 Content-Transfer-Encoding .................... 26 | 8.8 Base64 Content-Transfer-Encoding .................... 26 | |||
| 9 Content-ID Header Field ............................... 29 | 9 Content-ID Header Field ............................... 29 | |||
| 10 Content-Description Header Field ..................... 30 | 10 Content-Description Header Field ..................... 30 | |||
| 11 Additional MIME Header Fields ........................ 30 | 11 Additional MIME Header Fields ........................ 30 | |||
| 12 Summary .............................................. 30 | 12 Summary .............................................. 30 | |||
| skipping to change at page 7, line 37 ¶ | skipping to change at page 7, line 37 ¶ | |||
| of converting a sequence of octets into a sequence of | of converting a sequence of octets into a sequence of | |||
| characters. Note that unconditional and unambiguous | characters. Note that unconditional and unambiguous | |||
| conversion in the other direction is not required, in that not | conversion in the other direction is not required, in that not | |||
| all characters may be representable by a given character set | all characters may be representable by a given character set | |||
| and a character set may provide more than one sequence of | and a character set may provide more than one sequence of | |||
| octets to represent a particular sequence of characters. | octets to represent a particular sequence of characters. | |||
| This definition is intended to allow various kinds of | This definition is intended to allow various kinds of | |||
| character encodings, from simple single-table mappings such as | character encodings, from simple single-table mappings such as | |||
| US-ASCII to complex table switching methods such as those that | US-ASCII to complex table switching methods such as those that | |||
| use ISO 2022's techniques. However, the definition associated | use ISO 2022's techniques, to be used as character sets. | |||
| with a MIME character set name must fully specify the mapping | However, the definition associated with a MIME character set | |||
| to be performed. In particular, use of external profiling | name must fully specify the mapping to be performed. In | |||
| information to determine the exact mapping is not permitted. | particular, use of external profiling information to determine | |||
| the exact mapping is not permitted. | ||||
| NOTE: The term "character set" was originally used in MIME | NOTE: The term "character set" was originally used in MIME | |||
| with specifications such as US-ASCII and other 7bit and 8bit | with specifications such as US-ASCII and other 7bit and 8bit | |||
| schemes which have a simple mapping from single octets to | schemes which have a simple mapping from single octets to | |||
| single characters. Multi-octet coded character sets and | single characters. Multi-octet coded character sets and | |||
| switching techniques make the situation more complex. For | switching techniques make the situation more complex. For | |||
| example, some communities use the term "character encoding" | example, some communities use the term "character encoding" | |||
| for what MIME calls a "character set", while using the phrase | for what MIME calls a "character set", while using the phrase | |||
| "coded character set" to denote an abstract mapping from | "coded character set" to denote an abstract mapping from | |||
| integers (not octets) to characters. | integers (not octets) to characters. | |||
| skipping to change at page 14, line 44 ¶ | skipping to change at page 14, line 44 ¶ | |||
| ietf-token := <An extension token defined by a | ietf-token := <An extension token defined by a | |||
| standards-track RFC and registered | standards-track RFC and registered | |||
| with IANA.> | with IANA.> | |||
| x-token := <The two characters "X-" or "x-" followed, with | x-token := <The two characters "X-" or "x-" followed, with | |||
| no intervening white space, by any token> | no intervening white space, by any token> | |||
| subtype := extension-token / iana-token | subtype := extension-token / iana-token | |||
| iana-token := <A publicly-defined extension token. Tokens | iana-token := <A publicly-defined extension token. Tokens | |||
| of this form should be registered with IANA | of this form must be registered with IANA | |||
| as specified in RFC MIME-REG.> | as specified in RFC MIME-REG.> | |||
| parameter := attribute "=" value | parameter := attribute "=" value | |||
| attribute := token | attribute := token | |||
| ; Matching of attributes | ; Matching of attributes | |||
| ; is ALWAYS case-insensitive. | ; is ALWAYS case-insensitive. | |||
| value := token / quoted-string | value := token / quoted-string | |||
| token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, | token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, | |||
| or tspecials> | or tspecials> | |||
| skipping to change at page 17, line 42 ¶ | skipping to change at page 17, line 42 ¶ | |||
| "quoted-printable" / "base64" / | "quoted-printable" / "base64" / | |||
| ietf-token / x-token | ietf-token / x-token | |||
| These values are not case sensitive -- Base64 and BASE64 and | These values are not case sensitive -- Base64 and BASE64 and | |||
| bAsE64 are all equivalent. An encoding type of 7BIT requires | bAsE64 are all equivalent. An encoding type of 7BIT requires | |||
| that the body is already in a 7bit mail-ready representation. | that the body is already in a 7bit mail-ready representation. | |||
| This is the default value -- that is, "Content-Transfer- | This is the default value -- that is, "Content-Transfer- | |||
| Encoding: 7BIT" is assumed if the Content-Transfer-Encoding | Encoding: 7BIT" is assumed if the Content-Transfer-Encoding | |||
| header field is not present. | header field is not present. | |||
| 8.2. Content-Transfer-Encodings Sematics | 8.2. Content-Transfer-Encodings Semantics | |||
| This single Content-Transfer-Encoding token actually provides | This single Content-Transfer-Encoding token actually provides | |||
| two pieces of information. It specifies what sort of encoding | two pieces of information. It specifies what sort of encoding | |||
| transformation the body was subjected to, and it specifies | transformation the body was subjected to, and it specifies | |||
| what the domain of the result is. | what the domain of the result is. | |||
| Three transformations are currently defined: identity, the | Three transformations are currently defined: identity, the | |||
| "quoted-printable" encoding, and the "base64" encoding. The | "quoted-printable" encoding, and the "base64" encoding. The | |||
| domains are "binary", "8bit" and "7bit". | domains are "binary", "8bit" and "7bit". | |||
| skipping to change at page 21, line 47 ¶ | skipping to change at page 21, line 47 ¶ | |||
| couples the specification of an application protocol with a | couples the specification of an application protocol with a | |||
| specific lower-level transport. This is not desirable since | specific lower-level transport. This is not desirable since | |||
| the developers of a media type should not have to be aware of | the developers of a media type should not have to be aware of | |||
| all the transports in use and what their limitations are. | all the transports in use and what their limitations are. | |||
| 8.5. Translating Encodings | 8.5. Translating Encodings | |||
| The quoted-printable and base64 encodings are designed so that | The quoted-printable and base64 encodings are designed so that | |||
| conversion between them is possible. The only issue that | conversion between them is possible. The only issue that | |||
| arises in such a conversion is the handling of hard line | arises in such a conversion is the handling of hard line | |||
| breaks. When converting from quoted-printable to base64 a | breaks in quoted-printable encoding output. When converting | |||
| hard line break must be converted into a CRLF sequence. | from quoted-printable to base64 a hard line break must be | |||
| converted into a CRLF sequence. Similarly, a CRLF sequence in | ||||
| Similarly, a CRLF sequence in base64 data must be converted to | base64 data must be converted to a quoted-printable hard line | |||
| a quoted-printable hard line break, but ONLY when converting | break, but ONLY when converting text data. | |||
| text data. | ||||
| 8.6. Canonical Encoding Model | 8.6. Canonical Encoding Model | |||
| There was some confusion, in the previous versions of this | There was some confusion, in the previous versions of this | |||
| RFC, regarding the model for when email data was to be | RFC, regarding the model for when email data was to be | |||
| converted to canonical form and encoded, and in particular how | converted to canonical form and encoded, and in particular how | |||
| this process would affect the treatment of CRLFs, given that | this process would affect the treatment of CRLFs, given that | |||
| the representation of newlines varies greatly from system to | the representation of newlines varies greatly from system to | |||
| system, and the relationship between content-transfer- | system, and the relationship between content-transfer- | |||
| encodings and character sets. A canonical model for encoding | encodings and character sets. A canonical model for encoding | |||
| skipping to change at page 32, line 35 ¶ | skipping to change at page 32, line 35 ¶ | |||
| Email: ned@innosoft.com | Email: ned@innosoft.com | |||
| Phone: +1 818 919 3600 | Phone: +1 818 919 3600 | |||
| Fax: +1 818 919 3614 | Fax: +1 818 919 3614 | |||
| MIME is a result of the work of the Internet Engineering Task | MIME is a result of the work of the Internet Engineering Task | |||
| Force Working Group on Email Extensions. The chairman of that | Force Working Group on Email Extensions. The chairman of that | |||
| group, Greg Vaudreuil, may be reached at: | group, Greg Vaudreuil, may be reached at: | |||
| Gregory M. Vaudreuil | Gregory M. Vaudreuil | |||
| Tigon Corporation | Octel Network Services | |||
| 17060 Dallas Parkway | 17080 Dallas Parkway | |||
| Dallas Texas, 75248 | Dallas, TX 75248-1905 | |||
| USA | ||||
| Email: greg.vaudreuil@ons.octel.com | Email: Greg.Vaudreuil@Octel.Com | |||
| Phone: +1 214 733 2722 | ||||
| Appendix A -- Collected Grammar | Appendix A -- Collected Grammar | |||
| This appendix contains the complete BNF grammar for all the | This appendix contains the complete BNF grammar for all the | |||
| syntax specified by this document. | syntax specified by this document. | |||
| By itself, however, this grammar is incomplete. It refers by | By itself, however, this grammar is incomplete. It refers by | |||
| name to several syntax rules that are defined by RFC 822. | name to several syntax rules that are defined by RFC 822. | |||
| Rather than reproduce those definitions here, and risk | Rather than reproduce those definitions here, and risk | |||
| unintentional differences between the two, this document | unintentional differences between the two, this document | |||
| simply refers the reader to RFC 822 for the remaining | simply refers the reader to RFC 822 for the remaining | |||
| skipping to change at page 34, line 11 ¶ | skipping to change at page 34, line 11 ¶ | |||
| *( MIME-extension-field CRLF ) | *( MIME-extension-field CRLF ) | |||
| extension-token := ietf-token / x-token | extension-token := ietf-token / x-token | |||
| hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") | hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") | |||
| ; Octet must be used for characters > 127, =, | ; Octet must be used for characters > 127, =, | |||
| ; SPACEs or TABs at the ends of lines, and is | ; SPACEs or TABs at the ends of lines, and is | |||
| ; recommended for any character not listed in | ; recommended for any character not listed in | |||
| ; RFC MIME-CONF as "mail-safe". | ; RFC MIME-CONF as "mail-safe". | |||
| iana-token := <A publicly-defined extension token. Tokens | iana-token := <A publicly-defined extension token. Tokens | |||
| of this form should be registered with IANA | of this form must be registered with IANA | |||
| as specified in RFC MIME-REG.> | as specified in RFC MIME-REG.> | |||
| ietf-token := <An extension token defined by a | ietf-token := <An extension token defined by a | |||
| standards-track RFC and registered | standards-track RFC and registered | |||
| with IANA.> | with IANA.> | |||
| id := "Content-ID" ":" msg-id | id := "Content-ID" ":" msg-id | |||
| mechanism := "7bit" / "8bit" / "binary" / | mechanism := "7bit" / "8bit" / "binary" / | |||
| "quoted-printable" / "base64" / | "quoted-printable" / "base64" / | |||
| ietf-token / x-token | ietf-token / x-token | |||
| End of changes. 12 change blocks. | ||||
| 32 lines changed or deleted | 25 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||