implementations.   A line break is NOT forced by a change of the margin, to permit the   description of "hanging" text.  Thus for example the following text:   Now <indent> is the time for all good horses to come to the aid of   their stable, assuming that </indent> any stable is really stable.   would be displayed in a 40-character-wide window as follows:               Now is the time for all good horses to                   come to the aid of their stable,                   assuming that any stable is               really stable.Miscellaneous Commands         Excerpt -- causes the affected text to be interpreted as a              textual excerpt from another source, probably a message              being responded to.  Typically this will be displayed              using indentation and an alternate font, or by indenting              lines and preceding them with "> ", but such decisions are              up to the implementation.  (Note that this is the only              truly declarative markup construct in text/enriched, and              as such doesn't fit very well with the other facilities,              but it describes a type of markup that is very commonly              used in email and has no procedural analogue.)  Note that              as with the justification commands, the excerpt command              implicitly begins and ends with a line break if one is not              already there.Borenstein                                                      [Page 6]RFC 1563             A text/enriched type for MIME          January 1994         Param -- Marks the affected text as command parameters, to be              interpreted or ignored by the text/enriched interpreter,              but NOT to be shown to the reader.  The syntax of the              parameter data (whatever appears between the initial              "<param>" and the terminating "</param>") is left              undefined by this memo, to be defined by text/enriched              extensions in the future.  However, the format of such              data must NOT contain nested <param> commands, and either              must NOT use the "<" character or must use it in a way              that is compatible with text/enriched parsing.  That is,              the end of the parameter data should be recognizable with              EITHER of two algorithms: simply searching for the first              occurence of "</param>" or parsing until a balanced              "</param>" command is found.  In either case, however, the              parameter data should NOT be shown to the human reader.Balancing and Nesting of Formatting Commands   Pairs of formatting commands must be properly balanced and nested.   Thus, a proper way to describe text in bold italics is:                      <bold><italic>the-text</italic></bold>                 or, alternately,                      <italic><bold>the-text</bold></italic>                 but, in particular, the following is illegal                 text/enriched:                      <bold><italic>the-text</bold></italic>   The nesting requirement for formatting commands imposes a slightly   higher burden upon the composers of text/enriched bodies, but   potentially simplifies text/enriched displayers by allowing them to   be stack-based.  The main goal of text/enriched is to be simple   enough to make multifont, formatted email widely readable, so that   those with the capability of sending it will be able to do so with   confidence.  Thus slightly increased complexity in the composing   software was deemed a reasonable tradeoff for simplified reading   software.  Nonetheless, implementors of text/enriched readers are   encouraged to follow the general Internet guidelines of being   conservative in what you send and liberal in what you accept.  Those   implementations that can do so are encouraged to deal reasonably with   improperly nested text/enriched data.Borenstein                                                      [Page 7]RFC 1563             A text/enriched type for MIME          January 1994Unrecognized formatting commands   Implementations must regard any unrecognized formatting command as   "no-op" commands, that is, as commands having no effect, thus   facilitating future extensions to "text/enriched".  Private   extensions may be defined using formatting commands that begin with   "X-", by analogy to Internet mail header field names.   In order to formally define extended commands, a new Internet   document should be published.White Space in Text/enriched Data   No special behavior is required for the SPACE or TAB (HT) character.   It is recommended, however, that, at least when fixed-width fonts are   in use, the common semantics of the TAB (HT) character should be   observed, namely that it moves to the next column position that is a   multiple of 8.  (In other words, if a TAB (HT) occurs in column n,   where the leftmost column is column 0, then that TAB (HT) should be   replaced by 8-(n mod 8) SPACE characters.)  It should also be noted   that some mail gateways are notorious for losing (or, less commonly,   adding) white space at the end of lines, so reliance on SPACE or TAB   characters at the end of a line is not recommended.Initial State of a text/enriched interpreter   Text/enriched is assumed to begin with filled text in a variable-   width font in a normal typeface and a size that is average for the   current display and user.  The left and right margins are assumed to   be maximal, that is, at the leftmost and rightmost acceptable   positions.Non-ASCII character sets   If the character set specified by the charset parameter on the   Content-type line is anything other than "US-ASCII", this means that   the text being described by text/enriched formatting commands is in a   non-ASCII character set.  However, the commands themselves are still   the same ASCII commands that are defined in this document.  This   creates an ambiguity only with reference to the "<" character, the   octet with numeric value 60.  In single byte character sets, such as   the ISO-8859 family, this is not a problem; the octet 60 can be   quoted by including it twice, just as for ASCII.  The problem is more   complicated, however, in the case of multi-byte character sets, where   the octet 60 might appear at any point in the byte sequence for any   of several characters.Borenstein                                                      [Page 8]RFC 1563             A text/enriched type for MIME          January 1994   In practice, however, most multibyte character sets address this   problem internally.  For example, the ISO-2022 family of character   sets can switch back into ASCII at any moment.  Therefore it is   specified that, before text/enriched formatting commands, the   prevailing character set should be "switched back" into ASCII, and   that only those characters which would be interpreted as "<" in plain   text should be interpreted as token delimiters in text/enriched.   The question of what to do for hypothetical future character sets   that do NOT subsume ASCII is not addressed in this memo.Minimal text/enriched conformance   A minimal text/enriched implementation is one that converts "<<" to   "<", removes everything between a <param> command and the next   balancing </param> command, removes all other formatting commands   (all text enclosed in angle brackets), and, outside of <nofill>   environments, converts any series of n CRLFs to n-1 CRLFs, and   converts any lone CRLF pairs to SPACE.Notes for Implementors   It is recognized that implementors of future mail systems will want   rich text functionality far beyond that currently defined for   text/enriched.  The intent of text/enriched is to provide a common   format for expressing that functionality in a form in which much of   it, at least, will be understood by interoperating software.  Thus,   in particular, software with a richer notion of formatted text than   text/enriched can still use text/enriched as its basic   representation, but can extend it with new formatting commands and by   hiding information specific to that software system in text/enriched   <param> constructs.  As such systems evolve, it is expected that the   definition of text/enriched will be further refined by future   published specifications, but text/enriched as defined here provides   a platform on which evolutionary refinements can be based.   An expected common way that sophisticated mail programs will generate   text/enriched data is as part of a multipart/alternative construct.   For example, a mail agent that can generate enriched mail in ODA   format can generate that mail in a more widely interoperable form by   generating both text/enriched and ODA versions of the same data,   e.g.:Borenstein                                                      [Page 9]RFC 1563             A text/enriched type for MIME          January 1994                 Content-type: multipart/alternative; boundary=foo                 --foo                 Content-type: text/enriched                 [text/enriched version of data]                 --foo                 Content-type: application/oda                 [ODA version of data]                 --foo--   If such a message is read using a MIME-conformant mail reader that   understands ODA, the ODA version will be displayed; otherwise, the   text/enriched version will be shown.   In some environments, it might be impossible to combine certain   text/enriched formatting commands, whereas in others they might be   combined easily.  For example, the combination of <bold> and <italic>   might produce bold italics on systems that support such fonts, but   there exist systems that can make text bold or italicized, but not   both.  In such cases, the most recently issued (innermost) recognized   formatting command should be preferred.   One of the major goals in the design of text/enriched was to make it   so simple that even text-only mailers will implement enriched-to-   plain-text translators, thus increasing the likelihood that enriched   text will become "safe" to use very widely.  To demonstrate this   simplicity, an extremely simple C program that converts text/enriched   input into plain text output is included in Appendix A.Extensions to text/enriched   It is expected that various mail system authors will desire   extensions to text/enriched.  The simple syntax of text/enriched, and   the specification that unrecognized formatting commands should simply   be ignored, are intend to promote such extensions.   Beyond simply defining new formatting commands, however, it may   sometimes be necessary to define formatting commands that can take   arguments.  This is the intended use of the <param> construct.  In   particular, software that wished to extend text/enriched to include   colored text might define an "x-color" environment which always began   with a color name parameter, to indicate the desired color for the   affected text.Borenstein                                                     [Page 10]RFC 1563             A text/enriched type for MIME          January 1994An Example   Putting all this together, the following "text/enriched" body   fragment:                      From: Nathaniel Borenstein <nsb@bellcore.com>                      To: Ned Freed <ned@innosoft.com>                      Content-type: text/enriched                      <bold>Now</bold> is the time for                      <italic>all</italic> good men                       <smaller>(and <<women>)</smaller> to                      <ignoreme>come</ignoreme>                      to the aid of their                      <x-color><param>red</param>beloved</x-color>                      country.                      By the way, I think that <<smaller>                      should                      REALLY be called                      <<tinier>                      and that I am always right.                      -- the end   represents the following formatted text (which will, no doubt, look   somewhat cryptic in the text-only version of this document):