One document matched: draft-gellens-format-00.txt
Internet Draft: The TEXT/PLAIN FORMAT Parameter R. Gellens, Editor
Document: draft-gellens-format-00.txt Qualcomm
Expires: 7 February 1999 7 August
1998
The TEXT/PLAIN FORMAT Parameter
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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
To learn the current status of any Internet Draft, please check the
"1id-abstracts.txt" listing contained in the Internet Drafts shadow
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Comments
A version of this draft document is intended for submission to the
RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested.
Private comments should be sent to the author. Public comments may
be sent to the IETF 822 mailing list, <ietf-822@imc.org>. To
subscribe, send a message to <ietf-822-request@imc.org> with the
word SUBSCRIBE as the body of the message. Archives for the list
are at <http://www.imc.org/ietf-822/>.
Comments are especially desired on the problems mentioned in section
7, in particular where the text "[[[COMMENTS?]]]" appears.
Copyright Notice
Copyright (C) The Internet Society 1998. All Rights Reserved.
Gellens [Page 1] Expires February
1999 Internet Draft The FORMAT Parameter August
1998
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . 2
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . . 3
3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . . 3
3.3. New Media Types . . . . . . . . . . . . . . . . . . . . . 3
4. The FORMAT Parameter to the TEXT/PLAIN Media Type . . . . . 4
5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Line Analysis Table . . . . . . . . . . . . . . . . . . . . 5
7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Trailing White Space Corruption . . . . . . . . . . . . 5
7.2. The Usenet Signature Convention . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . 6
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
11. Editor's Address . . . . . . . . . . . . . . . . . . . . . . 7
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 7
1. Introduction
Interoperability problems have been observed with erroneous
labelling of paragraph text as TEXT/PLAIN, and with various forms of
"embarrassing line wrap." (See section 3.)
Attempts to deploy new media types, such as TEXT/ENRICHED [RICH] and
TEXT/HTML [HTML] have suffered from a lack of backwards
compatibility and an often hostile user reaction at the receiving
end.
What is desired is a format which is in all significant ways
TEXT/PLAIN, and therefore is quite suitable for display as
TEXT/PLAIN, and yet allows the sender to express to the receiver
which lines can be considered a logical paragraph, and thus flowed
(wrapped and joined) as appropriate.
This memo proposes a new parameter to be used with TEXT/PLAIN, and,
in the presence of this parameter, the use of trailing whitespace to
indicate flowed lines. This results in an encoding which appears as
normal TEXT/PLAIN in older implementations, since it is in fact
normal TEXT/PLAIN.
2. Conventions Used in this Document
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].
Gellens [Page 2] Expires February
1999 Internet Draft The FORMAT Parameter August
1998
3. The Problem
The TEXT/PLAIN media type is the lowest common denominator of
Internet email, with lines of no more than 998 characters (by
convention usually no more than 80), and where the CRLF sequence
represents a line break [MIME-IMT].
TEXT/PLAIN is usually displayed as preformatted text, often in a
fixed font. That is, the characters start at the left margin of the
display window, and advance to the right until a CRLF sequence is
seen, at which point a new line is started, again at the left
margin. When a line length exceeds the display window, some clients
will wrap the line, while others invoke a horizontal scroll bar.
Some interoperability problems have been observed with this media
type:
3.1. Paragraph Text
Many modern programs use a proportional-spaced font and CRLF to
represent paragraph breaks. Line breaks are "soft", occurring as
needed on display. That is, characters are grouped into a paragraph
until a CRLF sequence is seen, at which point a new paragraph is
started. Each paragraph is displayed, starting at the left margin
(or paragraph indent), and continuing to the right until a word is
encountered which does not fit in the remaining display width. The
display shifts to the next line, starting with the word which would
not fit on the previous line. This continues until the paragraph
ends (a CRLF is seen). Extra vertical space is left between
paragraphs.
Numerous software products erroneously label this media type as
TEXT/PLAIN, resulting in much user discomfort.
3.2. Embarrassing Line Wrap
As TEXT/PLAIN messages get quoted in replies or forwarded, the
length of each line gradually increases, resulting in "embarrassing
line wrap." This results in text which is at best hard to read, and
often confuses attributions.
In addition, as devices with display widths smaller than 80
characters become more popular, embarrassing line wrap has become
even more prevalent, even with unquoted text.
3.3. New Media Types
Attempts to deploy new media types, such as TEXT/ENRICHED [RICH] and
TEXT/HTML [HTML] have suffered from a lack of backwards
compatibility and an often hostile user reaction at the receiving
end.
Gellens [Page 3] Expires February
1999 Internet Draft The FORMAT Parameter August
1998
In particular, TEXT/ENRICHED requires that open angle brackets ("<")
and hard line breaks be doubled, with resulting user unhappiness
when viewed as TEXT/PLAIN. TEXT/HTML requires even more alteration
of text, with a corresponding increase in user complaints.
A proposal to define a new media type to explicitly represent the
paragraph form suffered from a lack of interoperability with
currently deployed software. Some programs treat unknown subtypes
of TEXT as an attachment.
What is desired is a format which is in all significant ways
TEXT/PLAIN, and therefore is quite suitable for display as
TEXT/PLAIN, and yet allows the sender to express to the receiver
which lines can be considered a logical paragraph, and thus flowed
(wrapped and joined) as appropriate.
4. The FORMAT Parameter to the TEXT/PLAIN Media Type
This document defines a new MIME parameter for use with TEXT/PLAIN:
Name: Format
Value: Fixed-Lines, Flowed
(Neither the parameter name nor its value are case sensitive.)
If not specified, a value of Fixed-Lines is assumed. The semantics
of the Fixed-Lines value are the usual associated with TEXT/PLAIN
[MIME-IMT].
A value of Flowed indicates that any line which ends in exactly one
space MAY be treated as a "flowed" line. A series of one or more
such lines is considered a paragraph, and MAY be flowed (wrapped and
unwrapped) as appropriate on display and in the construction of new
messages (see section 5).
A line consisting of exactly one space is considered a flowed line.
Because flowed lines are all-but-indistinguishable from fixed lines,
currently deployed software will treat flowed lines as normal
TEXT/PLAIN (which is what they are). Thus, no interoperability
problems are expected.
5. Quoting
When Format=Flowed, the canonical quote indicator is an open angle
bracket (">"), optionally followed by a space ("> "). Lines which
start with one or more quote indicators are considered quoted.
Flowed lines which are also quoted may require special handling on
display and when copied to new messages.
Gellens [Page 4] Expires February
1999 Internet Draft The FORMAT Parameter August
1998
When creating quoted flowed lines, each such line MUST start with
one or more quote indicators.
If a receiving agent wishes to reformat flowed quoted lines (joining
and/or wrapping them) on display or when generating new messages,
the lines SHOULD be dequoted, reformatted, and then requoted. To
dequote, the number of quote indicators at the start of each line is
counted. Consecutive lines with the same quoting depth are
considered one logical entity and are reformatted together. To
requote after reformatting, the same number of quote indicators
originally present are prefixed to each line. Either ">" or "> "
MAY be used to requote, but the agent SHOULD be consistent.
6. Line Analysis Table
Lines contained in a TEXT body part with Format=Flowed can be
analyzed by examining the start and end of the line. If the line
starts with one ore more quote indicators, it is quoted. If the
line ends with exactly one space character, it is flowed. This is
summarized by the following table:
Starts Ends in
with Exactly Line
Quote One Space Type
------ --------- ---------------
no no unquoted, fixed
yes no quoted, fixed
no yes unquoted, flowed
yes yes quoted, flowed
7. Failure Modes
7.1. Trailing White Space Corruption
There are systems in existence which alter trailing whitespace on
messages which pass through them. Such systems may strip, or in
rarer cases, add trailing whitespace, in violation of RFC 821 [SMTP]
section 4.5.2.
Stripping trailing whitespace has the effect of converting flowed
lines to fixed lines, which results in a message no worse than if
the parameter had not been used.
Adding trailing whitespace most often has no effect or merely
converts flowed lines to fixed, but if exactly one trailing space is
added to one or more lines of a message which uses the Format=Flowed
parameter, the effect may be a corrupted display or reply. Since
most systems which add trailing white space do so to create a line
which fills an internal record format, the result is almost always a
line which contains an even number of characters (counting the added
Gellens [Page 5] Expires February
1999 Internet Draft The FORMAT Parameter August
1998
trailing white space).
One possible avoidance, therefore, would be to define Format=Flowed
lines to use either one or two trailing space characters to indicate
a flowed line, such that the total line length is odd. However,
considering the scarcity of such systems today, it is not worth the
added complexity. [[[COMMENTS?]]]
7.2. The Usenet Signature Convention
There is a convention in Usenet news of using "-- " as the separator
line between the body and the signature of a message. If such a
line is present in a Format=Flowed message, a receiving system may
erroneously flow the first line of the signature with the signature
separator line on display or in the creation of new messages.
This could be avoided by (a) treating "-- " as a special case, (b)
advising user agents which create Format=Flowed messages to put the
signature (and separator line) in an additional body part or use
either zero or two spaces in the signature separator, or (c) define
Format=Flowed lines to use two trailing space characters to indicate
a flowed line (or either two or three, to also deal with trailing
white space corruption).
As the "-- " convention is not widely used on receipt, it is not
considered worth extra complexity to avoid. [[[COMMENTS?]]]
8. Security Considerations
This parameter introduces no security considerations beyond those
which apply to text/plain.
9. Acknowledgments
This proposal evolved from a discussion of Chris Newman's
TEXT/PARAGRAPH draft, which took place on the IETF 822 mailing list.
10. References
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997.
[RICH] Resnick, Walker, "The text/enriched MIME Content-type", RFC
1896, QUALCOMM, InterCon, February 1996.
[MIME-IMT] Freed, Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual,
November 1996.
Gellens [Page 6] Expires February
1999 Internet Draft The FORMAT Parameter August
1998
[SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821, Information
Sciences Institute, August 1982.
11. Editor's Address
Randall Gellens +1 619 651 5115
QUALCOMM Incorporated randy@qualcomm.com
6455 Lusk Blvd.
San Diego, CA 92121-2779
USA
12. Full Copyright Statement
Copyright (C) The Internet Society 1998. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gellens [Page 7] Expires February 1999
| PAFTECH AB 2003-2026 | 2026-04-24 07:31:41 |