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
>
>
>
>
>