rfc1563.txt

中、英文RFC文档大全打包下载完全版 .

                 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 1994


Security 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: [phone]
   Fax:  [phone]
   EMail: [e-mail]

Acknowledgements

   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 1994


Appendix 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 1994


Appendix 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]