home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1800s / rfc1896.txt < prev    next >
Text File  |  1996-02-14  |  46KB  |  1,180 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         P. Resnick
  8. Request for Comments: 1896                                      QUALCOMM
  9. Obsoletes: 1523, 1563                                          A. Walker
  10. Category: Informational                                         InterCon
  11.                                                            February 1996
  12.  
  13.  
  14.                   The text/enriched MIME Content-type
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    MIME [RFC-1521] defines a format and general framework for the
  25.    representation of a wide variety of data types in Internet mail. This
  26.    document defines one particular type of MIME data, the text/enriched
  27.    MIME type. The text/enriched MIME type is intended to facilitate the
  28.    wider interoperation of simple enriched text across a wide variety of
  29.    hardware and software platforms. This document is only a minor
  30.    revision to the text/enriched MIME type that was first described in
  31.    [RFC-1523] and [RFC-1563], and is only intended to be used in the
  32.    short term until other MIME types for text formatting in Internet
  33.    mail are developed and deployed.
  34.  
  35. The text/enriched MIME type
  36.  
  37.    In order to promote the wider interoperability of simple formatted
  38.    text, this document defines an extremely simple subtype of the MIME
  39.    content-type "text", the "text/enriched" subtype. The content-type
  40.    line for this type may have one optional parameter, the "charset"
  41.    parameter, with the same values permitted for the "text/plain" MIME
  42.    content-type.
  43.  
  44.    The text/enriched subtype was designed to meet the following
  45.    criteria:
  46.  
  47.    1. The syntax must be extremely simple to parse, so that even
  48.       teletype-oriented mail systems can easily strip away the
  49.       formatting information and leave only the readable text.
  50.  
  51.    2. The syntax must be extensible to allow for new formatting
  52.       commands that are deemed essential for some application.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Resnick & Walker             Informational                      [Page 1]
  59.  
  60. RFC 1896            text/enriched MIME Content-type        February 1996
  61.  
  62.  
  63.    3. If the character set in use is ASCII or an 8-bit ASCII superset,
  64.       then the raw form of the data must be readable enough to be
  65.       largely unobjectionable in the event that it is displayed on the
  66.       screen of the user of a non-MIME-conformant mail reader.
  67.  
  68.    4. The capabilities must be extremely limited, to ensure that it can
  69.       represent no more than is likely to be representable by the
  70.       user's primary word processor. While this limits what can be
  71.       sent, it increases the likelihood that what is sent can be
  72.       properly displayed.
  73.  
  74.    There are other text formatting standards which meet some of these
  75.    criteria. In particular, HTML and SGML have come into widespread use
  76.    on the Internet. However, there are two important reasons that this
  77.    document further promotes the use of text/enriched in Internet mail
  78.    over other such standards:
  79.  
  80.    1. Most MIME-aware Internet mail applications are already able to
  81.       either properly format text/enriched mail or, at the very least,
  82.       are able to strip out the formatting commands and display the
  83.       readable text. The same is not true for HTML or SGML.
  84.  
  85.    2. The current RFC on HTML [RFC-1866] and Internet Drafts on SGML
  86.       have many features which are not necessary for Internet mail, and
  87.       are missing a few capabilities that text/enriched already has.
  88.  
  89.    For these reasons, this document is promoting the use of
  90.    text/enriched until other Internet standards come into more
  91.    widespread use. For those who will want to use HTML, Appendix B of
  92.    this document contains a very simple C program that converts
  93.    text/enriched to HTML 2.0 described in [RFC-1866].
  94.  
  95. Syntax
  96.  
  97.    The syntax of "text/enriched" is very simple. It represents text in a
  98.    single character set--US-ASCII by default, although a different
  99.    character set can be specified by the use of the "charset" parameter.
  100.    (The semantics of text/enriched in non-ASCII character sets are
  101.    discussed later in this document.) All characters represent
  102.    themselves, with the exception of the "<" character (ASCII 60), which
  103.    is used to mark the beginning of a formatting command. A literal
  104.    less-than sign ("<") can be represented by a sequence of two such
  105.    characters, "<<".
  106.  
  107.    Formatting instructions consist of formatting commands surrounded by
  108.    angle brackets ("<>", ASCII 60 and 62). Each formatting command may
  109.    be no more than 60 characters in length, all in US-ASCII, restricted
  110.    to the alphanumeric and hyphen ("-") characters. Formatting commands
  111.  
  112.  
  113.  
  114. Resnick & Walker             Informational                      [Page 2]
  115.  
  116. RFC 1896            text/enriched MIME Content-type        February 1996
  117.  
  118.  
  119.    may be preceded by a solidus ("/", ASCII 47), making them negations,
  120.    and such negations must always exist to balance the initial opening
  121.    commands.  Thus, if the formatting command "<bold>" appears at some
  122.    point, there must later be a "</bold>" to balance it. (NOTE: The 60
  123.    character limit on formatting commands does NOT include the "<", ">",
  124.    or "/" characters that might be attached to such commands.)
  125.    Formatting commands are always case-insensitive. That is, "bold" and
  126.    "BoLd" are equivalent in effect, if not in good taste.
  127.  
  128. Line break rules
  129.  
  130.    Line breaks (CRLF pairs in standard network representation) are
  131.    handled specially. In particular, isolated CRLF pairs are translated
  132.    into a single SPACE character. Sequences of N consecutive CRLF pairs,
  133.    however, are translated into N-1 actual line breaks. This permits
  134.    long lines of data to be represented in a natural looking manner
  135.    despite the frequency of line-wrapping in Internet mailers. When
  136.    preparing the data for mail transport, isolated line breaks should be
  137.    inserted wherever necessary to keep each line shorter than 80
  138.    characters. When preparing such data for presentation to the user,
  139.    isolated line breaks should be replaced by a single SPACE character,
  140.    and N consecutive CRLF pairs should be presented to the user as N-1
  141.    line breaks.
  142.  
  143.    Thus text/enriched data that looks like this:
  144.  
  145.      This is
  146.      a single
  147.      line
  148.  
  149.      This is the
  150.      next line.
  151.  
  152.  
  153.      This is the
  154.      next section.
  155.  
  156.    should be displayed by a text/enriched interpreter as follows:
  157.  
  158.      This is a single line
  159.      This is the next line.
  160.  
  161.      This is the next section.
  162.  
  163.    The formatting commands, not all of which will be implemented by all
  164.    implementations, are described in the following sections.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Resnick & Walker             Informational                      [Page 3]
  171.  
  172. RFC 1896            text/enriched MIME Content-type        February 1996
  173.  
  174.  
  175. Formatting Commands
  176.  
  177.    The text/enriched formatting commands all begin with <commandname>
  178.    and end with </commandname>, affecting the formatting of the text
  179.    between those two tokens. The commands are described here, grouped
  180.    according to type.
  181.  
  182. Parameter Command
  183.  
  184.    Some of the formatting commands may require one or more associated
  185.    parameters. The "param" command is a special formatting command used
  186.    to include these parameters.
  187.  
  188.      Param
  189.           Marks the affected text as command parameters, to be
  190.           interpreted or ignored by the text/enriched interpreter,
  191.           but not to be shown to the reader. The "param" command
  192.           always immediately follows some other formatting command,
  193.           and the parameter data indicates some additional
  194.           information about the formatting that is to be done. The
  195.           syntax of the parameter data (whatever appears between
  196.           the initial "<param>" and the terminating "</param>") is
  197.           defined for each command that uses it. However, it is
  198.           always required that the format of such data must not
  199.           contain nested "param" commands, and either must not use
  200.           the "<" character or must use it in a way that is
  201.           compatible with text/enriched parsing. That is, the end
  202.           of the parameter data should be recognizable with either
  203.           of two algorithms: simply searching for the first
  204.           occurrence of "</param>" or parsing until a balanced
  205.           "</param>" command is found. In either case, however, the
  206.           parameter data should not be shown to the human reader.
  207.  
  208. Font-Alteration Commands
  209.  
  210.    The following formatting commands are intended to alter the font in
  211.    which text is displayed, but not to alter the indentation or
  212.    justification state of the text:
  213.  
  214.      Bold
  215.           causes the affected text to be in a bold font. Nested
  216.           bold commands have the same effect as a single bold
  217.           command.
  218.  
  219.      Italic
  220.           causes the affected text to be in an italic font. Nested
  221.           italic commands have the same effect as a single italic
  222.           command.
  223.  
  224.  
  225.  
  226. Resnick & Walker             Informational                      [Page 4]
  227.  
  228. RFC 1896            text/enriched MIME Content-type        February 1996
  229.  
  230.  
  231.      Underline
  232.           causes the affected text to be underlined. Nested
  233.           underline commands have the same effect as a single
  234.           underline command.
  235.  
  236.      Fixed
  237.           causes the affected text to be in a fixed width font.
  238.           Nested fixed commands have the same effect as a single
  239.           fixed command.
  240.  
  241.      FontFamily
  242.           causes the affected text to be displayed in a specified
  243.           typeface. The "fontfamily" command requires a parameter
  244.           that is specified by using the "param" command. The
  245.           parameter data is a case-insensitive string containing
  246.           the name of a font family. Any currently available font
  247.           family name (e.g. Times, Palatino, Courier, etc.) may be
  248.           used. This includes font families defined by commercial
  249.           type foundries such as Adobe, BitStream, or any other
  250.           such foundry. Note that implementations should only use
  251.           the general font family name, not the specific font name
  252.           (e.g. use "Times", not "TimesRoman" nor
  253.           "TimesBoldItalic"). When nested, the inner "fontfamily"
  254.           command takes precedence. Also note that the "fontfamily"
  255.           command is advisory only; it should not be expected that
  256.           other implementations will honor the typeface information
  257.           in this command since the font capabilities of systems
  258.           vary drastically.
  259.  
  260.      Color
  261.           causes the affected text to be displayed in a specified
  262.           color. The "color" command requires a parameter that is
  263.           specified by using the "param" command. The parameter
  264.           data can be one of the following:
  265.  
  266.                red
  267.                blue
  268.                green
  269.                yellow
  270.                cyan
  271.                magenta
  272.                black
  273.                white
  274.  
  275.           or an RGB color value in the form:
  276.  
  277.                ####,####,####
  278.  
  279.  
  280.  
  281.  
  282. Resnick & Walker             Informational                      [Page 5]
  283.  
  284. RFC 1896            text/enriched MIME Content-type        February 1996
  285.  
  286.  
  287.           where '#' is a hexadecimal digit '0' through '9', 'A'
  288.           through 'F', or 'a' through 'f'. The three 4-digit
  289.           hexadecimal values are the RGB values for red, green, and
  290.           blue respectively, where each component is expressed as
  291.           an unsigned value between 0 (0000) and 65535 (FFFF). The
  292.           default color for the message is unspecified, though
  293.           black is a common choice in many environments. When
  294.           nested, the inner "color" command takes precedence.
  295.  
  296.      Smaller
  297.           causes the affected text to be in a smaller font. It is
  298.           recommended that the font size be changed by two points,
  299.           but other amounts may be more appropriate in some
  300.           environments. Nested smaller commands produce ever
  301.           smaller fonts, to the limits of the implementation's
  302.           capacity to reasonably display them, after which further
  303.           smaller commands have no incremental effect.
  304.  
  305.      Bigger
  306.           causes the affected text to be in a bigger font. It is
  307.           recommended that the font size be changed by two points,
  308.           but other amounts may be more appropriate in some
  309.           environments. Nested bigger commands produce ever bigger
  310.           fonts, to the limits of the implementation's capacity to
  311.           reasonably display them, after which further bigger
  312.           commands have no incremental effect.
  313.  
  314.    While the "bigger" and "smaller" operators are effectively inverses,
  315.    it is not recommended, for example, that "<smaller>" be used to end
  316.    the effect of "<bigger>". This is properly done with "</bigger>".
  317.  
  318.    Since the capabilities of implementations will vary, it is to be
  319.    expected that some implementations will not be able to act on some of
  320.    the font-alteration commands. However, an implementation should still
  321.    display the text to the user in a reasonable fashion. In particular,
  322.    the lack of capability to display a particular font family, color, or
  323.    other text attribute does not mean that an implementation should fail
  324.    to display text.
  325.  
  326. Fill/Justification/Indentation Commands
  327.  
  328.    Initially, text/enriched text is intended to be displayed fully
  329.    filled (that is, using the rules specified for replacing CRLF pairs
  330.    with spaces or removing them as appropriate) with appropriate kerning
  331.    and letter-tracking, and using the maximum available margins as suits
  332.    the capabilities of the receiving user agent software.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Resnick & Walker             Informational                      [Page 6]
  339.  
  340. RFC 1896            text/enriched MIME Content-type        February 1996
  341.  
  342.  
  343.    The following commands alter that state. Each of these commands force
  344.    a line break before and after the formatting environment if there is
  345.    not otherwise a line break. For example, if one of these commands
  346.    occurs anywhere other than the beginning of a line of text as
  347.    presented, a new line is begun.
  348.  
  349.      Center
  350.           causes the affected text to be centered.
  351.  
  352.      FlushLeft
  353.           causes the affected text to be left-justified with a
  354.           ragged right margin.
  355.  
  356.      FlushRight
  357.           causes the affected text to be right-justified with a
  358.           ragged left margin.
  359.  
  360.      FlushBoth
  361.           causes the affected text to be filled and padded so as to
  362.           create smooth left and right margins, i.e., to be fully
  363.           justified.
  364.  
  365.      ParaIndent
  366.           causes the running margins of the affected text to be
  367.           moved in. The recommended indentation change is the width
  368.           of four characters, but this may differ among
  369.           implementations. The "paraindent" command requires a
  370.           parameter that is specified by using the "param" command.
  371.           The parameter data is a comma-seperated list of one or
  372.           more of the following:
  373.  
  374.           Left
  375.                causes the running left margin to be moved to the
  376.                right.
  377.  
  378.           Right
  379.                causes the running right margin to be moved to the
  380.                left.
  381.  
  382.           In
  383.                causes the first line of the affected paragraph to
  384.                be indented in addition to the running margin. The
  385.                remaining lines remain flush to the running margin.
  386.  
  387.           Out
  388.                causes all lines except for the first line of the
  389.                affected paragraph to be indented in addition to the
  390.                running margin. The first line remains flush to the
  391.  
  392.  
  393.  
  394. Resnick & Walker             Informational                      [Page 7]
  395.  
  396. RFC 1896            text/enriched MIME Content-type        February 1996
  397.  
  398.  
  399.                running margin.
  400.  
  401.      Nofill
  402.           causes the affected text to be displayed without filling.
  403.           That is, the text is displayed without using the rules
  404.           for replacing CRLF pairs with spaces or removing
  405.           consecutive sequences of CRLF pairs. However, the current
  406.           state of the margins and justification is honored; any
  407.           indentation or justification commands are still applied
  408.           to the text within the scope of the "nofill".
  409.  
  410.    The "center", "flushleft", "flushright", and "flushboth" commands are
  411.    mutually exclusive, and, when nested, the inner command takes
  412.    precedence.
  413.  
  414.    The "nofill" command is mutually exclusive with the "in" and "out"
  415.    parameters of the "paraindent" command; when they occur in the same
  416.    scope, their behavior is undefined.
  417.  
  418.    The parameter data for the "paraindent" command may contain multiple
  419.    occurances of the same parameter (i.e. "left", "right", "in", or
  420.    "out").  Each occurance causes the text to be further indented in the
  421.    manner indicated by that parameter. Nested "paraindent" commands
  422.    cause the affected text to be further indented according to the
  423.    parameters. Note that the "in" and "out" parameters for "paraindent"
  424.    are mutually exclusive; when they appear together or when nested
  425.    "paraindent" commands contain both of them, their behavior is
  426.    undefined.
  427.  
  428.    For purposes of the "in" and "out" parameters, a paragraph is defined
  429.    as text that is delimited by line breaks after applying the rules for
  430.    replacing CRLF pairs with spaces or removing consecutive sequences of
  431.    CRLF pairs. For example, within the scope of an "out", the line
  432.    following each CRLF is made flush with the running margin, and
  433.    subsequent lines are indented. Within the scope of an "in", the first
  434.    line following each CRLF is indented, and subsequent lines remain
  435.    flush to the running margin.
  436.  
  437.    Whether or not text is justified by default (that is, whether the
  438.    default environment is "flushleft", "flushright", or "flushboth") is
  439.    unspecified, and depends on the preferences of the user, the
  440.    capabilities of the local software and hardware, and the nature of
  441.    the character set in use. On systems where full justification is
  442.    considered undesirable, the "flushboth" environment may be identical
  443.    to the default environment. Note that full justification should never
  444.    be performed inside of "center", "flushleft", "flushright", or
  445.    "nofill" environments.  Note also that for some non-ASCII character
  446.    sets, full justification may be fundamentally inappropriate.
  447.  
  448.  
  449.  
  450. Resnick & Walker             Informational                      [Page 8]
  451.  
  452. RFC 1896            text/enriched MIME Content-type        February 1996
  453.  
  454.  
  455.    Note that [RFC-1563] defined two additional indentation commands,
  456.    "Indent" and "IndentRight". These commands did not force a line
  457.    break, and therefore their behavior was unpredictable since they
  458.    depended on the margins and character sizes that a particular
  459.    implementation used.  Therefore, their use is deprecated and they
  460.    should be ignored just as other unrecognized commands.
  461.  
  462. Markup Commands
  463.  
  464.    Commands in this section, unlike the other text/enriched commands are
  465.    declarative markup commands. Text/enriched is not intended as a full
  466.    markup language, but instead as a simple way to represent common
  467.    formatting commands. Therefore, markup commands are purposely kept to
  468.    a minimum. It is only because each was deemed so prevalent or
  469.    necessary in an e-mail environment that these particular commands
  470.    have been included at all.
  471.  
  472.      Excerpt
  473.           causes the affected text to be interpreted as a textual
  474.           excerpt from another source, probably a message being
  475.           responded to. Typically this will be displayed using
  476.           indentation and an alternate font, or by indenting lines
  477.           and preceding them with "> ", but such decisions are up
  478.           to the implementation. Note that as with the
  479.           justification commands, the excerpt command implicitly
  480.           begins and ends with a line break if one is not already
  481.           there. Nested "excerpt" commands are acceptable and
  482.           should be interpreted as meaning that the excerpted text
  483.           was excerpted from yet another source. Again, this can be
  484.           displayed using additional indentation, different colors,
  485.           etc.
  486.  
  487.           Optionally, the "excerpt" command can take a parameter by
  488.           using the "param" command. The format of the data is
  489.           unspecified, but it is intended to uniquely identify the
  490.           text from which the excerpt is taken. With this
  491.           information, an implementation should be able to uniquely
  492.           identify the source of any particular excerpt, especially
  493.           if two or more excerpts in the message are from the same
  494.           source, and display it in some way that makes this
  495.           apparent to the user.
  496.  
  497.      Lang
  498.           causes the affected text to be interpreted as belonging
  499.           to a particular language. This is most useful when two
  500.           different languages use the same character set, but may
  501.           require a different font or formatting depending on the
  502.           language. For instance, Chinese and Japanese share
  503.  
  504.  
  505.  
  506. Resnick & Walker             Informational                      [Page 9]
  507.  
  508. RFC 1896            text/enriched MIME Content-type        February 1996
  509.  
  510.  
  511.           similar character glyphs, and in some character sets like
  512.           UNICODE share common code points, but it is considered
  513.           very important that different fonts be used for the two
  514.           languages, especially if they appear together, so that
  515.           meaning is not lost. Also, language information can be
  516.           used to allow for fancier text handling, like spell
  517.           checking or hyphenation.
  518.  
  519.           The "lang" command requires a parameter using the "param"
  520.           command. The parameter data can be any of the language
  521.           tags specified in [RFC-1766], "Tags for the
  522.           Identification of Languages". These tags are the two
  523.           letter language codes taken from [ISO-639] or can be
  524.           other language codes that are registered according to the
  525.           instructions in the Langauge Tags RFC. Consult that memo
  526.           for further information.
  527.  
  528. Balancing and Nesting of Formatting Commands
  529.  
  530.    Pairs of formatting commands must be properly balanced and nested.
  531.    Thus, a proper way to describe text in bold italics is:
  532.  
  533.      <bold><italic>the-text</italic></bold>
  534.  
  535.    or, alternately,
  536.  
  537.      <italic><bold>the-text</bold></italic>
  538.  
  539.    but, in particular, the following is illegal text/enriched:
  540.  
  541.      <bold><italic>the-text</bold></italic>
  542.  
  543.    The nesting requirement for formatting commands imposes a slightly
  544.    higher burden upon the composers of text/enriched bodies, but
  545.    potentially simplifies text/enriched displayers by allowing them to
  546.    be stack-based. The main goal of text/enriched is to be simple enough
  547.    to make multifont, formatted email widely readable, so that those
  548.    with the capability of sending it will be able to do so with
  549.    confidence. Thus slightly increased complexity in the composing
  550.    software was deemed a reasonable tradeoff for simplified reading
  551.    software. Nonetheless, implementors of text/enriched readers are
  552.    encouraged to follow the general Internet guidelines of being
  553.    conservative in what you send and liberal in what you accept. Those
  554.    implementations that can do so are encouraged to deal reasonably with
  555.    improperly nested text/enriched data.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Resnick & Walker             Informational                     [Page 10]
  563.  
  564. RFC 1896            text/enriched MIME Content-type        February 1996
  565.  
  566.  
  567. Unrecognized formatting commands
  568.  
  569.    Implementations must regard any unrecognized formatting command as
  570.    "no-op" commands, that is, as commands having no effect, thus
  571.    facilitating future extensions to "text/enriched". Private extensions
  572.    may be defined using formatting commands that begin with "X-", by
  573.    analogy to Internet mail header field names.
  574.  
  575.    In order to formally define extended commands, a new Internet
  576.    document should be published.
  577.  
  578. White Space in Text/enriched Data
  579.  
  580.    No special behavior is required for the SPACE or TAB (HT) character.
  581.    It is recommended, however, that, at least when fixed-width fonts are
  582.    in use, the common semantics of the TAB (HT) character should be
  583.    observed, namely that it moves to the next column position that is a
  584.    multiple of 8. (In other words, if a TAB (HT) occurs in column n,
  585.    where the leftmost column is column 0, then that TAB (HT) should be
  586.    replaced by 8-(n mod 8) SPACE characters.) It should also be noted
  587.    that some mail gateways are notorious for losing (or, less commonly,
  588.    adding) white space at the end of lines, so reliance on SPACE or TAB
  589.    characters at the end of a line is not recommended.
  590.  
  591. Initial State of a text/enriched interpreter
  592.  
  593.    Text/enriched is assumed to begin with filled text in a variable-
  594.    width font in a normal typeface and a size that is average for the
  595.    current display and user. The left and right margins are assumed to
  596.    be maximal, that is, at the leftmost and rightmost acceptable
  597.    positions.
  598.  
  599. Non-ASCII character sets
  600.  
  601.    One of the great benefits of MIME is the ability to use different
  602.    varieties of non-ASCII text in messages. To use non-ASCII text in a
  603.    message, normally a charset parameter is specified in the Content-
  604.    type line that indicates the character set being used. For purposes
  605.    of this RFC, any legal MIME charset parameter can be used with the
  606.    text/enriched Content-type. However, there are two difficulties that
  607.    arise with regard to the text/enriched Content-type when non-ASCII
  608.    text is desired. The first problem involves difficulties that occur
  609.    when the user wishes to create text which would normally require
  610.    multiple non-ASCII character sets in the same text/enriched message.
  611.    The second problem is an ambiguity that arises because of the
  612.    text/enriched use of the "<" character in formatting commands.
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Resnick & Walker             Informational                     [Page 11]
  619.  
  620. RFC 1896            text/enriched MIME Content-type        February 1996
  621.  
  622.  
  623. Using multiple non-ASCII character sets
  624.  
  625.    Normally, if a user wishes to produce text which contains characters
  626.    from entirely different character sets within the same MIME message
  627.    (for example, using Russian Cyrillic characters from ISO 8859-5 and
  628.    Hebrew characters from ISO 8859-8), a multipart message is used.
  629.    Every time a new character set is desired, a new MIME body part is
  630.    started with different character sets specified in the charset
  631.    parameter of the Content-type line. However, using multiple character
  632.    sets this way in text/enriched messages introduces problems. Since a
  633.    change in the charset parameter requires a new part, text/enriched
  634.    formatting commands used in the first part would not be able to apply
  635.    to text that occurs in subsequent parts. It is not possible for
  636.    text/enriched formatting commands to apply across MIME body part
  637.    boundaries.
  638.  
  639.    [RFC-1341] attempted to get around this problem in the now obsolete
  640.    text/richtext format by introducing different character set
  641.    formatting commands like "iso-8859-5" and "us-ascii". But this, or
  642.    even a more general solution along the same lines, is still
  643.    undesirable: It is common for a MIME application to decide, for
  644.    example, what character font resources or character lookup tables it
  645.    will require based on the information provided by the charset
  646.    parameter of the Content-type line, before it even begins to
  647.    interpret or display the data in that body part. By allowing the
  648.    text/enriched interpreter to subsequently change the character set,
  649.    perhaps to one completely different from the charset specified in the
  650.    Content-type line (with potentially much different resource
  651.    requirements), too much burden would be placed on the text/enriched
  652.    interpreter itself.
  653.  
  654.    Therefore, if multiple types of non-ASCII characters are desired in a
  655.    text/enriched document, one of the following two methods must be
  656.    used:
  657.  
  658.    1. For cases where the different types of non-ASCII text can be
  659.       limited to their own paragraphs with distinct formatting, a
  660.       multipart message can be used with each part having a
  661.       Content-Type of text/enriched and a different charset parameter.
  662.       The one caveat to using this method is that each new part must
  663.       start in the initial state for a text/enriched document. That
  664.       means that all of the text/enriched commands in the preceding
  665.       part must be properly balanced with ending commands before the
  666.       next text/enriched part begins. Also, each text/enriched part
  667.       must begin a new paragraph.
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Resnick & Walker             Informational                     [Page 12]
  675.  
  676. RFC 1896            text/enriched MIME Content-type        February 1996
  677.  
  678.  
  679.    2. If different types of non-ASCII text are to appear in the same
  680.       line or paragraph, or if text/enriched formatting (e.g. margins,
  681.       typeface, justification) is required across several different
  682.       types of non-ASCII text, a single text/enriched body part should
  683.       be used with a character set specified that contains all of the
  684.       required characters. For example, a charset parameter of
  685.       "UNICODE-1-1-UTF-7" as specified in [RFC-1642] could be used for
  686.       such purposes. Not only does UNICODE contain all of the
  687.       characters that can be represented in all of the other registered
  688.       ISO 8859 MIME character sets, but UTF-7 is fully compatible with
  689.       other aspects of the text/enriched standard, including the use of
  690.       the "<" character referred to below. Any other character sets
  691.       that are specified for use in MIME which contain different types
  692.       of non-ASCII text can also be used in these instances.
  693.  
  694. Use of the "<" character in formatting commands
  695.  
  696.    If the character set specified by the charset parameter on the
  697.    Content-type line is anything other than "US-ASCII", this means that
  698.    the text being described by text/enriched formatting commands is in a
  699.    non-ASCII character set. However, the commands themselves are still
  700.    the same ASCII commands that are defined in this document. This
  701.    creates an ambiguity only with reference to the "<" character, the
  702.    octet with numeric value 60. In single byte character sets, such as
  703.    the ISO-8859 family, this is not a problem; the octet 60 can be
  704.    quoted by including it twice, just as for ASCII. The problem is more
  705.    complicated, however, in the case of multi-byte character sets, where
  706.    the octet 60 might appear at any point in the byte sequence for any
  707.    of several characters.
  708.  
  709.    In practice, however, most multi-byte character sets address this
  710.    problem internally. For example, the UNICODE character sets can use
  711.    the UTF-7 encoding which preserves all of the important ASCII
  712.    characters in their single byte form. The ISO-2022 family of
  713.    character sets can use certain character sequences to switch back
  714.    into ASCII at any moment.  Therefore it is specified that, before
  715.    text/enriched formatting commands, the prevailing character set
  716.    should be "switched back" into ASCII, and that only those characters
  717.    which would be interpreted as "<" in plain text should be interpreted
  718.    as token delimiters in text/enriched.
  719.  
  720.    The question of what to do for hypothetical future character sets
  721.    that do not subsume ASCII is not addressed in this memo.
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Resnick & Walker             Informational                     [Page 13]
  731.  
  732. RFC 1896            text/enriched MIME Content-type        February 1996
  733.  
  734.  
  735. Minimal text/enriched conformance
  736.  
  737.    A minimal text/enriched implementation is one that converts "<<" to
  738.    "<", removes everything between a <param> command and the next
  739.    balancing </param> command, removes all other formatting commands
  740.    (all text enclosed in angle brackets), and, outside of <nofill>
  741.    environments, converts any series of n CRLFs to n-1 CRLFs, and
  742.    converts any lone CRLF pairs to SPACE.
  743.  
  744. Notes for Implementors
  745.  
  746.    It is recognized that implementors of future mail systems will want
  747.    rich text functionality far beyond that currently defined for
  748.    text/enriched.  The intent of text/enriched is to provide a common
  749.    format for expressing that functionality in a form in which much of
  750.    it, at least, will be understood by interoperating software. Thus, in
  751.    particular, software with a richer notion of formatted text than
  752.    text/enriched can still use text/enriched as its basic
  753.    representation, but can extend it with new formatting commands and by
  754.    hiding information specific to that software system in text/enriched
  755.    <param> constructs. As such systems evolve, it is expected that the
  756.    definition of text/enriched will be further refined by future
  757.    published specifications, but text/enriched as defined here provides
  758.    a platform on which evolutionary refinements can be based.
  759.  
  760.    An expected common way that sophisticated mail programs will generate
  761.    text/enriched data is as part of a multipart/alternative construct.
  762.    For example, a mail agent that can generate enriched mail in ODA
  763.    format can generate that mail in a more widely interoperable form by
  764.    generating both text/enriched and ODA versions of the same data,
  765.    e.g.:
  766.  
  767.      Content-type: multipart/alternative; boundary=foo
  768.  
  769.      --foo
  770.      Content-type: text/enriched
  771.  
  772.      [text/enriched version of data]
  773.      --foo Content-type: application/oda
  774.  
  775.      [ODA version of data]
  776.      --foo--
  777.  
  778.    If such a message is read using a MIME-conformant mail reader that
  779.    understands ODA, the ODA version will be displayed; otherwise, the
  780.    text/enriched version will be shown.
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Resnick & Walker             Informational                     [Page 14]
  787.  
  788. RFC 1896            text/enriched MIME Content-type        February 1996
  789.  
  790.  
  791.    In some environments, it might be impossible to combine certain
  792.    text/enriched formatting commands, whereas in others they might be
  793.    combined easily. For example, the combination of <bold> and <italic>
  794.    might produce bold italics on systems that support such fonts, but
  795.    there exist systems that can make text bold or italicized, but not
  796.    both. In such cases, the most recently issued (innermost) recognized
  797.    formatting command should be preferred.
  798.  
  799.    One of the major goals in the design of text/enriched was to make it
  800.    so simple that even text-only mailers will implement enriched-to-
  801.    plain-text translators, thus increasing the likelihood that enriched
  802.    text will become "safe" to use very widely. To demonstrate this
  803.    simplicity, an extremely simple C program that converts text/enriched
  804.    input into plain text output is included in Appendix A.
  805.  
  806. Extensions to text/enriched
  807.  
  808.    It is expected that various mail system authors will desire
  809.    extensions to text/enriched. The simple syntax of text/enriched, and
  810.    the specification that unrecognized formatting commands should simply
  811.    be ignored, are intended to promote such extensions.
  812.  
  813. An Example
  814.  
  815.    Putting all this together, the following "text/enriched" body
  816.    fragment:
  817.  
  818.      From: Nathaniel Borenstein <nsb@bellcore.com>
  819.      To: Ned Freed <ned@innosoft.com>
  820.      Content-type: text/enriched
  821.  
  822.      <bold>Now</bold> is the time for <italic>all</italic>
  823.      good men
  824.      <smaller>(and <<women>)</smaller> to
  825.      <ignoreme>come</ignoreme>
  826.  
  827.      to the aid of their
  828.  
  829.  
  830.      <color><param>red</param>beloved</color>
  831.      country.
  832.  
  833.      By the way,
  834.      I think that <paraindent><param>left</param><<smaller>
  835.  
  836.      </paraindent>should REALLY be called
  837.  
  838.      <paraindent><param>left</param><<tinier></paraindent>
  839.  
  840.  
  841.  
  842. Resnick & Walker             Informational                     [Page 15]
  843.  
  844. RFC 1896            text/enriched MIME Content-type        February 1996
  845.  
  846.  
  847.      and that I am always right.
  848.  
  849.      -- the end
  850.  
  851.    represents the following formatted text (which will, no doubt, look
  852.    somewhat cryptic in the text-only version of this document):
  853.  
  854.      Now is the time for all good men (and <women>) to come
  855.      to the aid of their
  856.  
  857.      beloved country.
  858.      By the way, I think that
  859.           <smaller>
  860.      should REALLY be called
  861.           <tinier>
  862.      and that I am always right.
  863.      -- the end
  864.  
  865.    where the word "beloved" would be in red on a color display.
  866.  
  867.    ti 0 Security Considerations
  868.  
  869.    Security issues are not discussed in this memo, as the mechanism
  870.    raises no security issues.
  871.  
  872. Authors' Addresses
  873.  
  874.    For more information, the authors of this document may be contacted
  875.    via Internet mail:
  876.  
  877.    Peter W. Resnick
  878.    QUALCOMM Incorporated
  879.    6455 Lusk Boulevard
  880.    San Diego, CA 92121-2779
  881.  
  882.    Phone: +1 619 587 1121
  883.    Fax: +1 619 658 2230
  884.    EMail: presnick@qualcomm.com
  885.  
  886.  
  887.    Amanda Walker
  888.    InterCon Systems Corporation
  889.    950 Herndon Parkway
  890.    Herndon, VA 22070
  891.  
  892.    Phone: +1 703 709 5500
  893.    Fax: +1 703 709 5555
  894.    EMail: amanda@intercon.com
  895.  
  896.  
  897.  
  898. Resnick & Walker             Informational                     [Page 16]
  899.  
  900. RFC 1896            text/enriched MIME Content-type        February 1996
  901.  
  902.  
  903. Acknowledgements
  904.  
  905.    The authors gratefully acknowledge the input of many contributors,
  906.    readers, and implementors of the specification in this document.
  907.    Particular thanks are due to Nathaniel Borenstein, the original
  908.    author of RFC 1563.
  909.  
  910. References
  911.  
  912.    [RFC-1341]
  913.         Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
  914.         Extensions): Mechanisms for Specifying and Describing the Format
  915.         of Internet Message Bodies", 06/11/1992.
  916.  
  917.    [RFC-1521]
  918.         Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
  919.         Extensions) Part One: Mechanisms for Specifying and Describing
  920.         the Format of Internet Message Bodies", 09/23/1993.
  921.  
  922.    [RFC-1523]
  923.         Borenstein, N., "The text/enriched MIME Content-type",
  924.         09/23/1993.
  925.  
  926.    [RFC-1563]
  927.         Borenstein, N., "The text/enriched MIME Content-type",
  928.         01/10/1994.
  929.  
  930.    [RFC-1642]
  931.         Goldsmith, D., Davis, M., "UTF-7 - A Mail-Safe Transformation
  932.         Format of Unicode", 07/13/1994.
  933.  
  934.    [RFC-1766]
  935.         Alvestrand, H., "Tags for the Identification of Languages",
  936.         03/02/1995.
  937.  
  938.    [RFC-1866]
  939.         Berners-Lee, T., and D. Connolly, D., "Hypertext Markup Language
  940.         - 2.0", 11/03/1995.
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Resnick & Walker             Informational                     [Page 17]
  955.  
  956. RFC 1896            text/enriched MIME Content-type        February 1996
  957.  
  958.  
  959. Appendix A--A Simple enriched-to-plain Translator in C
  960.  
  961.    One of the major goals in the design of the text/enriched subtype of
  962.    the text Content-Type is to make formatted text so simple that even
  963.    text-only mailers will implement enriched-to-plain-text translators,
  964.    thus increasing the likelihood that multifont text will become "safe"
  965.    to use very widely. To demonstrate this simplicity, what follows is a
  966.    simple C program that converts text/enriched input into plain text
  967.    output. Note that the local newline convention (the single character
  968.    represented by "\n") is assumed by this program, but that special
  969.    CRLF handling might be necessary on some systems.
  970.  
  971. #include <ctype.h>
  972. #include <stdio.h>
  973. #include <stdlib.h>
  974. #include <string.h>
  975.  
  976. main() {
  977.     int c, i, paramct=0, newlinect=0, nofill=0;
  978.     char token[62], *p;
  979.  
  980.     while ((c=getc(stdin)) != EOF) {
  981.         if (c == '<') {
  982.             if (newlinect == 1) putc(' ', stdout);
  983.             newlinect = 0;
  984.             c = getc(stdin);
  985.             if (c == '<') {
  986.                 if (paramct <= 0) putc(c, stdout);
  987.             } else {
  988.                 ungetc(c, stdin);
  989.                 for (i=0, p=token;
  990.                     (c=getc(stdin)) != EOF && c != '>'; i++) {
  991.                     if (i < sizeof(token)-1)
  992.                         *p++ = isupper(c) ? tolower(c) : c;
  993.                 }
  994.                 *p = '\0';
  995.                 if (c == EOF) break;
  996.                 if (strcmp(token, "param") == 0)
  997.                     paramct++;
  998.                 else if (strcmp(token, "nofill") == 0)
  999.                     nofill++;
  1000.                 else if (strcmp(token, "/param") == 0)
  1001.                     paramct--;
  1002.                 else if (strcmp(token, "/nofill") == 0)
  1003.                     nofill--;
  1004.             }
  1005.         } else {
  1006.             if (paramct > 0)
  1007.  
  1008.  
  1009.  
  1010. Resnick & Walker             Informational                     [Page 18]
  1011.  
  1012. RFC 1896            text/enriched MIME Content-type        February 1996
  1013.  
  1014.  
  1015.                 ; /* ignore params */
  1016.             else if (c == '\n' && nofill <= 0) {
  1017.                 if (++newlinect > 1) putc(c, stdout);
  1018.             } else {
  1019.                 if (newlinect == 1) putc(' ', stdout);
  1020.                 newlinect = 0;
  1021.                 putc(c, stdout);
  1022.             }
  1023.         }
  1024.     }
  1025.     /* The following line is only needed with line-buffering */
  1026.     putc('\n', stdout);
  1027.     exit(0);
  1028. }
  1029.  
  1030.    It should be noted that one can do considerably better than this in
  1031.    displaying text/enriched data on a dumb terminal. In particular, one
  1032.    can replace font information such as "bold" with textual emphasis
  1033.    (like *this* or _T_H_I_S_). One can also properly handle the
  1034.    text/enriched formatting commands regarding indentation,
  1035.    justification, and others.  However, the above program is all that is
  1036.    necessary in order to present text/enriched on a dumb terminal
  1037.    without showing the user any formatting artifacts.
  1038.  
  1039. Appendix B--A Simple enriched-to-HTML Translator in C
  1040.  
  1041.    It is fully expected that other text formatting standards like HTML
  1042.    and SGML will supplant text/enriched in Internet mail. It is also
  1043.    likely that as this happens, recipients of text/enriched mail will
  1044.    wish to view such mail with an HTML viewer. To this end, the
  1045.    following is a simple example of a C program to convert text/enriched
  1046.    to HTML. Since the current version of HTML at the time of this
  1047.    document's publication is HTML 2.0 defined in [RFC-1866], this
  1048.    program converts to that standard.  There are several text/enriched
  1049.    commands that have no HTML 2.0 equivalent. In those cases, this
  1050.    program simply puts those commands into processing instructions; that
  1051.    is, surrounded by "<?" and ">". As in Appendix A, the local newline
  1052.    convention (the single character represented by "\n") is assumed by
  1053.    this program, but special CRLF handling might be necessary on some
  1054.    systems.
  1055.  
  1056. #include <ctype.h>
  1057. #include <stdio.h>
  1058. #include <stdlib.h>
  1059. #include <string.h>
  1060.  
  1061. main() {
  1062.     int c, i, paramct=0, nofill=0;
  1063.  
  1064.  
  1065.  
  1066. Resnick & Walker             Informational                     [Page 19]
  1067.  
  1068. RFC 1896            text/enriched MIME Content-type        February 1996
  1069.  
  1070.  
  1071.     char token[62], *p;
  1072.  
  1073.     while((c=getc(stdin)) != EOF) {
  1074.         if(c == '<') {
  1075.             c = getc(stdin);
  1076.             if(c == '<') {
  1077.                 fputs("<", stdout);
  1078.             } else {
  1079.                 ungetc(c, stdin);
  1080.                 for (i=0, p=token;
  1081.                     (c=getc(stdin)) != EOF && c != '>'; i++) {
  1082.                     if (i < sizeof(token)-1)
  1083.                         *p++ = isupper(c) ? tolower(c) : c;
  1084.                 }
  1085.                 *p = '\0';
  1086.                 if(c == EOF) break;
  1087.                 if(strcmp(token, "/param") == 0) {
  1088.                     paramct--;
  1089.                     putc('>', stdout);
  1090.                 } else if(paramct > 0) {
  1091.                     fputs("<", stdout);
  1092.                     fputs(token, stdout);
  1093.                     fputs(">", stdout);
  1094.                 } else {
  1095.                     putc('<', stdout);
  1096.                     if(strcmp(token, "nofill") == 0) {
  1097.                         nofill++;
  1098.                         fputs("pre", stdout);
  1099.                     } else if(strcmp(token, "/nofill") == 0) {
  1100.                         nofill--;
  1101.                         fputs("/pre", stdout);
  1102.                     } else if(strcmp(token, "bold") == 0) {
  1103.                         fputs("b", stdout);
  1104.                     } else if(strcmp(token, "/bold") == 0) {
  1105.                         fputs("/b", stdout);
  1106.                     } else if(strcmp(token, "italic") == 0) {
  1107.                         fputs("i", stdout);
  1108.                     } else if(strcmp(token, "/italic") == 0) {
  1109.                         fputs("/i", stdout);
  1110.                     } else if(strcmp(token, "fixed") == 0) {
  1111.                         fputs("tt", stdout);
  1112.                     } else if(strcmp(token, "/fixed") == 0) {
  1113.                         fputs("/tt", stdout);
  1114.                     } else if(strcmp(token, "excerpt") == 0) {
  1115.                         fputs("blockquote", stdout);
  1116.                     } else if(strcmp(token, "/excerpt") == 0) {
  1117.                         fputs("/blockquote", stdout);
  1118.                     } else {
  1119.  
  1120.  
  1121.  
  1122. Resnick & Walker             Informational                     [Page 20]
  1123.  
  1124. RFC 1896            text/enriched MIME Content-type        February 1996
  1125.  
  1126.  
  1127.                         putc('?', stdout);
  1128.                         fputs(token, stdout);
  1129.                         if(strcmp(token, "param") == 0) {
  1130.                             paramct++;
  1131.                             putc(' ', stdout);
  1132.                             continue;
  1133.                         }
  1134.                     }
  1135.                     putc('>', stdout);
  1136.                 }
  1137.             }
  1138.         } else if(c == '>') {
  1139.             fputs(">", stdout);
  1140.         } else if (c == '&') {
  1141.             fputs("&", stdout);
  1142.         } else {
  1143.             if(c == '\n' && nofill <= 0 && paramct <= 0) {
  1144.                 while((i=getc(stdin)) == '\n') fputs("<br>", stdout);
  1145.                 ungetc(i, stdin);
  1146.             }
  1147.             putc(c, stdout);
  1148.         }
  1149.     }
  1150.     /* The following line is only needed with line-buffering */
  1151.     putc('\n', stdout);
  1152.     exit(0);
  1153. }
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Resnick & Walker             Informational                     [Page 21]
  1179.  
  1180.