rfc1523.txt

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

Network Working Group                                      N. Borenstein
Request for Comments: 1523                                      Bellcore
Category: Informational                                   September 1993


                  The text/enriched MIME Content-type

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  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.

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




Borenstein                                                      [Page 1]

RFC 1523           A text/enriched MIME Content-type      September 1993


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

   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.










Borenstein                                                      [Page 2]

RFC 1523           A text/enriched MIME Content-type      September 1993


   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.

   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.

   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.





Borenstein                                                      [Page 3]

RFC 1523           A text/enriched MIME Content-type      September 1993


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

   Justification Commands

   Initially, text/enriched text is intended to be displayed fully-
   justified with appropriate fill, 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 command 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.





Borenstein                                                      [Page 4]

RFC 1523           A text/enriched MIME Content-type      September 1993


   The center, flushleft, and flushright commands are mutually
   exclusive, and, when nested, the inner command takes precedence.

   Note that for some non-ASCII character sets, full justification may
   be inappropriate. In these cases, a user agent may choose not to
   justify such data.

   Indentation 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
              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