rfc1896.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,180 行 · 第 1/4 页

Network Working Group                                         P. Resnick
Request for Comments: 1896                                      QUALCOMM
Obsoletes: 1523, 1563                                          A. Walker
Category: Informational                                         InterCon
                                                           February 1996


                  The text/enriched MIME Content-type

Status 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-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
   MIME type. 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. This document is only a minor
   revision to the text/enriched MIME type that was first described in
   [RFC-1523] and [RFC-1563], and is only intended to be used in the
   short term until other MIME types for text formatting in Internet
   mail are developed and deployed.

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. 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 text/enriched 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.





Resnick & Walker             Informational                      [Page 1]

RFC 1896            text/enriched MIME Content-type        February 1996


   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.

   There are other text formatting standards which meet some of these
   criteria. In particular, HTML and SGML have come into widespread use
   on the Internet. However, there are two important reasons that this
   document further promotes the use of text/enriched in Internet mail
   over other such standards:

   1. Most MIME-aware Internet mail applications are already able to
      either properly format text/enriched mail or, at the very least,
      are able to strip out the formatting commands and display the
      readable text. The same is not true for HTML or SGML.

   2. The current RFC on HTML [RFC-1866] and Internet Drafts on SGML
      have many features which are not necessary for Internet mail, and
      are missing a few capabilities that text/enriched already has.

   For these reasons, this document is promoting the use of
   text/enriched until other Internet standards come into more
   widespread use. For those who will want to use HTML, Appendix B of
   this document contains a very simple C program that converts
   text/enriched to HTML 2.0 described in [RFC-1866].

Syntax

   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. A literal
   less-than sign ("<") can be represented by a sequence of two such
   characters, "<<".

   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



Resnick & Walker             Informational                      [Page 2]

RFC 1896            text/enriched MIME Content-type        February 1996


   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.

Line break rules

   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 section.

   should be displayed by a text/enriched interpreter as follows:

     This is a single line
     This is the next line.

     This is the next section.

   The formatting commands, not all of which will be implemented by all
   implementations, are described in the following sections.





Resnick & Walker             Informational                      [Page 3]

RFC 1896            text/enriched MIME Content-type        February 1996


Formatting 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.

Parameter Command

   Some of the formatting commands may require one or more associated
   parameters. The "param" command is a special formatting command used
   to include these parameters.

     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 "param" command
          always immediately follows some other formatting command,
          and the parameter data indicates some additional
          information about the formatting that is to be done. The
          syntax of the parameter data (whatever appears between
          the initial "<param>" and the terminating "</param>") is
          defined for each command that uses it. However, it is
          always required that 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
          occurrence 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.

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.



Resnick & Walker             Informational                      [Page 4]

RFC 1896            text/enriched MIME Content-type        February 1996


     Underline
          causes the affected text to be underlined. Nested
          underline commands have the same effect as a single
          underline 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.

     FontFamily
          causes the affected text to be displayed in a specified
          typeface. The "fontfamily" command requires a parameter
          that is specified by using the "param" command. The
          parameter data is a case-insensitive string containing
          the name of a font family. Any currently available font
          family name (e.g. Times, Palatino, Courier, etc.) may be
          used. This includes font families defined by commercial
          type foundries such as Adobe, BitStream, or any other
          such foundry. Note that implementations should only use
          the general font family name, not the specific font name
          (e.g. use "Times", not "TimesRoman" nor
          "TimesBoldItalic"). When nested, the inner "fontfamily"
          command takes precedence. Also note that the "fontfamily"
          command is advisory only; it should not be expected that
          other implementations will honor the typeface information
          in this command since the font capabilities of systems
          vary drastically.

     Color
          causes the affected text to be displayed in a specified
          color. The "color" command requires a parameter that is
          specified by using the "param" command. The parameter
          data can be one of the following:

               red
               blue
               green
               yellow
               cyan
               magenta
               black
               white

          or an RGB color value in the form:

               ####,####,####




Resnick & Walker             Informational                      [Page 5]

RFC 1896            text/enriched MIME Content-type        February 1996


          where '#' is a hexadecimal digit '0' through '9', 'A'
          through 'F', or 'a' through 'f'. The three 4-digit
          hexadecimal values are the RGB values for red, green, and
          blue respectively, where each component is expressed as
          an unsigned value between 0 (0000) and 65535 (FFFF). The
          default color for the message is unspecified, though
          black is a common choice in many environments. When
          nested, the inner "color" command takes precedence.