headers
Ian Bell | 16 Feb 1998 14:13

Content-Type: text/paragraph. An alternative proposal

>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.

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. 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.

This definition of text/paragraph is also unlikely to be taken up by the
software vendor mainly responsible for misusing text/plain in the
messages that we see. At least one of its offerings treats unknown sub-
types of text as application/octet-stream and so they will be unable to
upgrade to text/paragraph without seriously breaking their installed
base.

Since the current drafting of text/paragraph does not seem to advance
the current position significantly, why don't we take the opportunity to
(Continue reading)

Permalink | Reply | 536 comments |
headers
ruth moulton | 16 Feb 1998 16:23
Picon
Picon

Content-Type: text/paragraph. An alternative proposal


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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jacob Palme | 16 Feb 1998 17:50
Picon
Picon

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

At 13.13 +0000 98-02-16, Ian Bell wrote:
>This definition of text/paragraph is also unlikely to be taken up by the
>software vendor mainly responsible for misusing text/plain in the
>messages that we see. At least one of its offerings treats unknown sub-
>types of text as application/octet-stream and so they will be unable to
>upgrade to text/paragraph without seriously breaking their installed
>base.

How do you know this? Content-Type: text/paragraph is still only
a proposal. When it becomes a proposed standard, I am sure implementors
will begin supporting it.

I think the proposal in draft-newman-mime-textpara-00.txt is better
than your proposal. It does not require any modification of the text
itself, only better labelling of it, this must be simpler to implement.
Your proposal will make it difficult to intentionally send text with
spaces before line breaks, even if this may not be very meaningful,
it does not seem nice to restrict users from sending any text they
want!

------------------------------------------------------------------------
Jacob Palme <jpalme <at> dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Permalink | Reply | 0 comments |
headers
Ian Bell | 16 Feb 1998 17:27

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

On Mon, 16 Feb 1998, ruth moulton <ruth <at> muswell.demon.co.uk> writes
>
>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.

Not sure what you mean here, but quoting you out of order...

>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, 
>

... text/plain plus QP encoding is precisely what all the fuss is about!

Messages sent text/plain are meant to have their line-breaks just where
the sender wants them - so if some MUA sends out a line of 900
characters before a hard line-break (maybe using qp because it
mistakenly thinks qp supports paragraphs), the receiving MIME-compliant
MUA should display a line of 900 characters! This is invariably _not_
what the user themselves had in mind.

> 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.
>

QP is indeed proof against adding/stripping of trailing white space.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rick Troth | 16 Feb 1998 21:16
Picon
Picon

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

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Newman | 16 Feb 1998 23:31

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

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
Permalink | Reply | 533 comments |
headers
Ned Freed | 17 Feb 1998 08:57

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

> > This definition of text/paragraph is also unlikely to be taken up by the
> > software vendor mainly responsible for misusing text/plain in the
> > messages that we see. At least one of its offerings treats unknown sub-
> > types of text as application/octet-stream and so they will be unable to
> > upgrade to text/paragraph without seriously breaking their installed
> > base.

> How do you know this? Content-Type: text/paragraph is still only
> a proposal. When it becomes a proposed standard, I am sure implementors
> will begin supporting it.

Yes, support in the sense of labelling material of this sort properly would be
great.

> I think the proposal in draft-newman-mime-textpara-00.txt is better
> than your proposal. It does not require any modification of the text
> itself, only better labelling of it, this must be simpler to implement.
> Your proposal will make it difficult to intentionally send text with
> spaces before line breaks, even if this may not be very meaningful,
> it does not seem nice to restrict users from sending any text they
> want!

Agreed.

More generally, what we're doing here isn't defining a new form of text. (If we
were I would certainly be willing to consider alternative formats.) No, what
we're doing is providing a label for widespread existing practice -- practice
for which no MIME label presently exists.

We have substantial experience that says we cannot define new textual media
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald Tveit Alvestrand | 17 Feb 1998 10:41
Picon

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


>We have substantial experience that says we cannot define new textual media
>types and expect widepspread deployment. Both text/richtext,
text/enriched, and
>even text/html (in the context of email) have tried to do this and have not
>succeeded.
>
text/html is beginning to succeed.
It's good for two things:

- passing formatted text inside a html-enabled community
- raising blood pressures in communities that don't "do" text/html :-)

I've actually seen text/html messages that were NOT followed up by
a flame to the author not to send such stuff - but it's still rare.

(wrt text/paragraph, I agree completely that it should be registered)

                    Harald A

NOTE: New Email address: Harald.Alvestrand <at> maxware.no
I am working for Maxware (www.maxware.no) as of Dec 1, 1997
Permalink | Reply | 0 comments |
headers
Ian Bell | 17 Feb 1998 14:30

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

On Mon, 16 Feb 1998, Chris Newman <Chris.Newman <at> innosoft.com> writes
>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.
>

If the only use of text/paragraph will be to allow misusers of
text/plain to correctly label their stuff, then the current proposal is
fine...

...however, I am still worried about the effects on message-quoting if
it gets wider use. It will be all too easy for quoted sections to become
badly wrapped in long conversation threads leading to users complaining
about being mis-quoted. Perhaps an explicit warning to MUAs preparing
reply messages is needed.

>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.

The premise was that if text/paragraph were going to be defined, it
would be worth defining it in such a way that it has wider applicability
than just stopping the misuse of text/plain.

Defining it to be so backwards-compatible that it would be suitable to
be sent to non-MIME recipients seemed to be worth the attempt since many
messages are prepared for a "mixed audience" of MIME and non-MIME users
(eg mailing lists, UseNet,...).
(Continue reading)

Permalink | Reply | 17 comments |
headers
Ian Bell | 18 Feb 1998 15:37

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

On Tue, 17 Feb 1998, I wrote
>
>If the only use of text/paragraph will be to allow misusers of
>text/plain to correctly label their stuff, then the current proposal is
>fine...
>
>...however, I am still worried about the effects on message-quoting if
>it gets wider use. It will be all too easy for quoted sections to become
>badly wrapped in long conversation threads leading to users complaining
>about being mis-quoted. Perhaps an explicit warning to MUAs preparing
>reply messages is needed.
>

The more I think about this, the more I worry about the interaction
between text/paragraph and message-quoting. I fear we may be moving from a
standard (text/plain) that's being broken to a standard (text/paragraph)
that _is_ broken.

A reply to a paragraph within a text/paragraph body part that looks like

        A message with ... ... a very long line.

would, if the entire paragraph is quoted with the standard marker, be

        >A message with ... ... a very long line.

which may get displayed as

        >A message with ...
        >... a very long line.
(Continue reading)

Permalink | Reply | 15 comments |

Gmane