I am. I run into them on a daily basis in the customer support work I do.
The document <draft-newman-mime-textpara-00.txt> says this as well, but
like you without explanation. What are the compatibility problems here?
That some MUAs use a horizontal scrollbar when long lines occur? That some
MUAs are unable to display long lines? What exactly is the problem?
I believe I've described this several times already, but anyway...
The main problem I see is a second order one. People send around mail with long
lines intending for the lines to be treated as paragraphs. This works quite
poorly on a large number of existing mail clients. So people proceed to "fix"
these clients by adding facilities to perform line wrapping.
But they don't do it right. Instead of adding this as a display-time option
they add it as a facility that actually reformats messages. Sometimes this is
because they're incompetent, but more often than not it is because they don't
have access to the display machinery and must instead do this processing at
some other point in the message handling process.
Regardless, the end result is that these facilities end up getting applied to
messages that contain structured material -- tables, ASCII art, configuration
files, you name it. And the result is useless trash.
This is a widespread problem. We see it cropping up in a wide variety of
widely used products.
This malaise also has a funny way of hitting very highly placed people in
companies. I don't know why exactly -- perhaps its because these people
tend to send around more tabular information or something, or perhaps its
simply because the complaints of regular users are simply ignored by
technical staff. But the end result is that we have it thrown in our
face on a regular basis with quite a bit of force.
We also suffer from this ourselves, since we often send around configuration
files and the like through email as part of tech support. However, while it is
easy to get someone technical to resend a text file as a binary attachment,
this approach is a nonstarter when you're talking about a corporate VP.
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.
As you might well imagine, I am completely opposed to this.
I'm not totally sure I know what the above opposition refers to, so let me
weed this one out:
Are you opposed to a parameter to text/plain that means "I intend for these
long lines to be displayed wrapped"? Are you opposed to perhaps a
Content-Disposition that says "inline; wrapped"?
Neither of these have anything to do with the solution the quoted paragraph
above proposes. And so I'm not opposed to either of them, at least not
totally. (I do think they're both nonstarters but for other reasons.)
My opposition was and is to the idea of creating a new text/tty type to capture
the semantics text/plain is supposed to have. I am opposed to this because it
violates a fundamental IETF rule -- we don't declare existing, standardized
practice to be invalid.
There is nothing I can find in 2046 or 2049 which entails that text/plain
SHOULD NOT or MUST NOT be wrapped for display; in fact, that requirement
would be silly on devices which can fit substantially less than 72 columns
of text on the screen.
Of course there is no such requirement. However, there is a requirement that
that text/plain should be constructed so that this is not necessary.
The only thing that these documents say is that
text/plain should be able to be displayed "uninterpreted", presumably
differentiating it from text/enriched and the like in that you don't have
to interpret the characters inside text/plain as meaning something other
than "character". So, text/plain is defining an interpretation semantics,
but not a display semantics per se.
Read the documents again. This is not all they say.
It seems to me that the only problem with the "long line as paragraph"
people is that they are *assuming* a display semantics of "wrap these lines
to display width" which is unreasonable to assume; text/plain does not
provide any display semantics for long lines one way or the other. Adding a
parameter to text/plain indicating display semantics seems much more
coherent than creating a new Content-Type which normally implies a new
*interpretation* semantics.
This is only the first order problem; by itself it worries not appreciably more
than, say, the adoption and use of quoted-printable as an alternative to 8bit
SMTP. (Which is to say I don't ignore it, but I don't let it get me into a huge
snit either.)
I take issue, however, with the second order problems we _know_ this usage
causes. These cannot be fixed by simply upgrading display agents. Once
carefully formatted plain text is wrecked it is wrecked, and no amount of
automatic processing will fix it.
My primary goal in wanting to add some means of labelling paragraph text is so
that these sorts of effects can be contained. And any sort of labelling will
solve this problem -- some may bring up the old "some agents can't switch on
the basis of parameters but can on subtype so let's use subtype" line of
reasoning, but even that doesn't worry me all that much. What worries me about
the parameter approach is that its too easy and the restraints a document
specifying it will require are likely not to be acceptable to the people who
want to send around paragraph text.
Ned