Ned, I'd like clarification on two points.
On 3/10/98 at 10:53 AM -0600, Ned Freed wrote:
- I'm not aware of significant compatibility problems with text/plain &
long lines.
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?
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"?
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. 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.
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.
Any problems with this?
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478 / Fax: (217)337-1980