Subject: Content-Type: text/paragraph. An alternative proposal

From: ruth moulton <[email-masked]>
Date: Mon, 16 Feb 1998 15:23:15 GMT

Ian 

While I was reading this I DID think that the same affect could be
achieved with quoted printable. Surely a decoded QP line can be folded
by the receiving MUA, where there is a hard cr/lf then the line should
be broken. I thought one of the advantages of QP with soft & hard line breaks
is that it is proof against adding/stripping of trailing white space.

 >    it is said that some MTAs or gateways routinely strip trailing white-
 >    space or even pad lines with white space. The effect of the former is
 >    simply to reduce the message back to a text/plain equivalent. The
 >    effect of the latter would easily be spotted from the pattern of
 >    white space before the line endings. Either effect could be finessed
 >    by using quoted-printable encoding (but then the messages would never
 >    be suitable for sending to non-MIME recipients). "Munging" of

QP encoded text MAY be sent to non MIME recipients and still be
legible, the only problem being the existance of '=' and =20' at the
end of most lines. I would not say the message 'would never be
suitable' to send to non mime recipients.

Am I wrong in thinking that one advantage of text/paragraph over
text/plain plus QP encoding, is that to non MIME MUAs the result is
better looking. After all for a MIME inteligent MUA it is just as
capable of handling the latter as the former, 

also with text/paragraph the MUA is given *explicit* permission to
fold long lines and use proportianl fonts.

I'm probably missing the point here!...

Ruth

 >    trailing white-space does not seem to pose a significant problem
 >    here.
 > 
 > Display considerations: 
 > 
 >    since pre-formatted lines may have been formatted using fixed-pitch
 >    fonts (especially lines from signature files), MUAs may choose to
 >    display preformatted lines in a fixed pitch font while displaying
 >    paragraphs in a proportional font.
 > 
 > Conclusion
 > 
 > I don't think that the definition of text/paragraph described in the
 > first draft is very useful. However, if my ideas on line-break encoding
 > are acceptable, I believe that text/paragraph would be more useful to
 > modern MUAs than text/plain and more widely usable than text/html. There
 > seem to be no down-sides compared to text/plain and the up-side is that
 > email messages and UseNet articles could be displayed in modern
 > proportional fonts while preserving the layout of quoted material,
 > signatures and even embedded tables.
 > 
 > 
 > New functionality, fully backwards-compatible, with no down-sides - what
 > have I missed? :-)
 > 
 > -- 
 > Ian Bell                                           T U R N P I K E  Ltd

-- 
================================================
Ruth Moulton            [email-masked]
Consultant              

65 Tetherdown, 
London N.10 1NH, UK     Tel:+44 181 883 5823

--

---

From: Rick Troth <[email-masked]>
Date: Mon, 16 Feb 1998 14:16:24 -0600 (CST)

On Mon, 16 Feb 1998, Ian Bell wrote:

> >From <draft-newman-mime-textpara-00.txt>
> 
> >                    The Text/Paragraph Media Type
> >
> >     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.
 
	When I first read this,  I didn't like the idea.   But ... 
 
> text/paragraph is then defined in such a way as to simply codify the
> existing (mal)practice. It still results in existing MIME-compliant
> software displaying messages that use the new media-type with unreadably
> long lines. 
 
	Which I find totally unacceptable.   But I don't think 
that is what will happen.   As Jacob points out,  when (if?) 
text/paragraph is accepted (and UNDERSTOOD) then MUAs will 
finally have a way of dealing with the (mal)practice. 
 
> As mentioned later in that draft, there may also be problems
> when such messages are quoted (and requoted), and with signature files
> which usually include lines that are not meant to be wrapped.
 
	Yes.   But the burden is on the MUA to process content 
into presentation,  and then process presentation into content 
for the reply  (if any).   This new CT facilitates that end by 
offering a recognizable handle on what some systems are presuming. 
 
> Thus, my proposal for text/paragraph would be that:
> ... 
 
	Please do NOT introcuce dependencies on whitespace. 
Leading, trailing, mixed TABs and BLANKs:  they all lead to 
new and wonderful forms of (mal)practice. 
 
>    it is said that some MTAs or gateways routinely strip trailing 
>    whitespace or even pad lines with white space.   ... 
 
	It is truly said.   But stripping and padding of whitespace 
is not limited to MTAs  (though may be exclusive to MTAs within the 
realm of electronic mail). 

	Thanks for your constructive thoughts. 
 
-- 
Rick Troth at La Casita, Houston, Texas, USA

---

From: Chris Newman <[email-masked]>
Date: Mon, 16 Feb 1998 14:31:40 -0800 (PST)

The fundamental premise behind the current text/paragraph proposal is that
we can't stop vendors from generating this stuff, so let's at least
attempt to get them to label it so the recipient can fix it without 
breaking other things.

Your counter-proposal is based on the premise that the vendors who are
generating this stuff are willing to add code to make it palatable to
Internet users.  Given that downconversion to text/plain is simpler than
your proposal, and that there is an existing text media type which encodes
paragraph semantics in a human friendly way (RFC 1896), I suspect your
premise is not correct.

Your proposal is creative and might have been a good idea six years ago, 
but I don't think it addresses the underlying problem today.

		- Chris