rfc1523.txt

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

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


              as with the justification commands, the excerpt command
              implicitly begins and ends with a line break if one is not
              already there.

         Verbatim -- causes the affected text to be displayed without
              filling, justification, any interpretation of embedded
              formatting commands, or the usual special rules for CRLF
              handling.  Note, however, that the end token </verbatim>
              must still be recognized.

         Nofill -- causes the affected text to be displayed without
              filling or justification, and hence without any special
              handling of CRLFs, but with all remaining text/enriched
              features continuing to apply.

         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.

   Note that while the absence of a quoting mechanism makes it slightly
   challenging to include the literal string "<verbatim>" inside of a
   verbatim environment, it can be done by breaking up the verbatim
   segment into two verbatim segments as follows:

          <verbatim>
          ...slightly challenging to include the literal string
          "</</verbatim><verbatim>verbatim>" inside of a verbatim
          environment...
          </verbatim>

   Note that the above example demonstrates that it is not desirable for
   an implementation to break lines between tokens.  In particular,
   there should not be a line break inserted between the "</verbatim>"
   and the "<verbatim>" that follows it.

   Balancing and Nesting of Formatting Commands

   Pairs of formatting commands must be properly balanced and nested.
   Thus, a proper way to describe text in bold italics is:

           <bold><italic>the-text</italic></bold>

        or, alternately,

           <italic><bold>the-text</bold></italic>

        but, in particular, the following is illegal
        text/enriched:



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


           <bold><italic>the-text</bold></italic>

   The nesting requirement for formatting commands imposes a slightly
   higher burden upon the composers of text/enriched bodies, but
   potentially simplifies text/enriched displayers by allowing them to
   be stack-based.  The main goal of text/enriched is to be simple
   enough to make multifont, formatted email widely readable, so that
   those with the capability of sending it will be able to do so with
   confidence.  Thus slightly increased complexity in the composing
   software was deemed a reasonable tradeoff for simplified reading
   software.  Nonetheless, implementors of text/enriched readers are
   encouraged to follow the general Internet guidelines of being
   conservative in what you send and liberal in what you accept.  Those
   implementations that can do so are encouraged to deal reasonably with
   improperly nested text/enriched data.

   Unrecognized formatting commands

   Implementations must regard any unrecognized formatting command as
   "no-op" commands, that is, as commands having no effect, thus
   facilitating future extensions to "text/enriched".  Private
   extensions may be defined using formatting commands that begin with
   "X-", by analogy to Internet mail header field names.

   In order to formally define extended commands, a new Internet
   document should be published.

   "White Space" in text/enriched Data

   No special behavior is required for the SPACE or TAB (HT) character.
   It is recommended, however, that, at least when fixed-width fonts are
   in use, the common semantics of the TAB (HT) character should be
   observed, namely that it moves to the next column position that is a
   multiple of 8.  (In other words, if a TAB (HT) occurs in column n,
   where the leftmost column is column 0, then that TAB (HT) should be
   replaced by 8-(n mod 8) SPACE characters.)  It should also be noted
   that some mail gateways are notorious for losing (or, less commonly,
   adding) white space at the end of lines, so reliance on SPACE or TAB
   characters at the end of a line is not recommended.

