The text/enriched MIME Content-type
RFC 1523
|
Document |
Type |
|
RFC - Informational
(September 1993; No errata)
|
|
Author |
|
Nathaniel Borenstein
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 1523 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group N. Borenstein
Request for Comments: 1523 Bellcore
Category: Informational September 1993
The text/enriched MIME Content-type
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Abstract
MIME [RFC-1341, RFC-1521] defines a format and general framework for
the representation of a wide variety of data types in Internet mail.
This document defines one particular type of MIME data, the
text/enriched type, a refinement of the "text/richtext" type defined
in RFC 1341. The text/enriched MIME type is intended to facilitate
the wider interoperation of simple enriched text across a wide
variety of hardware and software platforms.
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.
Borenstein [Page 1]
RFC 1523 A text/enriched MIME Content-type September 1993
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 "<" character (ASCII 60), which
is 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 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
commands. Thus, if the formatting command "<bold>" appears at some
point, there must later be a "</bold>" to balance it. (NOTE: The 60
character limit on formatting commands does NOT include the "<", ">",
or "/" characters that might be attached to such commands.)
Formatting commands are always case-insensitive. That is, "bold" and
"BoLd" are equivalent in effect, if not in good taste.
Beyond tokens delimited by "<" and ">", there are two other special
processing rules. First, a literal less-than sign ("<") can be
represented by a sequence of two such characters, "<<". Second, line
breaks (CRLF pairs in standard network representation) are handled
specially. In particular, isolated CRLF pairs are translated into a
single SPACE character. Sequences of N consecutive CRLF pairs,
however, are translated into N-1 actual line breaks. This permits
long lines of data to be represented in a natural- looking manner
despite the frequency of line-wrapping in Internet mailers. When
preparing the data for mail transport, isolated line breaks should be
inserted wherever necessary to keep each line shorter than 80
characters. When preparing such data for presentation to the user,
isolated line breaks should be replaced by a single SPACE character,
and N consecutive CRLF pairs should be presented to the user as N-1
line breaks.
Borenstein [Page 2]
RFC 1523 A text/enriched MIME Content-type September 1993
Show full document text