10c10 < MIME (Multipurpose Internet Mail Extensions): --- > MIME (Multipurpose Internet Mail Extensions): 18c18 < February, 1992 --- > January, 1992 69c69 < INTERNET MIME: Multipurpose Internet Mail Extensions 2 --- > INTERNET DRAFT Internet Message Body Format 2 134c134 < INTERNET MIME: Multipurpose Internet Mail Extensions 3 --- > INTERNET DRAFT Internet Message Body Format 3 199c199 < INTERNET MIME: Multipurpose Internet Mail Extensions 4 --- > INTERNET DRAFT Internet Message Body Format 4 202c202 < This document describes several mechanisms that combine to --- > this document describes several mechanisms that combine to 231,232c231,232 < and hence, among other uses, to implement an < electronic mail file transfer service. --- > and hence, among other uses, to implement an email > file transfer service. 244,245c244,245 < video or moving image data, possibly with audio as < part of the composite video data format. --- > video, or moving image data, possibly with audio > as part of the composite video data format. 264c264 < INTERNET MIME: Multipurpose Internet Mail Extensions 5 --- > INTERNET DRAFT Internet Message Body Format 5 267,278d266 < MIME has been carefully designed as an extensible mechanism, < and it is expected that the set of content-type/subtype < pairs and their associated parameters will grow < significantly with time. Several other MIME fields, notably < including character set names, are likely to have new values < defined over time. In order to ensure that the set of such < values is developed in an orderly, well-specified, and < public manner, MIME defines a registration process which < uses the Internet Assigned Numbers Authority (IANA) as a < central registry for such values. Appendix F provides < details about how IANA registration is accomplished. < 310,313c298,303 < syntactic entities that are defined in RFC 822 and not in < this document. A complete formal grammar, then, is obtained < by combining the collected grammar appendix of this document < with that of RFC 822. --- > syntactic entities that are defined, not in this document, > but in RFC 822. Therefore RFC 822 is required for a > complete grammar. Like RFC 822, this document has an > appendix that is a collected grammar. A complete formal > grammar, then, is obtained by combining the collected > grammar appendix of this document with that of RFC 822. 317,318c307 < together, in this order, denote a line break in RFC 822 < mail. --- > together, denote a line break in RFC 822 mail. 319a309,312 > The term "character set", wherever it is used in this > document, refers to a coded character set, in the sense of > ISO character set standardization work, and should not be > misinterpreted as meaning "a set of characters." 320a314,315 > In this document, all numeric and octet values are given in > decimal notation. 321a317,319 > It should be noted that Content-Type values, subtypes, and > parameter names as defined in this document are case- > insensitive. However, parameter values are case-sensitive. 326d323 < 329c326 < INTERNET MIME: Multipurpose Internet Mail Extensions 6 --- > 332,335c329 < The term "character set", wherever it is used in this < document, refers to a coded character set, in the sense of < ISO character set standardization work, and must not be < misinterpreted as meaning "a set of characters." --- > INTERNET DRAFT Internet Message Body Format 6 337,338d330 < In this document, all numeric and octet values are given in < decimal notation. 340,344d331 < It must be noted that Content-Type values, subtypes, and < parameter names as defined in this document are case- < insensitive. However, parameter values are case-sensitive < unless otherwise specified for the specific parameter. < 374,396d360 < < < < < < < < < < < < < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 7 < < 422a387,396 > > > > > > > > INTERNET DRAFT Internet Message Body Format 7 > > 430,431c404,405 < extend "1.0", are (minimally) constrained by the definition < of "text", which appears in RFC 822. --- > extend "1.0", are constrained by the definition of "text", > which appears in RFC 822. 441,461d414 < < < < < < < < < < < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 8 < < 474c427,434 < given here. --- > given here. However, most of the specific values > for the Content-Type field that were defined by > RFC 1049 have been replaced, in this document, > with type/subtype pairs. A few types that were > incompletely defined in RFC 1049, and never used > in any known implementation, are omitted here, but > could be reintroduced in the new type/subtype > scheme without major difficulty. 483,487c443,446 < types. The ordering of parameters is not significant. < Among the defined parameters is a "charset" parameter by < which the character set used in the message body or body < part may be declared. Comments are allowed in accordance < with RFC 822 rules for structured header fields. --- > types. Among the defined parameters is a "charset" > parameter by which the character set used in the message > body or body part may be declared. Comments are allowed in > accordance with RFC 822 rules for structured header fields. 491a451,461 > > > > > > > > > INTERNET DRAFT Internet Message Body Format 8 > > 515a486,493 > 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 an extension to this standard. If another > primary type is to be used for any reason, it should be > given a name starting with "X-" to indicate its non-standard > status and to avoid a potential conflict with a future > official name. 516a495,496 > In the Extended BNF notation of RFC 822, a Content-Type > header field value is defined as follows: 521d500 < 524d502 < INTERNET MIME: Multipurpose Internet Mail Extensions 9 527,534d504 < 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 an extension to this standard. If another < primary 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. 536,537d505 < In the Extended BNF notation of RFC 822, a Content-Type < header field value is defined as follows: 539d506 < Content-Type := type "/" subtype *[";" parameter] 540a508,528 > > > > > > > > > > > > > > > > > INTERNET DRAFT Internet Message Body Format 9 > > > Content-Type:= type "/" subtype *[";" parameter] > 547c535 < intervening white space, by any token> --- > intervening white space, by any token> 562c550 < / "=" ; parameter values --- > / "=" ; parameter values 577c565 < type" for message/External-body is not case-sensitive.) --- > type" for message/external-body is not case-sensitive.) 581,591d568 < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 10 < < 603a581,591 > > > > > > > > > INTERNET DRAFT Internet Message Body Format 10 > > 606,609c594,598 < 2. New standard values must be documented, < registered with, and approved by IANA, as < described in Appendix F. Where intended for < public use, the formats they refer to must --- > 2. New "Standard" values must be documented, > registered with, and approved by the Internet > Assigned Numbers Authority (IANA) at ISI, by > email to IANA@ISI.EDU. Where intended for > public use, the formats they refer to should 630c619 < are defined, including the primary "mixed" --- > are defined, including the default "mixed" 636,637c625,626 < message -- an encapsulated message. A message body of < Content-Type "message" is itself a fully formatted --- > message -- an encapsulated message. A body of > Content-Type message is itself a fully formatted 640,645c629,645 < primary subtype is "rfc822". The "partial" < subtype is defined for partial messages, to permit < the fragmented transmission of message bodies that < are thought to be too large to be passed through < mail transport facilities. Another subtype, < "External-body", is defined for specifying large --- > "partial" subtype is defined for partial messages, > to permit the fragmented transmission of message > bodies that are thought to be too large to be > passed through mail transport facilities. Another > subtype, "external-body", is defined for > specifying large message bodies by reference to an > external data source. > application -- some other kind of data, typically > either uninterpreted binary data or information to > be processed by a mail-based application. The > primary subtype, "octet-stream", is to be used in > the case of uninterpreted binary data, in which > case the simplest recommended action is to offer > to write the information into a file for the user. > Two additional subtypes, "ODA" and "PostScript", > are defined for transporting ODA and PostScript > documents in message bodies. Other expected uses 654c654 < INTERNET MIME: Multipurpose Internet Mail Extensions 11 --- > INTERNET DRAFT Internet Message Body Format 11 657,658c657,659 < message bodies by reference to an external data < source. --- > for "application" include spreadsheets, data for > mail-based scheduling systems, and languages for > "active" (computational) email. 662,663c663,666 < subtypes are defined for three widely-used image < formats, jpeg, gif, and G3fax. --- > subtypes are defined for several widely-used image > formats, including jpeg, gif, G3fax, pbm, ppm, > pgm, and TIFF-B-NetFax. The latter is recommended > by the IETF Network Fax Working Group. 672,684d674 < application -- some other kind of data, typically < either uninterpreted binary data or information to < be processed by a mail-based application. The < primary subtype, "octet-stream", is to be used in < the case of uninterpreted binary data, in which < case the simplest recommended action is to offer < to write the information into a file for the user. < Two additional subtypes, "ODA" and "PostScript", < are defined for transporting ODA and PostScript < documents in message bodies. Other expected uses < for "application" include spreadsheets, data for < mail-based scheduling systems, and languages for < "active" (computational) email. 694,695c684,685 < plain US-ASCII text must still be assumed, but the sender's < intent might have been otherwise. --- > plain US-ASCII text should still be assumed, but the > sender's intent might have been otherwise. 703,710c693,701 < text in another character set or non-textual data < in a manner that cannot be automatically < recognized (e.g., a uuencoded compressed UNIX tar < file). Although there is no fully acceptable < alternative to treating such untyped messages as < "text/plain; charset=us-ascii", implementors < should remain aware that if a message lacks both < the MIME-Version and the Content-Type header --- > non-textual data in a manner that cannot be > automatically recognized (e.g., a uuencoded > compressed UNIX tar file). Although there is no > fully acceptable alternative to treating such > untyped messages as "text/plain; charset=us- > ascii", implementors should remain aware that if a > message lacks both the MIME-Version and the > Content-Type header fields, it may in practice > contain almost anything. 711a703,706 > It should be noted that the list of Content-Type values > given here may be augmented in time, via the mechanisms > described above, and that the set of subtypes is expected to > grow substantially. 712a708,710 > When a mail reader encounters mail with an unknown Content- > type value, it should generally treat it as equivalent to > "application/octet-stream", as described later in this 716d713 < 719c716 < INTERNET MIME: Multipurpose Internet Mail Extensions 12 --- > 722,723c719 < fields, it may in practice contain almost < anything. --- > INTERNET DRAFT Internet Message Body Format 12 725,728d720 < It should be noted that the list of Content-Type values < given here may be augmented in time, via the mechanisms < described above, and that the set of subtypes is expected to < grow substantially. 730,732d721 < When a mail reader encounters mail with an unknown Content- < type value, it should generally treat it as equivalent to < "application/octet-stream", as described later in this 740,742c729,731 < over some transport protocols. For example, RFC 821 < restricts mail messages to 7-bit US-ASCII data with 1000 < character lines. --- > over some transport protocols. For example, both RFC 821 > and RFC 822 restrict mail messages to 7-bit US-ASCII data > with 1000 character lines. 746c735 < This document specifies that such encodings will be --- > this document specifies that such encodings will be 772,786c761,762 < Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" / < "8BIT" / "7BIT" / < < < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 13 < < --- > Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE"/ > "8BIT" / "7BIT" 796,807d771 < The values "8bit", "7bit", and "binary" all imply that NO < encoding has been performed. However, they are potentially < useful as indications of the kind of data contained in the < object, and therefore of the kind of encoding that might < need to be performed for transmission in a given transport < system. "7bit" means that the data is all represented as < short lines of US-ASCII data. "8bit" means that the lines < are short, but there may be non-ASCII characters (octets < with the high-order bit set). "Binary" means that not only < may non-ASCII characters be present, but also that the lines < are not necessarily short enough for SMTP transport. < 810c774 < does not require adherence to any limits on line length or --- > does not require adherance to any limits on line length or 812c776,787 < require such adherence. If the message contains data in any --- > > > > > > > > > INTERNET DRAFT Internet Message Body Format 13 > > > require such adherance. If the message contains data in any 827c802,803 < do not meet the restrictions of RFC 821 transport. --- > does not meet the restrictions of RFC 821 > transport. 840c816 < should be labeled as such using this mechanism. --- > should be labelled as such using this mechanism. 842,851d817 < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 14 < < 874a841,851 > > > > > > > > > INTERNET DRAFT Internet Message Body Format 14 > > 885,888c862,865 < not ending at an 8-bit boundary must be padded with zeroes. < This document provides a mechanism for noting the addition < of such padding in the case of the application Content-Type, < which has a "padding" parameter. --- > not ending at an 8-bit boundary should be padded with > zeroes. This document provides a mechanism for noting the > addition of such padding in the case of the application > Content-Type, which has a "padding" parameter. 891,892c868,869 < data in ASCII. Thus, for example, suppose a message has < header fields such as: --- > data in ASCII. Thus, for example, if a message has header > fields such as: 894c871 < Content-Type: text/plain; charset=ISO-8859-1 --- > Content-Type: text/plain, charset=ISO-8859-1 906,916d882 < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 15 < < 939a906,916 > > > > > > > > > INTERNET DRAFT Internet Message Body Format 15 > > 963c940 < would be required for text in certain character --- > would be required for text in European character 971,981d947 < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 16 < < 983c949 < binary encoding mechanism) may only be reasonably --- > binary encoding mechanism) may only be resonably 995a962,981 > > > > > > > > > > > > > > > > > > INTERNET DRAFT Internet Message Body Format 16 > > 1004c990 < largely recognizable by humans. A message which is entirely --- > largely recognisable by humans. A message which is entirely 1021c1007 < example, the value 12 (ASCII form feed) can be --- > example, the value 12 (ACII carriage return) can be 1036,1046d1021 < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 17 < < 1054c1029 < that an octet with value 9 or 32 appearing at the end --- > that octets with values 9 and 32 appearing at the and 1060a1036,1046 > > > > > > > > > INTERNET DRAFT Internet Message Body Format 17 > > 1083c1069 < of the line is a single unencoded line that says: --- > of the line is a single line that says: 1085,1086c1071,1072 < Now's the time for all folk to come to the aid of < their country. --- > Now's the time for all folk to come to the aid of their > country. 1091,1093c1077,1079 < Now's the time = < for all folk to come= < to the aid of their country. --- > Now's the time = > for all folk to come= > to the aid of their country. 1101,1111d1086 < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 18 < < 1125a1101,1111 > > > > > > > > > INTERNET DRAFT Internet Message Body Format 18 > > 1137c1123 < !"#$@[\]^`{|}~ --- > !"#$@[]^`{}|~ \ 1142,1176d1127 < Because quoted-printable data is generally assumed to be < line-oriented, it is to be expected that 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 corruption of the < data, it is probably more sensible to use the base64 < encoding rather than the quoted-printable encoding. < < < < < < < < < < < < < < < < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 19 < < 1212c1163 < stream must be presumed to be ordered with the most- --- > stream should be presumed to be ordered with the most- 1215d1165 < bit will be the low-order bit in the first byte, and so on. 1217,1224d1166 < 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 encapsulation boundaries defined in this document < (e.g., "-"). 1228a1171 > 1230a1174 > INTERNET DRAFT Internet Message Body Format 19 1232a1177 > bit with be the low-order bit in the first byte, and so on. 1233a1179,1186 > 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 encapsulation boundaries defined in this document > (e.g., "-"). 1235,1241d1187 < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 20 < < 1274,1290c1220,1230 < available at the end of the data being encoded. A full < encoding quantum is always completed at the end of a < message. 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. Output character positions < which are not required to represent actual input data are < set to 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. --- > available at the end of a message or encapsulated part of a > message. A full encoding quantum is always completed at the > end of a message. 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. Output > character positions which are not required to represent > actual input data are set to 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 1292,1295d1231 < NOTE: There is no need to worry about quoting < apparent encapsulation boundaries within base64- < encoded parts of multipart messages because no < hyphen characters are used in the base64 encoding. 1300d1235 < 1304c1239 < INTERNET MIME: Multipurpose Internet Mail Extensions 21 --- > INTERNET DRAFT Internet Message Body Format 20 1306a1242,1254 > 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. > > Note: There is no need to worry about quoting > apparent encapsulation boundaries within base64- > encoded parts of multipart messages, because no > hyphen characters are used in the base64 encoding. > 1313c1261 < Accordingly, message body parts may be labeled using the --- > Accordingly, message body parts may be labelled using the 1319c1267 < Like the Message-ID values, Content-ID values must be --- > Like the Message-ID values, Content-ID values should be 1353,1365d1300 < < < < < < < < < < < < < 1369c1304 < INTERNET MIME: Multipurpose Internet Mail Extensions 22 --- > INTERNET DRAFT Internet Message Body Format 21 1374c1309 < This document defines seven initial Content-Type values and --- > this document defines seven initial Content-Type values and 1419c1354 < character set, which must be assumed in the absence of a --- > character set, which should be assumed in the absence of a 1424,1425c1359,1360 < may be registered with IANA as described in Appendix F, < although the standardization of their use requires the usual --- > may be registered with IANA, although the standardization of > their use requires the usual IAB review and approval. Note 1434c1369 < INTERNET MIME: Multipurpose Internet Mail Extensions 23 --- > INTERNET DRAFT Internet Message Body Format 22 1437,1441c1372,1375 < IAB review and approval. Note that if the specified < character set includes 8-bit data, a Content-Transfer- < Encoding header field and a corresponding encoding on the < data are required in order to transmit the message via some < mail transfer protocols, such as SMTP. --- > that if the specified character set includes 8-bit data, a > Content-Transfer-Encoding header field and a corresponding > encoding on the data are required in order to transmit the > message via some mail transfer protocols, such as SMTP. 1446c1380 < wide variations in practice. In order to eliminate such --- > wide variations in practice. In order to elminate such 1461c1395 < NOTE: RFC 821 explicitly specifies "ASCII", and --- > Note: RFC 821 explicitly specifies "ASCII", and 1463,1477c1397,1411 < Standard. Insofar as one of the purposes of < specifying a Content-Type and character set is to < permit the receiver to unambiguously determine how < the sender intended the coded message to be < interpreted, assuming anything other than "strict < ASCII" as the default would risk unintentional and < incompatible changes to the semantics of messages < now being transmitted. This also implies that < messages containing characters coded according to < national variations on ISO 646, or using code- < switching procedures (e.g., those of ISO 2022), as < well as 8-bit or multiple octet character < encodings MUST use an appropriate character set < specification to be consistent with this < specification. --- > Standard rather than the international standard. > Insofar as one of the purposes of specifying a > Content-Type and character set is to permit the > receiver to unambiguously determine how the sender > intended the coded message to be interpreted, > assuming anything other than "strict ASCII" as the > default would risk unintentional and incompatible > changes to the semantics of messages now being > transmitted. This also implies that messages > containing characters coded according to national > variations on ISO 646, or using code-switching > procedures (e.g., those of ISO 2022), as well as > 8-bit or multiple octet character encodings MUST > use an appropriate character set specification to > be consistent with this specification. 1490a1425 > recipient. Such private agreements are discouraged and 1499c1434 < INTERNET MIME: Multipurpose Internet Mail Extensions 24 --- > INTERNET DRAFT Internet Message Body Format 23 1502d1436 < recipient. Such private agreements are discouraged and 1512c1446 < world's languages in electronic mail. --- > world's languages in electronic mail. 1518c1452 < exists. It is our hope that ISO 10646 or some --- > exists. It is our hope that ISO-10646 or some 1520c1454 < character set which can then be specified for use --- > character set which can then be specfied for use 1522c1456 < definition we cannot specify the use of ISO 10646, --- > definition we cannot specify the use of ISO-10646, 1532c1466 < 8859]. Note that the ISO 646 character sets --- > 8859]. Note that the ISO-646 character sets 1538c1472,1473 < through 9. --- > through 9, though a value of "10" is expected > to be defined in 1992. 1540,1542c1475,1489 < Note that the character set used, if anything other than < US-ASCII, must always be explicitly specified in the < Content-Type field. --- > ISO-2022-jp -- ISO-2022, as defined in [ISO-2022] > specifies ways of designating and accessing > character sets, rather than, itself, being a > character set. Its use in mail will probably > be strongly desired by communities who are > already using it locally to handle multiple > sets of characters and multi-byte characters. > It appears necessary to explicitly specify > the ISO-2022 methods that will be permitted > in text mail so as to avoid the need for > private agreements about, e.g., the specific > character sets being used in messages. A > specification corresponding to the existing > practice of ISO-2022 use in Japan is included > as Appendix F. 1544,1548d1490 < No other character set name may be used in Internet mail < without the publication of a formal specification and its < registration with IANA as described in Appendix F, or by < private agreement, in which case the character set name must < begin with "X-". 1550,1551d1491 < Implementors are discouraged from defining new character < sets for mail use unless absolutely necessary. 1553,1555d1492 < The "charset" parameter has been defined primarily for the < purpose of textual data, and is described in this section < for that reason. However, it is conceivable that non- 1558a1496 > 1561c1499 < --- > INTERNET DRAFT Internet Message Body Format 24 1564c1502,1504 < INTERNET MIME: Multipurpose Internet Mail Extensions 25 --- > Note that the character set used, if anything other than > US-ASCII, must always be explicitly specified in the > Content-Type field. 1565a1506,1509 > The use of the string "ISO-10646" as a character set > specification is hereby reserved for future use, once the > ongoing efforts to define a standard universal character set > are completed. 1566a1511,1529 > No other character set name should be used in Internet mail > without the publication of a formal specification and its > registration with IANA, or by private agreement, in which > case the character set name should begin with "x-". Parties > wishing to use additional character sets and desiring to > label them uniformly might wish to consult [RFC-CHAR], which > names and defines a large number of additional character > sets. Implementors who wish to use one of the character > sets from that document should either publish a > specification of its use in internet mail, or should prefix > the character set name from [RFC-CHAR] with the characters > "X-". > > Implementors are discouraged from defining new character > sets for mail use unless absolutely necessary. > > The "charset" parameter has been defined primarily for the > purpose of textual data, and is described in this section > for that reason. However, it is conceivable that non- 1575,1581c1538,1540 < ISO-8859-1, which, like all the ISO-8859 family of character < sets, is a superset of US-ASCII. More generally, if a < widely-used character set is a subset of another character < set, and a message contains only characters in the widely- < used subset, it should be labeled as being in that subset. < This will increase the chances that the recipient will be < able to view the mail correctly. --- > ISO-8859-1, which is a superset of US-ASCII. This will > increase the chances that the recipient will be able to view > the mail correctly. 1583c1542 < 7.1.2 The Text/plain subtype --- > 7.1.2 The Text/richtext subtype 1585,1592d1543 < The primary subtype of text is "plain". This indicates < plain (unformatted) text. The default Content-Type for < Internet mail, "text/plain; charset=us-ascii", describes < existing Internet practice, that is, it is the type of < message body defined by RFC 822. < < 7.1.3 The Text/richtext subtype < 1605a1557,1566 > > > > > > > > INTERNET DRAFT Internet Message Body Format 25 > > 1622,1631d1582 < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 26 < < 1634c1585 < of course a different charset parameter was specified in the --- > of course a different charset parameter was specfied in the 1637,1656c1588,1606 < used to mark the beginning of a formatting command. < Formatting instructions consist of formatting commands < surrounded by angle brackets ("<>", ASCII 60 and 62). Each < formatting command may be no more than 40 characters in < length, all in US-ASCII, restricted to the alphanumeric and < hyphen ("-") characters. Formatting commands may be preceded < by a forward slash or solidus ("/", ASCII 47), making them < negations, and such negations must always exist to balance < the initial opening commands, except as noted below. Thus, < if the formatting command "" appears at some point, < there must later be a "" to balance it. There are < only three exceptions to this "balancing" rule: First, the < command "" is used to represent a literal "<" character. < Second, the command "" is used to represent a required < line break. (Otherwise, CRLFs in the data are treated as < equivalent to a single SPACE character.) Finally, the < command "" is used to represent a page break. (NOTE: < The 40 character limit on formatting commands does not < include the "<", ">", or "/" characters that might be < attached to such commands.) --- > used to begin a formatting command. Formatting instructions > consist of formatting commands surrounded by angle brackets > ("<>", ASCII 60 and 62). Each formatting command may be no > more than 40 characters in length, all in US-ASCII, > restricted to the alphanumeric and hyphen ("-") characters. > Formatting commands that begin with a forward slash or > solidus ("/", ASCII 47) are negations, and such negations > must always exist to balance the initial opening commands. > Thus, if the formatting command "" appears at some > point, there must later be a "" to balance it. There > are only three exceptions to this "balancing" rule: First, > the command "" is used to represent a literal "<" > character. Second, the command "" is used to represent > a required line break. (Otherwise, CRLFs in the data are > treated as equivalent to a single SPACE character.) > Finally, the command "" is used to represent a page > break. (NOTE: The 40 character limit on formatting > commands does not include the "<", ">", or "/" characters > that might be attached to such commands.) 1668a1619,1631 > > > > > > > > > > > INTERNET DRAFT Internet Message Body Format 26 > > 1684,1696d1646 < < < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 27 < < 1733,1737c1683 < balancing is allowed. < nl -- causes a line break. No balancing is < allowed. < np -- causes a page break. No balancing is < allowed. --- > balancing is required. 1739,1742d1684 < Each positive formatting command affects all subsequent text < until the matching negative formatting command. Such pairs < of formatting commands must be properly balanced and nested. < Thus, a proper way to describe text in bold italics is: 1744d1685 < the-text 1746d1686 < or, alternately, 1748d1687 < the-text 1751a1691 > 1753a1694 > INTERNET DRAFT Internet Message Body Format 27 1756c1697,1700 < --- > nl -- causes a line break. No balancing is > required. > np -- causes a page break. No balancing is > required. 1757a1702,1705 > Each positive formatting command affects all subsequent text > until the matching negative formatting command. Such pairs > of formatting commands must be properly balanced and nested. > Thus, a proper way to describe text in bold italics is: 1759c1707 < INTERNET MIME: Multipurpose Internet Mail Extensions 28 --- > the-text 1760a1709 > or, alternately, 1761a1711,1712 > the-text > 1765c1716 < the-text --- > the-text 1801c1752,1762 < Richtext also differentiates between "hard" and "soft" line --- > > > > > > > > INTERNET DRAFT Internet Message Body Format 28 > > > Richtext also differentiates betweeen "hard" and "soft" line 1809,1811c1770,1772 < but when soft line breaks immediately follow a or a < tag they should be ignored rather than treated < as white space. --- > but when soft line breaks immediately follow a or > a tag they should be ignored rather than > treated as white space. 1815a1777,1780 > Now is the time for > all good men > (and women>) to > come 1816a1782,1785 > to the aid of their > > beloved country. Stupid quote! > -- the end 1818,1836d1786 < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 29 < < < Now is the time for < all good men < (and women>) to < come < < to the aid of their < < beloved country. Stupid < quote! -- the end < 1865a1816,1826 > > > > > > > > > INTERNET DRAFT Internet Message Body Format 29 > > 1881,1891d1841 < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 30 < < 1903c1853 < IMPLEMENTATION NOTE: In some environments, it --- > Implementation note: In some environments, it 1936,1950d1885 < < < < < < < < < < < < < < < 1954c1889 < INTERNET MIME: Multipurpose Internet Mail Extensions 31 --- > INTERNET DRAFT Internet Message Body Format 30 1982,1985c1917,1921 < Such other fields are permitted to appear in body parts but < should not be depended on. "X-" fields may be created for < experimental or private purposes, with the recognition that < the information they contain may be lost at some gateways. --- > Such other fields are permitted to appear in body parts only > for ease of conversion between messages and body parts. > "X-" fields may be created for experimental or private > purposes, with the recognition that the information they > contain may be lost at some gateways. 2015d1950 < 2019c1954 < INTERNET MIME: Multipurpose Internet Mail Extensions 32 --- > INTERNET DRAFT Internet Message Body Format 31 2058c1993 < parameter value from the Content-Type header field. --- > parameter from the Content-Type header field. 2084c2019 < INTERNET MIME: Multipurpose Internet Mail Extensions 33 --- > INTERNET DRAFT Internet Message Body Format 32 2090,2091c2025,2026 < Content-Type: multipart/mixed; < boundary=gc0p4Jq0M2Yt08jU534c0p --- > Content-Type: multipart/mixed; > boundary=gc0p4Jq0M2Yt08jU534c0p 2099c2034 < --gc0p4Jq0M2Yt08jU534c0p --- > --gc0p4Jq0M2Yt08jU534c0p 2122,2130c2057,2063 < itself begin with a CRLF before the first encapsulation line < -- that is, if the "preamble" area is not used, the message < headers must be followed by TWO CRLFs. This is indeed how < such messages should be composed. A tolerant mail reading < program, however, may interpret a body of type multipart < that begins with an encapsulation line NOT initiated by a < CRLF as also being an encapsulation boundary, but a < compliant mail sending program must not generate such < messages. --- > itself begin with a CRLF before the first encapsulation > line. This is indeed how such messages should be composed. > A tolerant mail reading program, however, may interpret a > body of type multipart that begins with an encapsulation > line NOT initiated by a CRLF as also being an encapsulation > boundary, but a compliant mail sending program must not > generate such messages. 2145a2079,2080 > > 2149c2084 < INTERNET MIME: Multipurpose Internet Mail Extensions 34 --- > INTERNET DRAFT Internet Message Body Format 33 2152c2087 < --gc0p4Jq0M2Yt08jU534c0p-- --- > --gc0p4Jq0M2Yt08jU534c0p-- 2189c2124 < MIME-Version: 1.0 --- > MIME-Format: 1.0 2214c2149 < INTERNET MIME: Multipurpose Internet Mail Extensions 35 --- > INTERNET DRAFT Internet Message Body Format 34 2238,2239c2173,2174 < space must be presumed to have been added by a gateway, and < should be deleted.) It is formally specified by the --- > space should be presumed to have been added by a gateway, > and should be deleted.) It is formally specified by the 2246,2247c2181 < bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / < "_" --- > bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" 2260,2262c2194 < ; when content-type is < multipart < ; There must be no space --- > ; There should be no space 2268,2269c2200 < preamble := *text ; to be ignored upon < receipt. --- > preamble := *text ; to be ignored upon receipt. 2270a2202 > epilogue := *text ; to be ignored upon receipt. 2271a2204 > part-encapsulation = <"message" as defined in RFC 822, 2276d2208 < 2279c2211 < INTERNET MIME: Multipurpose Internet Mail Extensions 36 --- > 2282,2283c2214 < epilogue := *text ; to be ignored upon < receipt. --- > INTERNET DRAFT Internet Message Body Format 35 2285c2216 < part-encapsulation = <"message" as defined in RFC 822, --- > 2325c2256 < content of the various parts are interchangeable. The user --- > content of the various parts are interchangable. The user 2334a2266,2268 > To: Ned Freed > Subject: Formatted text mail > Content-Type: multipart/alternative; boundary=boundary42 2340a2275 > 2344c2279 < INTERNET MIME: Multipurpose Internet Mail Extensions 37 --- > INTERNET DRAFT Internet Message Body Format 36 2347,2352d2281 < To: Ned Freed < Subject: Formatted text mail < MIME-Version: 1.0 < Content-Type: multipart/alternative; boundary=boundary42 < < 2390,2393c2319,2322 < non-MIME-compliant mail reader. While this < approach does impose some burden on compliant mail < readers, interoperability with older mail readers < was deemed to be more important in this case. --- > non-compliant mail reader. While this approach > does impose some burden on compliant mail readers, > interoperability with older mail readers was > deemed to be more important in this case. 2400a2330,2332 > be shown multiple versions of the same data. Either the > user should be shown the last recognized version or should > explicitly be given the choice. 2401a2334 > 7.2.4 The Multipart/digest subtype 2406d2338 < 2409c2341 < INTERNET MIME: Multipurpose Internet Mail Extensions 38 --- > 2412,2415c2344 < be shown multiple versions of the same data. Either the < user should be shown the last recognized version or should < explicitly be given the choice. < 7.2.4 The Multipart/digest subtype --- > INTERNET DRAFT Internet Message Body Format 37 2416a2346 > 2430d2359 < MIME-Version: 1.0 2470a2400,2405 > > > > > > 2474c2409 < INTERNET MIME: Multipurpose Internet Mail Extensions 39 --- > INTERNET DRAFT Internet Message Body Format 38 2483c2418 < Type field. Additional subtypes, "partial" and "External- --- > Type field. Additional subtypes, "partial" and "external- 2539c2474 < INTERNET MIME: Multipurpose Internet Mail Extensions 40 --- > INTERNET DRAFT Internet Message Body Format 39 2565c2500 < number=2; total=3; --- > number=2; total=3 2575c2510 < number=3; total=3; --- > number=3; total=3 2586c2521 < reassembled partial message must be those of the "inner" --- > reassembled partial message should be those of the "inner" 2604c2539 < INTERNET MIME: Multipurpose Internet Mail Extensions 41 --- > INTERNET DRAFT Internet Message Body Format 40 2610c2545 < messages. In this process the following rules must be --- > messages. In this process the following rules should be 2615,2616c2550,2551 < "Content-" and "Message-ID", must be copied, in < order, to the new message. --- > "Content-", should be copied, in order, to the new > message. 2619,2623c2554,2557 < which start with "Content-" and "Message-ID" must < be appended, in order, to the headers of the new < message. Any headers in the enclosed message < which do not start with "Content-" (except for < "Message-ID") will be ignored. --- > which start with "Content-" should be appended, in > order, to the headers of the new message. Any > headers in the enclosed message which do not start > with "Content-" will be ignored. 2636d2569 < MIME-Version: 1.0 2643d2575 < Message-ID: anotherid@foo.com 2654d2585 < MIME-Version: 1.0 2660a2592,2594 > Then, when the fragmented message is reassembled, the > resulting message to be displayed to the user should look > something like this: 2665a2600 > 2669c2604 < INTERNET MIME: Multipurpose Internet Mail Extensions 42 --- > INTERNET DRAFT Internet Message Body Format 41 2672,2675d2606 < Then, when the fragmented message is reassembled, the < resulting message to be displayed to the user should look < something like this: < 2680,2681c2611 < Message-ID: anotherid@foo.com < MIME-Version: 1.0 --- > Message-ID: id1@host.com 2688,2693c2618 < It should be noted that, because some message transfer < agents may choose to automatically fragment large messages, < and because such agents may use different fragmentation < thresholds, it is possible that the pieces of a partial < message, upon reassembly, may prove themselves to comprise a < partial message. This is explicitly permitted. --- > 7.3.3 The Message/External-body' subtype 2695,2703d2619 < It should also be noted that the inclusion of a "References" < field in the headers of the second and subsequent pieces of < a fragmented message that references the Message-Id on the < previous piece may be of benefit to mail readers that < understand and track references. However, the generation of < such "References" fields is entirely optional. < < 7.3.3 The Message/External-Body subtype < 2707c2623,2625 < the external data. --- > the external data. The only mandatory parameter is > "access-type"; all of the other parameters may be mandatory > or optional depending on the value of access-type. 2709,2752c2627 < When a message body or body part is of type < "message/external-body", it consists of a message header, < two consecutive CRLFs, and the message header for the < encapsulated message. If another pair of consecutive CRLFs < appears, this of course ends the message header for the < encapsulated message. However, since the encapsulated < message's body is itself external, it does NOT appear in the < area that follows. For example, consider the following < message: < < Content-type: message/external-body; access- < type=local-file; < name=/u/nsb/Me.gif < < Content-type: image/gif < < < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 43 < < < THIS IS NOT REALLY THE BODY! < < The area at the end, which might be called the "phantom < body", is ignored for most external-body messages. However, < it may be used to contain auxilliary information for some < such messages, as indeed it is when the access-type is < "mail-server". Of the access-types defined by this < document, the phantom body is used only when the access-type < is "mail-server". In all other cases, the phantom body is < ignored. < < The only always-mandatory parameter for message/external- < body is "access-type"; all of the other parameters may be < mandatory or optional depending on the value of access-type. < < ACCESS-TYPE -- One or more case-insensitive words, --- > ACCESS-TYPE -- one or more case-insensitive words, 2757,2759c2632,2636 < and "MAIL-SERVER". Future values, except for < experimental values beginning with "X-", must be < registered with IANA, as described in Appendix F . --- > and "MAIL-SERVER". (The value "ANON-FTP" is used > to specify the FTP protocol with login > "anonymous".) Future values should be registered > with IANA in the same manner that Content-type and > charset values are registered. 2761,2762c2638,2641 < In addition, the following two parameters are optional for < ALL access-types: --- > For the "mail-server", "ftp" and "anon-ftp" access-types, > the additional mandatory parameters are name and site. For > the "afs" and "local-file" access types, only the name > parameter is mandatory. 2764,2767c2643,2644 < EXPIRATION -- The date (in the RFC 822 "date-time" < syntax, as extended by RFC 1123 to permit 4 digits < in the date field) after which the existence of < the external data is not guaranteed. --- > NAME -- The name of a file or other token that can > be used to reference the external body data. 2769,2849c2646 < SIZE -- The size (in octets) of the data. The < intent of this parameter is to help the recipient < decide whether or not to expend the necessary < resources to retrieve the external data. < < PERMISSION -- A field that indicates whether or < not it is expected that clients might also attempt < to overwrite the data. By default, or if < permission is "read", the assumption is that they < are not, and that if the data is retrieved once, < it is never needed again. If PERMISSION is "read- < write", this assumption is invalid, and any local < copy must be considered no more than a cache. < "Read" and "Read-write" are the only defined < values of permission. < < The precise semantics of the access-types defined here are < described in the sections that follow. < < 7.3.3.1 The "ftp" and "tftp" access-types < < < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 44 < < < An access-type of FTP or TFTP indicates that the message < body is accessible as a file using the FTP [RFC-959] or TFTP < [RFC-783] protocols, respectively. For these access-types, < the following additional parameters are mandatory: < < NAME -- The name of the file that contains the < external body. < < SITE -- A machine from which the file may be < obtained, using the given protocol < < Before the data is retrieved, using these protocols, the < user will generally need to be asked to provide a login id < and a password for the machine named by the site parameter. < < In addition, the following optional parameters may also < appear when the access-type is FTP or ANON-FTP: < < DIRECTORY -- A directory from which the data named < by NAME should be retrieved. < < MODE -- A transfer mode for retrieving the < information, e.g. "image". < < 7.3.3.2 The "anon-ftp" access-type < < The "anon-ftp" access-type is identical to the "ftp" access < type, except that the user need not be asked to provide a < name and password for the specified site. Instead, the ftp < protocol will be used with login "anonymous" and a password < that corresponds to the user's email address. < < 7.3.3.3 The "local-file" and "afs" access-types < < An access-type of "local-file" indicates that the message < body is accessible as a file on the local machine. An < access-type of "afs" indicates that the file is accessible < via the global AFS file system. In both cases, only a < single parameter is required: < < NAME -- The name of the file that contains the < external body data. < < The following optional parameter may be used to describe the < locality of reference for the data, that is, the site or < sites at which the file is expected to be visible: < < SITE -- A domain specifier for a machine or set of --- > SITE -- a domain specifier for a machine or set of 2855a2653,2654 > that is expected to be universally available, > e.g., via a global file system. 2856a2656,2658 > EXPIRATION -- The date (with the RFC 822 "date- > time" syntax) after which the existence of the > external data is not guaranteed. 2861d2662 < 2864d2664 < INTERNET MIME: Multipurpose Internet Mail Extensions 45 2865a2666 > 2867,2868d2667 < that is expected to be universally available, < e.g., via a global file system. 2870c2669 < 7.3.3.4 The "mail-server" access-type --- > INTERNET DRAFT Internet Message Body Format 42 2872,2874d2670 < The "mail-server" access-type indicates that the message < body is available from a mail server. The mandatory < parameter for this access-type is: 2876,2877c2672,2674 < SERVER -- The email address of the mail server < from which the data can be obtained. --- > DIRECTORY -- A directory from which the data named > by NAME should be retrieved. This is particularly > useful for the FTP access-type. 2879,2884c2676,2677 < Because mail servers accept a variety of syntax, some of < which is multiline, the full command to be sent to a mail < server is not included as a parameter on the content-type < line. Instead, it may be provided as the "phantom body" < when the content-type is message/external-body and the < access-type is mail-server. --- > MODE -- A transfer mode for retrieving the > information, with access-type FTP. 2886,2890c2679,2687 < Note that MIME does not define a mail server syntax. < Rather, it allows the inclusion of arbitrary mail server < commands in the phantom body. Implementations should < include the phantom body in the body of the message it sends < to the mail server address to retrieve the relevant data. --- > PERMISSION -- A field that indicates whether or > not it is expected that clients might also attempt > to overwrite the data. By default, or if > permission is "read", the assumption is that they > are not, and that if the data is retrieved once, > it is never needed again. If PERMISSION is "read- > write", this assumption is invalid, and any local > copy should be considered no more than a cache. > No other values of permission are defined here. 2892,2893d2688 < 7.3.3.5 Examples and Further Explanations < 2920a2716,2721 > convenient place for additional data that cannot be included > in the content-type header field. In particular, if the > "access-type" value is "mail-server", then the trailing area > should contain commands to be sent to the mail server at the > address given by NAME@SITE, where NAME and SITE are the > values of the NAME and SITE parameters, respectively. 2921a2723,2725 > The embedded message header fields which appear in the body > of the message/external-body data can be used to declare the > Content-type of the external body. Thus a complete 2925a2730 > 2929c2734 < INTERNET MIME: Multipurpose Internet Mail Extensions 46 --- > INTERNET DRAFT Internet Message Body Format 43 2932,2941d2736 < convenient place for additional data that cannot be included < in the content-type header field. In particular, if the < "access-type" value is "mail-server", then the trailing area < must contain commands to be sent to the mail server at the < address given by NAME@SITE, where NAME and SITE are the < values of the NAME and SITE parameters, respectively. < < The embedded message header fields which appear in the body < of the message/external-body data can be used to declare the < Content-type of the external body. Thus a complete 2947,2948d2741 < MIME-Version: 1.0 < Message-ID: id1@host.com 2956,2958c2749,2751 < access-type=ANON-FTP; < directory="pub"; < mode="image"; --- > access-type = ANON-FTP; > directory = "pub"; > mode = "image"; 2967c2760 < access-type=AFS --- > access-type = AFS 2974,2975c2767,2769 < access-type=mail-server < server="listserv@bogus.bitnet"; --- > name="listserv"; > site="bogus.bitnet"; > access-type = mail-server 2980,2981c2774 < get rfc-xxxx doc < --- > SEND-FILE: /u/nsb/writing/rfcs/RFC-XXXX.ps 2986,2996d2778 < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 47 < < 2999,3000c2781,2782 < outer and inner parts must be merged using the same rules as < for message/partial. In particular, this means that the --- > outer and inner parts should be merged using the same rules > as for message/partial. In particular, this means that the 3010,3015d2791 < Note that the body of a message of type "message/external- < body" is governed by the basic syntax for an RFC 822 < message. In particular, anything before the first < consecutive pair of CRLFs is header information, while < anything after it is body information, which is ignored for < most access-types. 3020,3055d2795 < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < 3059c2799 < INTERNET MIME: Multipurpose Internet Mail Extensions 48 --- > INTERNET DRAFT Internet Message Body Format 44 3066c2806 < for data to be processed by mail-based uses of application --- > for data to be proceessed by mail-based uses of application 3092,3093c2832,2833 < usages must be registered with IANA, as described in < Appendix F. --- > usages must be registered with IANA, as described earlier in > this document. 3095c2835 < 7.4.1 The Application/Octet-Stream (primary) subtype --- > 7.4.1 The Application/Octet-Stream subtype 3098c2838 < used to indicate that a body or body part of a message is --- > used to indicate that the body or body part of a message is 3106,3108c2846 < data. This is intended as information for the < human recipient rather than for any automatic < processing. --- > data 3115a2854,2855 > applied -- that is, the leftmost conversion must > have occurred first, and conversions are undone 3124c2864 < INTERNET MIME: Multipurpose Internet Mail Extensions 49 --- > INTERNET DRAFT Internet Message Body Format 45 3127,3134c2867 < applied -- that is, the leftmost conversion must < have occurred first, and conversions are undone < from right to left. Note that NO conversion < values are defined by this document. Any < conversion values that that do not begin with "X-" < must be preceded by a published specification and < by registration with IANA, as described in < Appendix F. --- > from right to left 3147c2880 < Content-Type: application/octet-stream; --- > Content-Type: application/octet-stream ; 3149c2882 < conversions="x-encrypt,x-compress" --- > conversions= "encrypt,compress" 3180a2914,2918 > "off-the-shelf" interpreters. While it is usually safe to > send PostScript to a printer, where the potential for harm > is greatly constrained, implementors should consider all of > the following before they add interactive display of > PostScript messages to their mail readers. 3186d2923 < 3189c2926 < INTERNET MIME: Multipurpose Internet Mail Extensions 50 --- > 3192,3196c2929 < "off-the-shelf" interpreters. While it is usually safe to < send PostScript to a printer, where the potential for harm < is greatly constrained, implementors should consider all of < the following before they add interactive display of < PostScript messages to their mail readers. --- > INTERNET DRAFT Internet Message Body Format 46 3197a2931 > 3245a2980,2985 > PostScript provides operators for setting system-wide and > device-specific parameters. These parameter settings may be > retained across jobs and may potentially pose a threat to > the correct operation of the interpreter. The PostScript > operators that set system and device parameters include, but > may not be limited to, the setsystemparams and setdevparams 3254c2994 < INTERNET MIME: Multipurpose Internet Mail Extensions 51 --- > INTERNET DRAFT Internet Message Body Format 47 3257,3262d2996 < PostScript provides operators for setting system-wide and < device-specific parameters. These parameter settings may be < retained across jobs and may potentially pose a threat to < the correct operation of the interpreter. The PostScript < operators that set system and device parameters include, but < may not be limited to, the setsystemparams and setdevparams 3310a3045 > are found. 3311a3047 > 7.4.3 The Application/ODA subtype 3312a3049,3050 > The "ODA" subtype of application is used to mark message > bodies or parts as being information encoded according to 3316d3053 < 3319c3056 < INTERNET MIME: Multipurpose Internet Mail Extensions 52 --- > 3322c3059 < are found. --- > INTERNET DRAFT Internet Message Body Format 48 3324d3060 < 7.4.3 The Application/ODA subtype 3326,3333c3062,3066 < The "ODA" subtype of application is used to mark message < bodies or parts as being information encoded according to < the Office Document Architecture [ODA] standards, using the < ODIF representation format. For application/oda, the < Content-Type line should also specify an attribute/value < pair that indicates the document application profile (DAP), < using the key word "profile". Thus an appropriate header < field might look like this: --- > the Office Document Architecture [ODA] standards. For > application/oda, the Content-Type line should also specify > an attribute/value pair that indicates the document > application profile (DAP), using the key word "profile". > Thus an appropriate header field might look like this: 3380a3114,3120 > > > > > > > 3384c3124 < INTERNET MIME: Multipurpose Internet Mail Extensions 53 --- > INTERNET DRAFT Internet Message Body Format 49 3391,3393c3131,3135 < format. These names are case insensitive. Three initial < subtypes are "G3Fax" for Group Three Fax, "jpeg" for the < JPEG format, JFIF encoding, and "gif" for GIF format [GIF]. --- > format. These names are case insensitive. A few subtypes > are "G3Fax" for Group Three Fax, "jpeg" for the JPEG format, > "gif" for GIF format, and "pbm", "pgm", and "ppm" for the > "portable bitmap" formats for black and white, grey scale, > or color images. 3394a3137,3154 > A special subtype is "tiff-b-netfax" which refers to the > bi-level (e.g., fax) image file format proposed by the IETF > Network Fax Working Group described in the Internet Draft > [RFC-NETFAX]. The proposed format is basically TIFF-B with > some restrictions and supports MMR, MR, and MH compression > as well as uncompressed images. MMR compression is > recommended where possible. > > A Content-Type of "image/pbm" indicates portable bitmap data > (PBM) data encoded using the format described in the pbm(5) > manual entry in the PBMPLUS sources, dated 91-09-21. Note > that both the ASCII and RAWBITS formats are allowed (magic > numbers P1 and P4). PBMPLUS is available via anonymous FTP > at many sites. Similarly, Content-Types of "image/pgm" and > "image/ppm" refer to the pgm(5) and ppm(5) manual entries > (magic numbers P2/P5 and P3/P6, respectively). For further > details on these formats, contact jef@well.sf.ca.us. > 3402,3404c3162,3167 < of this subtype is strongly discouraged. Instead, it is < recommended that the sender should convert image/g3fax parts < to another format. --- > of this content is strongly discouraged. Instead, it is > recommended that the sender should convert it to another > format. The PBMPLUS package contains a program to convert a > one-dimensional g3fax image to a PBM image. The ISODE > package [ISODE] contains a program to convert a one- or > two-dimensional g3fax image to a PBM image. 3408c3171,3173 < IANA, as described in Appendix F. --- > IANA. For maximum interoperability within the Internet, > the Network Fax Working Group recommends the use of > "IMAGE/TIFF-B-NetFax" rather than "G3Fax." 3409a3175,3191 > > > > > > > > > > > > > > > INTERNET DRAFT Internet Message Body Format 50 > > 3441,3451d3222 < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 54 < < 3480,3510d3250 < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < 3514c3254 < INTERNET MIME: Multipurpose Internet Mail Extensions 55 --- > INTERNET DRAFT Internet Message Body Format 51 3579c3319 < INTERNET MIME: Multipurpose Internet Mail Extensions 56 --- > INTERNET DRAFT Internet Message Body Format 52 3591,3633c3331,3372 < Harald Tveit Alvestrand Timo Lehtinen < Randall Atkinson John R. MacMillan < Philippe Brandon Rick McGowan < Kevin Carosso Leo Mclaughlin < Uhhyung Choi Goli Montaser-Kohsari < Cristian Constantinof Keith Moore < Mark Crispin Tom Moore < Dave Crocker Erik Naggum < Terry Crowley Mark Needleman < Walt Daniels John Noerenberg < Frank Dawson Mats Ohrman < Hitoshi Doi Julian Onions < Kevin Donnelly Michael Patton < Keith Edwards David J. Pepper < Chris Eich Blake C. Ramsdell < Johnny Eriksson Luc Rooijakkers < Craig Everhart Marshall T. Rose < Patrik Faeltstroem Jonathan Rosenberg < Erik E. Fair Jan Rynning < Roger Fajman Harri Salminen < Alain Fontaine Michael Sanderson < James M. Galvin Masahiro Sekiguchi < Philip Gladstone Mark Sherman < Thomas Gordon Keld Jorn Simonsen < Phill Gross Bob Smart < James Hamilton Peter Speck < Steve Hardcastle-Kille Henry Spencer < David Herron Einar Stefferud < Bruce Howard Michael Stein < Bill Janssen Klaus Steinberger < Olle Jaernefors Peter Svanberg < Risto Kankkunen James Thompson < Phil Karn Steve Uhler < Alan Katz Stuart Vance < Tim Kehres Erik van der Poel < Neil Katin Guido van Rossum < Kyuho Kim Peter Vanderbilt < Anders Klemets Greg Vaudreuil < John Klensin Ed Vielmetti < Valdis Kletniek Ryan Waldron < Jim Knowles Wally Wedel < Stev Knowles Sven-Ove Westberg < Bob Kummerfeld Brian Wideen --- > Harald Tveit Alvestrand Vincent Lau > Randall Atkinson Timo Lehtinen > Philippe Brandon John R. MacMillan > Kevin Carosso Rick McGowan > Cristian Constantinof Leo Mclaughlin > Mark Crispin Goli Montaser-Kohsari > Dave Crocker Keith Moore > Terry Crowley Tom Moore > Walt Daniels Mark Needleman > Frank Dawson John Noerenberg > Hitoshi Doi Mats Ohrman > Kevin Donnelly Julian Onions > Keith Edwards Michael Patton > Chris Eich David J. Pepper > Johnny Eriksson Marshall T. Rose > Craig Everhart Jonathan Rosenberg > Patrik F.ltstr.m Jan Rynning > Erik E. Fair Harri Salminen > Roger Fajman Michael Sanderson > Alain Fontaine Masahiro Sekiguchi > James M. Galvin Mark Sherman > Philip Gladstone Keld J/rn Simonsen > Thomas Gordon Bob Smart > Phill Gross Einar Stefferud > James Hamilton Michael Stein > Steve Hardcastle-Kille Klaus Steinberger > David Herron Peter Svanberg > Bruce Howard James Thompson > Bill Janssen Steve Uhler > Olle Jaernefors Stuart Vance > Risto Kankkunen Erik van der Poel > Phil Karn Guido van Rossum > Alan Katz Peter Vanderbilt > Tim Kehres Greg Vaudreuil > Neil Katin Ed Vielmetti > Anders Klemets Ryan Waldron > John Klensin Sven-Ove Westberg > Valdis Kletniek Brian Wideen > Jim Knowles John Wobus > Stev Knowles Glenn Wright > Bob Kummerfeld Rayan Zachariassen > Pekka Kytolaakso David Zimmerman 3635,3650d3373 < < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 57 < < < Pekka Kytolaakso John Wobus < Stellan Lagerstrom Glenn Wright < Vincent Lau Rayan Zachariassen < Donald Lindsay David Zimmerman 3658,3705d3380 < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < 3709c3384 < INTERNET MIME: Multipurpose Internet Mail Extensions 58 --- > INTERNET DRAFT Internet Message Body Format 53 3716c3391 < support all of the Content-Types described, nor that they --- > implement all of the Content-Types described, nor that they 3774c3449 < INTERNET MIME: Multipurpose Internet Mail Extensions 59 --- > INTERNET DRAFT Internet Message Body Format 54 3794c3469 < redundant parts of --- > redundant pieces parts of 3824c3499 < such systems will at least be able to treat the data as --- > they will at least be able to treat the data as 3839c3514 < INTERNET MIME: Multipurpose Internet Mail Extensions 60 --- > INTERNET DRAFT Internet Message Body Format 55 3904c3579 < INTERNET MIME: Multipurpose Internet Mail Extensions 61 --- > INTERNET DRAFT Internet Message Body Format 56 3918,3919c3593,3594 < There exist many widely-deployed non-conformant MTAs in the < Internet. These MTAs, speaking the SMTP protocol, alter --- > There exist many widely-deployed non-conformant MTA's in the > Internet. These MTA's, speaking the SMTP protocol, alter 3926c3601 < range of networking technologies and known broken MTAs --- > range of networking technologies and known broken MTA's 3932c3607 < some gateways to systems that use the EBCDIC character set. --- > gateways to systems that use the EBCDIC character set. 3969c3644 < INTERNET MIME: Multipurpose Internet Mail Extensions 62 --- > INTERNET DRAFT Internet Message Body Format 57 3973,3978c3648,3653 < (HT)) on a line may be discarded by some transport < agents, while other transport agents may pad lines < with these characters so that all lines in a mail < file are of equal length. The persistence of < trailing white space, therefore, should not be < relied on. --- > (HT), etc.) on a line may be discarded by some > transport agents, while other transport agents may > pad lines with these characters so that all lines > in a mail file are of equal length. The > persistence of trailing white space, therefore, > should not be relied on. 4018c3693 < practices for MTAs. RFC 821 MTAs are prohibited from --- > practices for MTA's. RFC 821 MTA's are prohibited from 4034c3709 < INTERNET MIME: Multipurpose Internet Mail Extensions 63 --- > INTERNET DRAFT Internet Message Body Format 58 4071c3746 < but illustrates explicit versus implicit --- > but illustrates implicit versus explicit 4084c3759 < u-law-format audio data goes here.... --- > u-law-format audio data goes here.... 4087c3762 < Content-Type: image/gif --- > Content-Type: image/tiff-b-netfax 4099c3774 < INTERNET MIME: Multipurpose Internet Mail Extensions 64 --- > INTERNET DRAFT Internet Message Body Format 59 4109c3784 < This is richtext. --- > This is richtext. 4121c3796 < ... Additional text in ISO-8859-1 goes here ... --- > ... Closing text in ISO-8859-1 goes here ... 4164c3839 < INTERNET MIME: Multipurpose Internet Mail Extensions 65 --- > INTERNET DRAFT Internet Message Body Format 60 4167c3842 < Appendix D -- A Simple Richtext-to-Text Translator in C --- > Appendix D -- A Richtext-to-Text Translator in C 4175c3850 < simple 44-line C program that converts richtext input into --- > simple 43-line C program that converts richtext input into 4186,4187c3861,3862 < for (i=0; (i<49 && (c = getc(stdin)) != '>' < && c != EOF); ++i) { --- > for (i=0; (c = getc(stdin)) != '>' > && c != EOF; ++i) { 4191,4195c3866 < if (c != '>') while ((c = getc(stdin)) != < '>' < && c != EOF) {;} < if (c == EOF) break; < token[i] = '\0'; --- > token[i] = NULL; 4201c3872 < fputs("\n\n", stdout); --- > puts("\n\n", stdout); 4218a3890,3893 > } > } /* Ignore all other tokens */ > } else if (c != '\n') { > putc(c, stdout); 4229c3904 < INTERNET MIME: Multipurpose Internet Mail Extensions 66 --- > INTERNET DRAFT Internet Message Body Format 61 4232,4234c3907 < } < } /* Ignore all other tokens */ < } else if (c != '\n') putc(c, stdout); --- > } 4244c3917 < the above program is all that is necessary in order to --- > the above program is all that is *necessary* in order to 4290a3964,3965 > > 4294c3969 < INTERNET MIME: Multipurpose Internet Mail Extensions 67 --- > INTERNET DRAFT Internet Message Body Format 62 4311a3987,3988 > MIME-Version := 1*token > 4316,4317c3993 < bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / < "_" --- > bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" 4327,4328c4003,4004 < PRINTABLE" / < "8BIT" / "7BIT" / --- > PRINTABLE"/ > "8BIT" / "7BIT" 4331c4007 < Content-Type := type "/" subtype *[";" parameter] --- > Content-Type:= type "/" subtype *[";" parameter] 4335,4336d4010 < ; when content-type is < multipart 4342,4343c4016 < epilogue := *text ; to be ignored upon < receipt. --- > epilogue := text ; to be ignored upon receipt. 4345c4018,4022 < MIME-Version := 1*text --- > part-encapsulation = <"message" as defined in RFC 822, > with all header fields optional, and with the > specified delimiter not occurring anywhere in > the message body, either on a line by itself > or as a substring anywhere.> 4354,4355d4030 < < 4359c4034 < INTERNET MIME: Multipurpose Internet Mail Extensions 68 --- > INTERNET DRAFT Internet Message Body Format 63 4364,4368c4039 < part-encapsulation = <"message" as defined in RFC 822, < with all header fields optional, and with the < specified delimiter not occurring anywhere in < the message body, either on a line by itself < or as a substring anywhere.> --- > preamble := text ; to be ignored upon receipt. 4370,4372d4040 < preamble := *text ; to be ignored upon < receipt. < 4380c4048 < / "=" ; parameter values --- > / "=" ; parameter values 4383,4384c4051 < type := "application" / "audio" ; case- < insensitive --- > type := "application" / "audio" 4392c4059 < intervening white space, by any token> --- > intervening white space, by any token> 4421d4087 < 4424d4089 < INTERNET MIME: Multipurpose Internet Mail Extensions 69 4427d4091 < Appendix F -- IANA Registration Procedures 4429,4441d4092 < MIME has been carefully designed to have extensible < mechanisms, and it is expected that the set of content- < type/subtype pairs and their associated parameters will grow < significantly with time. Several other MIME fields, notably < character set names, access-type parameters for the < message/external-body type, conversions parameters for the < application type, and possibly even Content-Transfer- < Encoding values, are likely to have new values defined over < time. In order to ensure that the set of such values is < developed in an orderly, well-specified, and public manner, < MIME defines a registration process which uses the Internet < Assigned Numbers Authority (IANA) as a central registry for < such values. 4443,4447d4093 < In general, parameters in the content-type header field are < used to convey supplemental information for various content < types, and their use is defined when the content-type and < subtype are defined. New parameters should not be defined < as a way to introduce new functionality. 4449,4453d4094 < In order to simplify and standardize the registration < process, this appendix gives templates for the registration < of new values with IANA. Each of these is given in the form < of an email message template, to be filled in by the < registering party. 4455,4485d4095 < F.1 Registration of New Content-type/subtype Values < < Note that MIME is generally expected to be extended by < subtypes. If a new fundamental top-level type is needed, < its specification should be published as an RFC and be < subject to the Internet standards process. < < To: IANA@isi.edu < Subject: Registration of new MIME content-type/subtype < < MIME type name: < < (If the above is not an existing top-level MIME type, < please explain why an existing type cannot be used.) < < MIME subtype name: < < Required parameters: < < Optional parameters: < < Encoding considerations: < < Security considerations: < < < < < < < 4489c4099 < INTERNET MIME: Multipurpose Internet Mail Extensions 70 --- > INTERNET DRAFT Internet Message Body Format 64 4492c4102 < Published specification: --- > Appendix F -- ISO-2022-jp 4494,4496c4104,4108 < (The published specification must be an Internet RFC if < a new top-level type is being defined, and must be a < publicly available specification in any case.) --- > This appendix briefly describes the existing practice for > the use of ISO-2022 in Japanese electronic mail. This > description is for informational purposes only, and is not > intended to guide an implementation of ISO-2022-jp mail > senders or readers. 4498,4500c4110,4118 < Person & email address to contact for further < information: < F.2 Registration of New Character Set Values --- > ISO-2022 is a scheme for switching between multiple > character sets. Japanese usage of it uses ASCII as a base > character set. Thus it is possible that a message labelled > as text/iso-2022-jp is entirely in US-ASCII, and just > showing the text as if it were ASCII is not an unreasonable > strategy for an implementation that does not really > understand ISO-2022-jp. A better, nearly-minimal strategy > would be to at least inform the user of a character set > shift when escape sequences are encountered. 4502,4503c4120,4124 < To: IANA@isi.edu < Subject: Registration of new MIME character set value --- > In ISO-2022-jp, announcer sequences ESC 2/0 4/1, ESC 2/0 4/8 > and ESC 2/0 4/10 are implicitly assumed. These announcer > sequences must not appear as a part of the data. (They mean > "Use G0 only and no locking-shifts are allowed," "Use 94 > characters sets only" and "Use 7-bits.") 4505c4126,4128 < MIME character set name: --- > Designation sequences ESC 2/8 4/2, ESC 2/8 4/10, ESC 2/4 4/0 > and ESC 2/4 4/2 are allowed. No other designation sequences > are allowed. Each escape sequence designates: 4507c4130,4136 < Published specification: --- > ESC 2/8 4/2: ASCII. > ESC 2/8 4/10: Left half of JIS X0201. (Japanese > version of 646) > ESC 2/4 4/0: JIS C6226-1978; so-called "Old JIS > Kanji." > ESC 2/4 4/2: JIS X0208-1983; so-called "New JIS > Kanji.") 4509,4510c4138,4139 < (The published specification must be an Internet RFC or < an international standard.) --- > No other escape sequences are allowed. At the beginning, > ESC 2/8 4/2 or ESC 2/8 4/10 may be omitted. 4512,4513c4141,4148 < Person & email address to contact for further < information: --- > As an exception to 2022, the following rule is applied: > Three bit combinations 0/10, 0/13 and 2/0 can appear only > when a single byte coded character set is designated to G0. > That is, these bit combinations must not appear when a multi > byte coded character set is designated to G0. (This rule > forces that each line starts and terminates in a "single > byte designation state" and that the space is handled as if > it is a member of 94 character single byte graphics sets.) 4515,4516d4149 < F.3 Registration of New Access-type Values for < Message/external-body 4518,4520d4150 < To: IANA@isi.edu < Subject: Registration of new MIME Access-type for < Message/external-body content-type 4522d4151 < MIME access-type name: 4524d4152 < Required parameters: 4526d4153 < Optional parameters: 4528d4154 < Published specification: 4530d4155 < (The published specification must be an Internet RFC.) 4532,4533d4156 < Person & email address to contact for further < information: 4535d4157 < F.4 Registration of New Conversions Values for Application 4537,4539d4158 < To: IANA@isi.edu < Subject: Registration of new MIME Conversions value < for Application content-type 4541d4159 < MIME Conversions name: 4543,4550d4160 < Published specification: < < < < < < < 4554c4164 < INTERNET MIME: Multipurpose Internet Mail Extensions 71 --- > INTERNET DRAFT Internet Message Body Format 65 4557,4621d4166 < (The published specification must be an Internet RFC.) < < Person & email address to contact for further < information: < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < INTERNET MIME: Multipurpose Internet Mail Extensions 72 < < 4670,4671c4215,4216 < Subtypes defined by this document: octet-stream, < postscript, oda --- > Subtypes defined by this document: Octet-stream, > PostScript, ODA 4684c4229 < INTERNET MIME: Multipurpose Internet Mail Extensions 73 --- > INTERNET DRAFT Internet Message Body Format 66 4707c4252,4253 < Subtypes defined by this document: g3fax, jpeg, gif --- > Subtypes defined by this document: tiff-b-netfax, g3fax, > jpeg, gif, pbm, pgm, ppm 4745d4290 < 4749c4294 < INTERNET MIME: Multipurpose Internet Mail Extensions 74 --- > INTERNET DRAFT Internet Message Body Format 67 4760,4761c4305,4307 < [GIF] Graphics Interchange Format (Version 89a), < Compuserve, Inc., Columbus, Ohio, 1990. --- > [ISO-10646] Working document for ISO/IEC Draft > International Standard 10646-1. ISO/IEC / JTC1 / SC2 / WG2, > document N 745. 27 September 1991. 4781a4328,4331 > [ISODE] Rose, Marshall T., Julian P. Onions, and Colin J. > Robbins, "The ISO Development Environment: User's Manual", > Version 7.0, X-Tel Services Ltd., July, 1991. > 4783c4333 < IEC/TJC1/SC2/WG11 (Motion Picture Experts Group), May, 1991. --- > IEC/TJC1/SC2/WG11 (motion Picture Experts Group), May, 1991. 4794a4345,4347 > [UNICODE] The Unicode Standard. Worldwide Character > Encoding. Version 1.0. The Unicode Consortium, 1991. > 4798d4350 < Holland, 1989, pp. 3-41. 4800,4801d4351 < [RFC-783] Sollins, K.R. TFTP Protocol (revision 2). June, < 1981, Network Information Center, RFC-783. 4803,4804d4352 < [RFC-821] Postel, J.B. Simple Mail Transfer Protocol. < August, 1982, Network Information Center, RFC-821. 4808,4810d4355 < < < 4814c4359 < INTERNET MIME: Multipurpose Internet Mail Extensions 75 --- > INTERNET DRAFT Internet Message Body Format 68 4817,4819c4362 < [RFC-822] Crocker, D. Standard for the format of ARPA < Internet text messages. August, 1982, Network Information < Center, RFC-822. --- > Holland, 1989, pp. 3-41. 4821,4828d4363 < [RFC-934] Rose, M.T.; Stefferud, E.A. Proposed standard < for message encapsulation. January, 1985, Network < Information Center, RFC-934. < < [RFC-959] Postel, J.B.; Reynolds, J.K. File Transfer < Protocol. October, 1985, Network Information Center, RFC- < 959. < 4839c4374 < for Internet messages. April, 1990, Network Information --- > for internet messages. April, 1990, Network Information 4842,4844c4377,4378 < [RFC-HDRS] Moore, Keith, "Representation of Non-Ascii Text < in Internet Message Headers", Internet Draft, draft-ietf- < 822ext-msghead-01.txt. --- > [RFC-821] Postel, J.B. Simple Mail Transfer Protocol. > August, 1982, Network Information Center, RFC-821. 4845a4380,4382 > [RFC-822] Crocker, D. Standard for the format of ARPA > Internet text messages. August, 1982, Network Information > Center, RFC-822. 4846a4384,4386 > [RFC-934] Rose, M.T.; Stefferud, E.A. Proposed standard > for message encapsulation. January, 1985, Network > Information Center, RFC-934. 4847a4388,4390 > [RFC-HDRS] Moore,Keith, "Representation of Non-Ascii Text in > Internet Message Headers", Internet Draft, draft-ietf- > 822ext-msghead-01.txt. 4848a4392,4394 > [RFC-CHAR] Simonsen, Keld, "Character Mnemonics and > Character Sets", Internet Draft draft-ietf-822ext-charsets- > 01.txt. 4849a4396,4398 > [RFC-NETFAX] Katz, A., Cohen, D., "File Format for the > Transmission of Images in the Internet", Internet Draft, > draft-ietf-netfax-netimage-00.txt. 4872,4875d4420 < < < < 4879c4424 < INTERNET MIME: Multipurpose Internet Mail Extensions 76 --- > INTERNET DRAFT Internet Message Body Format 69 4889,4890c4434,4435 < 3 The MIME-Version Header Field...................... 7 < 4 The Content-Type Header Field...................... 8 --- > 3 The MIME-Version Header Field...................... 6 > 4 The Content-Type Header Field...................... 7 4893,4934c4438,4479 < 5.2 Base64 Content-Transfer-Encoding................... 19 < 6 Additional Optional Content- Header Fields......... 21 < 6.1 Optional Content-ID Header Field................... 21 < 6.2 Optional Content-Description Header Field.......... 21 < 7 The Predefined Content-Type Values................. 22 < 7.1 The Text Content-Type.............................. 22 < 7.1.1 The charset parameter.............................. 22 < 7.1.2 The Text/plain subtype............................. 25 < 7.1.3 The Text/richtext subtype.......................... 25 < 7.2 The Multipart Content-Type......................... 31 < 7.2.1 Multipart: The common syntax...................... 32 < 7.2.2 The Multipart/mixed (primary) subtype.............. 36 < 7.2.3 The Multipart/alternative subtype.................. 36 < 7.2.4 The Multipart/digest subtype....................... 38 < 7.2.5 The Multipart/parallel subtype..................... 38 < 7.3 The Message Content-Type........................... 39 < 7.3.1 The Message/rfc822 (primary) subtype............... 39 < 7.3.2 The Message/Partial subtype........................ 39 < 7.3.3 The Message/External-Body subtype.................. 42 < 7.4 The Application Content-Type....................... 48 < 7.4.1 The Application/Octet-Stream (primary) subtype..... 48 < 7.4.2 The Application/PostScript subtype................. 49 < 7.4.3 The Application/ODA subtype........................ 52 < 7.5 The Image Content-Type............................. 53 < 7.6 The Audio Content-Type............................. 53 < 7.7 The Video Content-Type............................. 53 < 7.8 Experimental Content-Type Values................... 54 < Summary............................................ 55 < Contacts........................................... 55 < Acknowledgements................................... 56 < Appendix A -- Minimal MIME-Conformance............. 58 < Appendix B -- General Guidelines For Sending Email Data61 < Appendix C -- A Complex Multipart Example.......... 63 < Appendix D -- A Simple Richtext-to-Text Translator in C65 < Appendix E -- Collected Grammar.................... 67 < Appendix F -- IANA Registration Procedures......... 69 < F.1 Registration of New Content-type/subtype Values..69 < F.2 Registration of New Character Set Values...... 70 < F.3 Registration of New Access-type Values for Message/external-body70 < F.4 Registration of New Conversions Values for Application70 < Appendix G -- Summary of the Seven Content-types... 72 < References......................................... 74 --- > 5.2 Base64 Content-Transfer-Encoding................... 18 > 6 Additional Optional Content- Header Fields......... 20 > 6.1 Optional Content-ID Header Field................... 20 > 6.2 Optional Content-Description Header Field.......... 20 > 7 The Predefined Content-Type Values................. 21 > 7.1 The Text Content-Type.............................. 21 > 7.1.1 The charset parameter.............................. 21 > 7.1.2 The Text/richtext subtype.......................... 24 > 7.2 The Multipart Content-Type......................... 30 > 7.2.1 Multipart: The common syntax...................... 31 > 7.2.2 The Multipart/mixed (primary) subtype.............. 35 > 7.2.3 The Multipart/alternative subtype.................. 35 > 7.2.4 The Multipart/digest subtype....................... 36 > 7.2.5 The Multipart/parallel subtype..................... 37 > 7.3 The Message Content-Type........................... 38 > 7.3.1 The Message/rfc822 (primary) subtype............... 38 > 7.3.2 The Message/Partial subtype........................ 38 > 7.3.3 The Message/External-body' subtype................. 41 > 7.4 The Application Content-Type....................... 44 > 7.4.1 The Application/Octet-Stream subtype............... 44 > 7.4.2 The Application/PostScript subtype................. 45 > 7.4.3 The Application/ODA subtype........................ 47 > 7.5 The Image Content-Type............................. 49 > 7.6 The Audio Content-Type............................. 50 > 7.7 The Video Content-Type............................. 50 > 7.8 Experimental Content-Type Values................... 50 > Summary............................................ 51 > Contacts........................................... 51 > Acknowledgements................................... 52 > Appendix A -- Minimal MIME-Conformance............. 53 > Appendix B -- General Guidelines For Sending Email Data56 > Appendix C -- A Complex Multipart Example.......... 58 > Appendix D -- A Richtext-to-Text Translator in C... 60 > Appendix E -- Collected Grammar.................... 62 > Appendix F -- ISO-2022-jp.......................... 64 > Appendix G -- Summary of the Seven Content-types... 65 > References......................................... 67 > > > > >