Network Working Group                                      N. BorensteinRequest for Comments: 1563                                      BellcoreObsoletes: 1523                                             January 1994Category: Informational                  The text/enriched MIME Content-typeStatus of this Memo   This memo provides information for the Internet community.  This memo   does not specify an Internet standard of any kind.  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.Table of Contents   The Text/enriched MIME type..............................  2   Formatting Commands......................................  4         Font-Alteration Commands...........................  4         Fill/Justification Commands........................  5         Indentation Commands...............................  6         Miscellaneous Commands.............................  6         Balancing and Nesting of Formatting Commands.......  7         Unrecognized formatting commands...................  8   White Space in Text/enriched Data........................  8   Initial State of a text/enriched interpreter.............  8   Non-ASCII character sets.................................  8   Minimal text/enriched conformance........................  9   Notes for Implementors...................................  9   Extensions to text/enriched.............................. 10   An Example............................................... 11   Security Considerations.................................. 12   Author's Address......................................... 12   Acknowledgements......................................... 12   References............................................... 12   Appendix A -- A Simple enriched-to-plain Translator in C. 13   Appendix B -- Differences from RFC 1341 text/richtext.... 15Borenstein                                                      [Page 1]RFC 1563             A text/enriched type for MIME          January 1994The 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 "<" 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 openingBorenstein                                                      [Page 2]RFC 1563             A text/enriched type for MIME          January 1994   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.   Thus text/enriched data that looks like this:                 This is                 a single                 line                 This is the                 next line.                 This is the                 next paragraph.   should be displayed by a text/enriched interpreter as follows:                 This is a single line                 This is the next line.                 This is the next paragraph.   The formatting commands, not all of which will be implemented by all   implementations, are described in the following sections.Borenstein                                                      [Page 3]RFC 1563             A text/enriched type for MIME          January 1994Formatting Commands   The text/enriched formatting commands all begin with <commandname>   and end with </commandname>, affecting the formatting of the text   between those two tokens.  The commands are described here, grouped   according to type.Font-Alteration Commands   The following formatting commands are intended to alter the font in   which text is displayed, but not to alter the indentation or   justification state of the text:         Bold -- causes the affected text to be in a bold font.  Nested              bold commands have the same effect as a single bold              command.         Italic -- causes the affected text to be in an italic font.              Nested italic commands have the same effect as a single              italic command.         Fixed -- causes the affected text to be in a fixed width font.              Nested fixed commands have the same effect as a single              fixed command.         Smaller -- causes the affected text to be in a smaller font.              It is recommended that the font size be changed by two              points, but other amounts may be more appropriate in some              environments.  Nested smaller commands produce ever-              smaller fonts, to the limits of the implementation's              capacity to reasonably display them, after which further              smaller commands have no incremental effect.         Bigger -- causes the affected text to be in a bigger font.  It              is recommended that the font size be changed by two              points, but other amounts may be more appropriate in some              environments.  Nested bigger commands produce ever-bigger              fonts, to the limits of the implementation's capacity to              reasonably display them, after which further bigger              commands have no incremental effect.         Underline -- causes the affected text to be underlined.  Nested              underline commands have the same effect as a single              underline command.   While the "bigger" and "smaller" operators are effectively inverses,   it is not recommended, for example, that "<smaller>" be used to end   the effect of "<bigger>".  This is properly done with "</bigger>".Borenstein                                                      [Page 4]RFC 1563             A text/enriched type for MIME          January 1994Fill/Justification Commands   Initially, text/enriched text is intended to be displayed fully   filled with appropriate kerning and letter-tracking as suits the   capabilities of the receiving user agent software.  Actual line width   is left to the discretion of the receiver, which is expected to fold   lines intelligently (preferring soft line breaks) to the best of its   ability.   The following commands alter that state.  Each of these commands   force a line break before and after the formatting environment if   there is not otherwise a line break.  For example, if one of these   commands occurs anywhere other than the beginning of a line of text   as presented, a new line is begun.      Center -- causes the affected text to be centered.      FlushLeft -- causes the affected text to be left-justified with a           ragged right margin.      FlushRight -- causes the affected text to be right-justified with a           ragged left margin.      FlushBoth -- causes the affected text to be filled and padded so           as to create smooth left and right margins, i.e., to be           fully justified.      Nofill -- causes the affected text to be displayed without filling           or justification.   The center, flushleft, flushright, and flushboth commands are   mutually exclusive, and, when nested, the inner command takes   precedence.   Whether or not text is justified by default (that is, whether the   default environment is flushleft, flushright, or flushboth) is   unspecified, and depends on the preferences of the user, the   capabilities of the local software and hardware, and the nature of   the character set in use.  On systems where justification is   considered undesirable, the flushboth environment may be identical to   the default environment.  Note that justification should never be   performed inside of center, flushleft, flushright, or nofill   environments.  Note also that for some non-ASCII character sets, full   justification may be fundamentally inappropriate.Borenstein                                                      [Page 5]RFC 1563             A text/enriched type for MIME          January 1994Indentation Commands   Initially, text/enriched text is displayed using the maximum   available margins.  Two formatting commands may be used to affect the   margins.         Indent -- causes the running left margin to be moved to the              right.  The recommended indentation change is the width of              four characters, but this may differ among              implementations.         IndentRight -- causes the running right margin to be moved to              the left.  The recommended indentation change is the width              of four characters, but this may differ among