rfc1896.txt

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

Initial State of a text/enriched interpreter

   Text/enriched is assumed to begin with filled 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.

Non-ASCII character sets

   One of the great benefits of MIME is the ability to use different
   varieties of non-ASCII text in messages. To use non-ASCII text in a
   message, normally a charset parameter is specified in the Content-
   type line that indicates the character set being used. For purposes
   of this RFC, any legal MIME charset parameter can be used with the
   text/enriched Content-type. However, there are two difficulties that
   arise with regard to the text/enriched Content-type when non-ASCII
   text is desired. The first problem involves difficulties that occur
   when the user wishes to create text which would normally require
   multiple non-ASCII character sets in the same text/enriched message.
   The second problem is an ambiguity that arises because of the
   text/enriched use of the "<" character in formatting commands.





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


Using multiple non-ASCII character sets

   Normally, if a user wishes to produce text which contains characters
   from entirely different character sets within the same MIME message
   (for example, using Russian Cyrillic characters from ISO 8859-5 and
   Hebrew characters from ISO 8859-8), a multipart message is used.
   Every time a new character set is desired, a new MIME body part is
   started with different character sets specified in the charset
   parameter of the Content-type line. However, using multiple character
   sets this way in text/enriched messages introduces problems. Since a
   change in the charset parameter requires a new part, text/enriched
   formatting commands used in the first part would not be able to apply
   to text that occurs in subsequent parts. It is not possible for
   text/enriched formatting commands to apply across MIME body part
   boundaries.

   [RFC-1341] attempted to get around this problem in the now obsolete
   text/richtext format by introducing different character set
   formatting commands like "iso-8859-5" and "us-ascii". But this, or
   even a more general solution along the same lines, is still
   undesirable: It is common for a MIME application to decide, for
   example, what character font resources or character lookup tables it
   will require based on the information provided by the charset
   parameter of the Content-type line, before it even begins to
   interpret or display the data in that body part. By allowing the
   text/enriched interpreter to subsequently change the character set,
   perhaps to one completely different from the charset specified in the
   Content-type line (with potentially much different resource
   requirements), too much burden would be placed on the text/enriched
   interpreter itself.

   Therefore, if multiple types of non-ASCII characters are desired in a
   text/enriched document, one of the following two methods must be
   used:

   1. For cases where the different types of non-ASCII text can be
      limited to their own paragraphs with distinct formatting, a
      multipart message can be used with each part having a
      Content-Type of text/enriched and a different charset parameter.
      The one caveat to using this method is that each new part must
      start in the initial state for a text/enriched document. That
      means that all of the text/enriched commands in the preceding
      part must be properly balanced with ending commands before the
      next text/enriched part begins. Also, each text/enriched part
      must begin a new paragraph.






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


   2. If different types of non-ASCII text are to appear in the same
      line or paragraph, or if text/enriched formatting (e.g. margins,
      typeface, justification) is required across several different
      types of non-ASCII text, a single text/enriched body part should
      be used with a character set specified that contains all of the
      required characters. For example, a charset parameter of
      "UNICODE-1-1-UTF-7" as specified in [RFC-1642] could be used for
      such purposes. Not only does UNICODE contain all of the
      characters that can be represented in all of the other registered
      ISO 8859 MIME character sets, but UTF-7 is fully compatible with
      other aspects of the text/enriched standard, including the use of
      the "<" character referred to below. Any other character sets
      that are specified for use in MIME which contain different types
      of non-ASCII text can also be used in these instances.

Use of the "<" character in formatting commands

   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 multi-byte character sets address this
   problem internally. For example, the UNICODE character sets can use
   the UTF-7 encoding which preserves all of the important ASCII
   characters in their single byte form. The ISO-2022 family of
   character sets can use certain character sequences to 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.








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


Minimal text/enriched conformance

   A minimal text/enriched implementation is one that 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), and, outside of <nofill>
   environments, 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
   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.





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


   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 intended to promote such extensions.

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


     <color><param>red</param>beloved</color>
     country.

     By the way,
     I think that <paraindent><param>left</param><<smaller>

     </paraindent>should REALLY be called

     <paraindent><param>left</param><<tinier></paraindent>



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


     and that I am always right.

     -- the end

   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

   where the word "beloved" would be in red on a color display.

   ti 0 Security Considerations

   Security issues are not discussed in this memo, as the mechanism
   raises no security issues.

Authors' Addresses

   For more information, the authors of this document may be contacted
   via Internet mail:

   Peter W. Resnick
   QUALCOMM Incorporated
   6455 Lusk Boulevard
   San Diego, CA 92121-2779

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]