Initial State of a text/enriched interpreter

   Text/enriched is assumed to begin with filled, fully justified text
   in a variable-width font in a normal typeface and a size that is
   average for the current display and user.  The left and right margins
   are assumed to be maximal, that is, at the leftmost and rightmost
   acceptable positions.




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


   Non-ASCII character sets

   If the character set specified by the charset parameter on the
   Content-type line is anything other than "US-ASCII", this means that
   the text being described by text/enriched formatting commands is in a
   non-ASCII character set.  However, the commands themselves are still
   the same ASCII commands that are defined in this document.  This
   creates an ambiguity only with reference to the "<" character, the
   octet with numeric value 60.  In single byte character sets, such as
   the ISO-8859 family, this is not a problem; the octet 60 can be
   quoted by including it twice, just as for ASCII.  The problem is more
   complicated, however, in the case of multi-byte character sets, where
   the octet 60 might appear at any point in the byte sequence for any
   of several characters.

   In practice, however, most multibyte character sets address this
   problem internally. For example, the ISO-2022 family of character
   sets can switch back into ASCII at any moment.  Therefore it is
   specified that, before text/enriched formatting commands, the
   prevailing character set should be "switched back" into ASCII, and
   that only those characters which would be interpreted as "<" in plain
   text should be interpreted as token delimiters in text/enriched.

   The question of what to do for hypothetical future character sets
   that do NOT subsume ASCII is not addressed in this memo.

   Minimal text/enriched conformance

   A minimal text/enriched implementation is one that simply recognizes
   the beginning and ending of "verbatim" environments and, outside of
   them, converts "<<" to "<", removes everything between a <param>
   command and the next balancing </param> command, removes all other
   formatting commands (all text enclosed in angle brackets), converts
   any series of n CRLFs to n-1 CRLFs, and converts any lone CRLF pairs
   to SPACE.

   Notes for Implementors

   It is recognized that implementors of future mail systems will want
   rich text functionality far beyond that currently defined for
   text/enriched.  The intent of text/enriched is to provide a common
   format for expressing that functionality in a form in which much of
   it, at least, will be understood by interoperating software.  Thus,
   in particular, software with a richer notion of formatted text than
   text/enriched can still use text/enriched as its basic
   representation, but can extend it with new formatting commands and by
   hiding information specific to that software system in text/enriched
   <param> constructs. As such systems evolve, it is expected that the



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


   definition of text/enriched will be further refined by future
   published specifications, but text/enriched as defined here provides
   a platform on which evolutionary refinements can be based.

   An expected common way that sophisticated mail programs will generate
   text/enriched data is as part of a multipart/alternative construct.
   For example, a mail agent that can generate enriched mail in ODA
   format can generate that mail in a more widely interoperable form by
   generating both text/enriched and ODA versions of the same data,
   e.g.:

         Content-type: multipart/alternative; boundary=foo

         --foo
         Content-type: text/enriched

         [text/enriched version of data]
         --foo
         Content-type: application/oda

         [ODA version of data]
         --foo--

   If such a message is read using a MIME-conformant mail reader that
   understands ODA, the ODA version will be displayed; otherwise, the
   text/enriched version will be shown.

   In some environments, it might be impossible to combine certain
   text/enriched formatting commands, whereas in others they might be
   combined easily.  For example, the combination of <bold> and <italic>
   might produce bold italics on systems that support such fonts, but
   there exist systems that can make text bold or italicized, but not
   both.  In such cases, the most recently issued (innermost) recognized
   formatting command should be preferred.

   One of the major goals in the design of text/enriched was to make it
   so simple that even text-only mailers will implement enriched-to-
   plain-text translators, thus increasing the likelihood that enriched
   text will become "safe" to use very widely.  To demonstrate this
   simplicity, an extremely simple C program that converts text/enriched
   input into plain text output is included in Appendix A.

   Extensions to text/enriched

   It is expected that various mail system authors will desire
   extensions to text/enriched.  The simple syntax of text/enriched, and
   the specification that unrecognized formatting commands should simply
   be ignored, are intend to promote such extensions.



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


   Beyond simply defining new formatting commands, however, it may
   sometimes be necessary to define formatting commands that can take
   arguments.  This is the intended use of the <param> construct.  In
   particular, software that wished to extend text/enriched to include
   colored text might define an "x-color" environment which always began
   with a color name parameter, to indicate the desired color for the
   affected text.

   An Example

   Putting all this together, the following "text/enriched" body
   fragment:

         From: Nathaniel Borenstein <[e-mail]>
         To: Ned Freed <[e-mail]>
         Content-type: text/enriched

         <bold>Now</bold> is the time for
         <italic>all</italic> good men
         <smaller>(and <<women>)</smaller> to
         <ignoreme>come</ignoreme>

         to the aid of their

         <x-color><param>red</param>beloved</x-color>country.
         <verbatim>
         By the way, I think that <smaller>
         should
         REALLY be called
         <tinier>
         and that I am always right.
         -- the end
         </verbatim>

   represents the following formatted text (which will, no doubt, look
   somewhat cryptic in the text-only version of this document):

         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



Borenstein                                                     [Page 10]