I find the response to Laurence's text/paragraph test to be what I
expected; significant compatibility problems still exist, in mailers it
would scare me to ignore.
RFC 2046:
4.1.1. Representation of Line Breaks
...
Similarly, whether or not line breaks should be added during display
operations is also a function of the media type. It should not be
necessary to add any line breaks to display "text/plain" correctly
...
4.1.3. Plain Subtype
...The
default media type of "text/plain; charset=us-ascii" for Internet
mail describes existing Internet practice. That is, it is the type
of body defined by RFC 822.
So, does 822 impose a no-folding-necessary rule? The only item I can find
in 822 that mentions the body is:
3.1. GENERAL DESCRIPTION
A message consists of header fields and, optionally, a body.
The body is simply a sequence of lines containing ASCII charac-
ters. It is separated from the headers by a null line (i.e., a
line with nothing preceding the CRLF).
This says nothing about line length at all. The only mention in 822 I can
find of lengths is:
3.4.8. FOLDING LONG HEADER FIELDS
...For readability, the
field-body portion of long header fields may be "folded" onto
multiple lines of the actual field. "Long" is commonly inter-
preted to mean greater than 65 or 72 characters. The former
length serves as a limit, when the message is to be viewed on
most simple terminals which use simple display software; how-
ever, the limit is not imposed by this standard.
Note: Some display software often can selectively fold lines,
to suit the display terminal. In such cases, sender-
provided folding can interfere with the display
software.
Note that this does not impose a length restriction, and in the note gives
tacit approval to letting the sender do the wrapping. Yes, this is in the
headers, not the body; I find it hard to believe that matters; the point
is, RFC 822 is clearly providing for long lines and recipient wrapping
rather than declaring long lines to be illegal.
So I think that 2046.4.1.1 and 2046.4.1.3 are in conflict with one another.
text/plain can't be both required to be viewable without added line breaks
and a description of RFC 822 mail, since RFC 822 had no such restriction.
So:
- Long lines in 822 were permissible, even lines that needed to be wrapped
for display.
- 2046 claims that text/plain is the same as 822.
- 2046 also claims that text/plain must be viewable without wrapping, which
seems to me to conflict with the previous two statements.
- There will be significant compatibility problems if people start sending
text/paragraph.
- I'm not aware of significant compatibility problems with text/plain &
long lines.
It seems to me that if there is a desire to have a type that should be
prewrapped and not need to be rewrapped, that should be the new type;
text/tty or something. I would be equally happy with a "wrap" parameter to
text/plain. However, I don't see much point in generating text/paragraph,
since it will be handled poorly by some major MUA's.