One document matched: draft-newman-mime-textpara-00.txt

Network Working Group                                          C. Newman
Internet Draft: The Text/Paragraph Media Type                   N. Freed
Document: draft-newman-mime-textpara-00.txt                     Innosoft
                                                           February 1998


                     The Text/Paragraph Media Type


Status of this memo

     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its areas,
     and its working groups.  Note that other groups may also distribute
     working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
     Coast), or ftp.isi.edu (US West Coast).


Introduction

     The text/plain media type is defined to represent plain text where
     the CRLF sequence represents a line break [MIME-IMT].  Many modern
     computer systems have a different concept of ``plain text'' from
     the systems where the text/plain media type originated.  These
     modern systems usually use a proportional-spaced font and use CRLF
     to represent paragraph breaks.  Numerous software products have
     erroneously labelled this media type as text/plain.  In order to
     correct this interoperability problem, the text/paragraph media
     type is defined.

     [NOTE: This proposal may be discussed publicly on the ietf-
     822@imc.org mailing list.  The subscription address is ietf-822-
     request@imc.org.]


1. Conventions Used in this Document




Newman                                                          [Page 1]

Internet Draft       The Text/Paragraph Media Type         February 1998


     The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
     NOT", and "MAY" in this document are to be interpreted as described
     in "Key words for use in RFCs to Indicate Requirement Levels"
     [KEYWORDS].


2. The text/paragraph Media Type

     MIME media type name: text

     MIME subtype name: paragraph

     Required parameters: none

     Optional parameters: charset

     Encoding considerations:

     The text/paragraph media type is likely to include paragraphs
     longer than 1000 characters (including the terminating CRLF
     characters).  Therefore the quoted-printable content transfer
     encoding is usually necessary for transport over systems with line
     length limits such as SMTP [SMTP].  If all paragraphs fit within
     the line length limits of the underlying transport, then the 7-bit
     or 8-bit content transfer encoding may be used if appropriate for
     the specified charset.

     Security considerations:

     This media type has the same security considerations as text/plain.

     Interoperability considerations:

     An agent which receives text/paragraph and doesn't understand it is
     REQUIRED to display it as text/plain by MIME [MIME-CONF] -- this
     could result in paragraphs being displayed as long lines which
     extend outside the visible display area, but many clients offer the
     ability to wrap such lines.  This is an improvement over the
     current practice where the text/paragraph media type is mislabelled
     as text/plain and therefore the user agent has a choice between
     risking the previous problem or damaging text/plain content by word
     wrapping it.

     It is simple to convert text/paragraph to text/plain (by word
     wrapping near the 72nd character column), but there is no
     algorithmic method to reliably create a text/paragraph media type
     from a text/plain media type.  There is also no algorithmic way to
     distinguish text/plain from text/paragraph when they are



Newman                                                          [Page 2]

Internet Draft       The Text/Paragraph Media Type         February 1998


     unlabelled.  Heuristics can often produce satifactory results in
     these cases, but when the heuristics fail, the results can be
     unpleasant.

     Published specification:

     The text/paragraph media follows the definition of the text/plain
     media type as specified in [MIME-IMT] except that a CRLF represents
     the end of a paragraph rather than the end of a line.

     Additional information:

     Magic Number(s): none

     File extension(s):
       No clear distinction is made between text/plain and text/paragraph
       for file extensions.  The ".txt" extension is used for both (this
       internet draft is text/plain).  The ".asc" or ".ascii" extension is
       traditionally used for text/plain with the US-ASCII character set.

     Macintosh File Type Code(s): TEXT
       NOTE: the TEXT file type on MacOS is used for both text/paragraph
       and text/plain.  The system application "SimpleText" generates
       a text/paragraph file with type TEXT (which also may contain
       MacOS-specific out-of-band markup in the resource fork).  Text
       editors such as those which come with compilers use text/plain.

     Intended usage: COMMON


3. User-Visible Differences between text/plain and text/paragraph

     The text/plain media type is not intended to be word wrapped.  In
     fact, word wrapping text/plain can make the text difficult to read,
     as it results in situations like the following:

         The text/plain media type is not intended to be word wrapped.
         In
         fact, word wrapping text/plain can make the text difficult to
         read,
         as it results in situations like the following:

             The text/plain media type is not intended to be
             word wrapped.
             In
             fact, word wrapping text/plain can make the text difficult
             to
             read,



Newman                                                          [Page 3]

