RFC 1563 (rfc1563) - Page 2 of 16
The text/enriched MIME Content-type
Alternative Format: Original Text Document
RFC 1563 A text/enriched type for MIME January 1994
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. This subtype was
designed to meet the following criteria:
1. The syntax must be extremely simple to parse,
so that even teletype-oriented mail systems can
easily strip away the formatting information and
leave only the readable text.
2. The syntax must be extensible to allow for new
formatting commands that are deemed essential for
some application.
3. If the character set in use is ASCII or an 8-
bit ASCII superset, 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 represent no more than is
likely to be representable by the user's primary
word processor. While this limits what can be
sent, it increases the likelihood that what is
sent can be properly displayed.
This document defines a new MIME content-type, "text/enriched". The
content-type line for this type may have one optional parameter, the
"charset" parameter, with the same values permitted for the
"text/plain" MIME content-type.
The syntax of "text/enriched" is very simple. It represents text in
a single character set -- US-ASCII by default, although a different
character set can be specified by the use of the "charset" parameter.
(The semantics of text/enriched in non-ASCII character sets are
discussed later in this document.) All characters represent
themselves, with the exception of the "", ASCII 60 and 62). Each formatting command may be no
more than 60 characters in length, all in US-ASCII, restricted to the
alphanumeric and hyphen ("-") characters. Formatting commands may be
preceded by a solidus ("/", ASCII 47), making them negations, and
such negations must always exist to balance the initial opening
Borenstein