Now is the time for all good men (and <women>)  to                 come                 to the aid of their                 beloved country.                 By the way, I think that <smaller>                 should                 REALLY be called                 <tinier>                 and that I am always right.                 -- the end   where the word "beloved" would be in red on a color display if the   receiving software implemented the "x-color" extension.Borenstein                                                     [Page 11]RFC 1563             A text/enriched type for MIME          January 1994Security Considerations   Security issues are not discussed in this memo, as the mechanism   raises no security issues.Author's Address   For more information, the author of this document may be contacted   via Internet mail:   Nathaniel S. Borenstein   MRE 2D-296, Bellcore   445 South St.   Morristown, NJ 07962-1910   Phone: +1 201 829 4270   Fax:  +1 201 829 5963   EMail: nsb@bellcore.comAcknowledgements   This document reflects the input of many contributors, readers, and   implementors of the original MIME specification, RFC 1341.  It also   reflects particular contributions and comments from Terry Crowley,   Rhys Weatherley, and John LoVerso.References   [RFC-1341] Borenstein, N., and N.  Freed, "MIME (Multipurpose              Internet Mail Extensions): Mechanisms for Specifying              and Describing the Format of Internet Message Bodies",              RFC 1341, Bellcore, Innosoft, June 1992.   [RFC-1521] 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, Bellcore, Innosoft,              September 1993.Borenstein                                                     [Page 12]RFC 1563             A text/enriched type for MIME          January 1994Appendix A -- A Simple enriched-to-plain Translator in C   One of the major goals in the design of the text/enriched subtype of   the text Content-Type is to make formatted text so simple that even   text-only mailers will implement enriched-to-plain-text translators,   thus increasing the likelihood that multifont text will become "safe"   to use very widely.  To demonstrate this simplicity, what follows is   a simple C program that converts text/enriched input into plain text   output.  Note that the local newline convention (the single character   represented by "\n") is assumed by this program, but that special   CRLF handling might be necessary on some systems.#include <stdio.h>#include <ctype.h>main() {    int c, i, paramct=0, newlinect=0, nofill=0;    char token[62], *p;    while ((c=getc(stdin)) != EOF) {        if (c == '<') {            if (newlinect == 1) putc(' ', stdout);            newlinect = 0;            c = getc(stdin);            if (c == '<') {                if (paramct <= 0) putc(c, stdout);            } else {                  ungetc(c, stdin);                  for (i=0, p=token; (c=getc(stdin)) != EOF && c != '>';                  i++)                  { if (i < sizeof(token)-1)                    *p++ = isupper(c) ? tolower(c) : c;                  }                  *p = '\0';                  if (c == EOF) break;                  if (strcmp(token, "param") == 0)                      paramct++;                  else if (strcmp(token, "nofill") == 0)                      nofill++;                  else if (strcmp(token, "/param") == 0)                      paramct--;                  else if (strcmp(token, "/nofill") == 0)                      nofill--;              }        } else {            if (paramct > 0)                ; /* ignore params */            else if (c == '\n' && nofill <= 0) {Borenstein                                                     [Page 13]RFC 1563             A text/enriched type for MIME          January 1994                if (++newlinect > 1) putc(c, stdout);            } else {                if (newlinect == 1) putc(' ', stdout);                newlinect = 0;                putc(c, stdout);            }        }     }     /* The following line is only needed with line-buffering */     putc('\n', stdout);     exit(0);}   It should be noted that one can do considerably better than this in   displaying text/enriched data on a dumb terminal.  In particular, one   can replace font information such as "bold" with textual emphasis   (like *this* or _T_H_I_S_).  One can also properly handle the   text/enriched formatting commands regarding indentation,   justification, and others.  However, the above program is all that is   necessary in order to present text/enriched on a dumb terminal   without showing the user any formatting artifacts.Borenstein                                                     [Page 14]RFC 1563             A text/enriched type for MIME          January 1994Appendix B -- Differences from RFC 1341 text/richtext   Text/enriched is a clarification, simplification, and refinement of   the type defined as text/richtext in RFC 1341.  For the benefit of   those who are already familiar with text/richtext, or for those who   want to exploit the similarities to be able to display text/richtext   data with their text/enriched software, the differences between the   two are summarized here. Note, however, that text/enriched is   intended to make text/richtext obsolete, so it is not recommended   that new software generate text/richtext.   0.  The name "richtext" was changed to "enriched", both to       differentiate the two versions and because "richtext"       created widespread confusion with Microsoft's Rich Text       Format (RTF).   1.  Clarifications.  Many things were ambiguous or       unspecified in the text/richtext definition, particularly       the initial state and the semantics of richtext with       multibyte character sets.  However, such differences are       OPERATIONALLY irrelevant, since the clarifications offered       in this document are at least reasonable interpretations of       the text/richtext specification.   2.  Newline semantics have changed.  In text/richtext, all       CRLFs were mapped to spaces, and line breaks were indicated       by "<nl>".  This has been replaced by the "n-1" rule for       CRLFs.   3.  The representation of a literal "<" character was "<lt>"       in text/richtext, but is "<<" in text/enriched.   4.  The "nofill" command did not exist in text/richtext.   5.  The "param" command did not exist in text/richtext.   6.  The following commands from text/richtext have been       REMOVED from text/enriched: <COMMENT>, <OUTDENT>,       <OUTDENTRIGHT>, <SAMEPAGE>, <SUBSCRIPT>, <SUPERSCRIPT>,       <HEADING>, <FOOTING>, <ISO-8859-[1-9]>, <US-ASCII>,       <PARAGRAPH>, <SIGNATURE>, <NO-OP>, <LT>, <NL>, and <NP>.   7.  All claims of SGML compatibility have been dropped.       However, with the possible exceptions of the new semantics       for CRLF and "<<" can be implemented, text/enriched should       be no less SGML-friendly than text/richtext was.Borenstein                                                     [Page 15]RFC 1563             A text/enriched type for MIME          January 1994   8.  In text/richtext, there were three commands (<NL>, <NP>,       and <LT>) that did not use balanced closing delimiters.       Since all of these have been eliminated, there are NO       exceptions to the nesting/balancing rules in text/enriched.   9.  The limit on the size of formatting tokens has been       increased from 40 to 60 characters.Borenstein                                                     [Page 16]