Internet Draft       The Text/Paragraph Media Type         February 1998


             as it results in situations like the following:

                 ...

     The text/paragraph media type, on the other hand, is intended to be
     word wrapped for display and will not cause this problem.

     There is an unwritten convention that text/plain is displayed in a
     fixed-width font, thus permitting the use of ASCII-art to represent
     graphics and tables.  The text/paragraph media type is suitable for
     display in a proportional width font and for line-wrapping, and
     thus it is not suitable for ASCII-art (such as is commonly used in
     message signatures).

     A common convention in Internet messages with the text/plain media
     type is to use the ">" character at the beginning of a line to
     quote text from a previous text/plain message when generating a
     reply.  Agents receiving text/paragraph in a message MAY wish to
     consider this convention when displaying it.

     It is important to note that the conversion from text/paragraph to
     text/plain is algorithmicly a one-way process and thus is not to be
     done when unnecessary.


4. Requirements

     User agents MUST offer an option to display text/plain without line
     wrapping and SHOULD display it in a fixed-width font.  User agents
     MAY offer an option to word wrap text/plain to deal with the
     unfortunately common practice of mislabelling text/paragraph as
     text/plain.

     User agents SHOULD word wrap text/paragraph on display and MAY
     display it in either a proportional or fixed-width font.  Because
     the algorithm for quality word wrapping can vary by language,
     generating agents SHOULD include a Content-Language header [LANG].

     Non-Internet mail systems often use paragraph-based text formats.
     A gateway from such a system MUST NOT label paragraph-based text as
     text/plain.  Instead, it MAY label such paragraph-based text as
     text/paragraph (or a suitable markup format) or convert to
     text/plain by word wrapping near the 72nd column.


5. Security Considerations

     This media type introduces no security considerations beyond those



Newman                                                          [Page 4]

Internet Draft       The Text/Paragraph Media Type         February 1998


     which apply to text/plain.  Considerations that apply to both
     follow.

     Some text display processors will scan text media types for
     recognizable sequences such as URLs or even nonstandard embedded
     commands.  Embedded commands can have the same sorts of security
     issues as PostScript. (The discussion of the
     "application/PostScript" media type [MIME-IMT] considers these
     risks in detail.)  In general, it may be possible to specify
     commands that perform unauthorized file operations or, make changes
     to the display processor's environment that affect subsequent
     operations.  Such nonstandard commands are often added for
     debugging purposes.  However, implementors should never assume that
     existance of such command can be kept secret and as such should
     make sure that any nonstandard commands with the potential to cause
     harm are disabled by default.

     Plain text (or other subtypes of text displayed as plain text) can
     contain embedded control characters and escape sequences which also
     have the potential to change the display processor environment in
     ways that adversely affect subsequent operations. Possible effects
     include, but are not limited to, locking the keyboard, changing
     display parameters so subsequent displayed text is unreadable, or
     even changing display parameters to deliberately obscure or distort
     subsequent displayed material so that its meaning is lost or
     altered.  Display processors should either filter such material
     from displayed text or else make sure to reset all important
     settings after a given display operation is complete.

     Some terminal devices have keys whose output when pressed can be
     changed by sending the display processor a character sequence. If
     this is possible the display of a text object containing such
     character sequences could reprogram keys to perform some illicit or
     dangerous action when the key is subsequently pressed by the user.
     In some cases not only can keys be programmed, they can be
     triggered remotely, making it possible for a text display operation
     to directly perform some unwanted action. As such, the ability to
     program keys should be blocked either by filtering or by disabling
     the ability to program keys entirely.


6. References

     [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
     Requirement Levels", RFC 2119, Harvard University, March 1997.

     [LANG] Alvestrand, H., "Tags for the Identification of Languages",
     RFC 1766, UNINETT, March 1995.



Newman                                                          [Page 5]

Internet Draft       The Text/Paragraph Media Type         February 1998


     [MIME-IMT] Freed, Borenstein, "Multipurpose Internet Mail
     Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First
     Virtual, November 1996.

     [MIME-CONF] Freed, Borenstein, "Multipurpose Internet Mail
     Extensions (MIME) Part Five: Conformance Criteria and Examples",
     RFC 2046, Innosoft, First Virtual, November 1996.

     [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821,
     Information Sciences Institute, August 1982.


7. Author's Address

     Chris Newman
     Innosoft International, Inc.
     1050 Lakes Drive
     West Covina, CA 91790 USA

     Email: chris.newman@innosoft.com

     Ned Freed
     Innosoft International, Inc.
     1050 Lakes Drive
     West Covina, CA 91790 USA

     Email: ned.freed@innosoft.com
























Newman                                                          [Page 6]