RFC 1896:The text/enriched MIME Content-type
RFC-Ref

MIME


Click on the red underlined text to get to the source

... The text/enriched MIME type ...
... In order to promote the wider interoperability of simple formatted text, this document defines an extremely simple subtype of the MIME content-type "text", the "text/enriched" subtype. The content-type line for this type may have one optional parameter ...
... charset" parameter, with the same values permitted for the "text/plain" MIME content-type. The text/enriched subtype was designed to meet the following ...
... then the raw form of the data must be readable enough to be largely unobjectionable in the event that it is displayed on the screen of the user of a non-MIME-conformant mail reader. 4. The capabilities must be extremely limited, to ensure that it can ...
... over other such standards: 1. Most MIME-aware Internet mail applications are already able to either properly format text/enriched mail or, at the very least, ...


... One of the great benefits of MIME is the ability to use different varieties of non-ASCII text in messages. To use non-ASCII ...
... type line that indicates the character set being used. For purposes of this RFC, any legal MIME charset parameter can be used with the text/enriched Content-type ...


... Normally, if a user wishes to produce text which contains characters from entirely different character sets within the same MIME message (for example, using Russian Cyrillic characters from ISO 8859-5 and ...
... ISO 8859-8), a multipart message is used. Every time a new character set is desired, a new MIME body part is started with different character sets specified in the charset parameter ...
... formatting commands used in the first part would not be able to apply to text that occurs in subsequent parts. It is not possible for text/enriched formatting commands to apply across MIME body part boundaries. ...
... formatting commands like "iso-8859-5" and "us-ascii". But this, or even a more general solution along the same lines, is still undesirable: It is common for a MIME application to decide, for example, what character font resources or character lookup tables it ...
... characters that can be represented in all of the other registered ISO 8859 MIME character sets, but UTF-7 is fully compatible with ...
... the "<" character referred to below. Any other character sets that are specified for use in MIME which contain different types of non-ASCII text can also be used in these instances. ...


... --foo-- If such a message is read using a MIME-conformant mail reader that understands ODA, the ODA version will be displayed; otherwise, the ...


... Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341(-> 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft)) ...
... Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft) ...
... Borenstein, N., "The text/enriched MIME Content-type", RFC 1523(-> 1896 | 1563(-> 1896)), 09/23/1993. ...
... Borenstein, N., "The text/enriched MIME Content-type", RFC 1563(-> 1896), 01/10/1994. ...



Google
Web
RFC-Ref